Blind SSRF
Blind SSRF(Sever Side Request Forgery)란?
블라인드 SSRF는 애플리케이션이 사용자가 제공한 URL로 백엔드 HTTP 요청을 보내도록 유도할 수는 있지만, 그 백엔드 요청의 응답 내용이 프론트엔드 응답에 포함되지 않는 유형의 취약점이다.
즉, 서버가 어딘가에 요청을 보내긴 보내는데, 그 결과를 화면에서 바로 확인할 수 없다.
블라인드 SSRF는 응답을 바로 회수할 수 있는 SSRF보다 일반적으로 영향이 낮은 편이다(단방향 특성 때문). 민감 데이터를 즉시 탈취하기는 어렵지만, 특정 상황에서는 원격 코드 실행(RCE)까지도 이어질 수 있다.
탐지/악용 방법
블라인드 SSRF를 가장 신뢰성 높게 발견하는 방법은 OAST(Out-of-Band) 기법이다.
핵심 아이디어:
내가 통제하는 외부 시스템(도메인/서버) 을 준비한다.
그 도메인/호스트를 페이로드에 넣어 애플리케이션에 보낸다.
내 쪽 시스템에서 네트워크 상호작용(요청 도착 여부) 을 모니터링한다.
또는 OAST 기법을 수행할 때 Burp Collaborator를 활용할 수 있다…
Collaborator에서 고유한 도메인을 발급받는다.
이 도메인을 페이로드에 넣어 애플리케이션에 전송한다.
Collaborator 탭에서 해당 도메인으로 들어오는 상호작용(DNS/HTTP 등)이 있는지 확인한다.
애플리케이션 쪽에서 해당 도메인으로 실제 요청이 날아오면 블라인드 SSRF 취약점이 존재한다고 판단할 수 있다.
참고 사항(Note)
SSRF 테스트 중 DNS 조회만 보이고 HTTP 요청은 오지 않는 경우가 자주 있다.
보통 애플리케이션이 HTTP 요청을 보내려 시도하면서 먼저 DNS 조회는 수행했지만,
네트워크 레벨 필터링(방화벽/프록시/아웃바운드 정책 등)에 의해 실제 HTTP 연결이 차단된 상황이다.
인프라 환경에서는 다양한 이유로 아웃바운드 DNS는 허용(정상 동작에 필요)하면서, 예상치 못한 대상에 대한 HTTP 연결은 차단하는 구성이 흔하다.
Blind SSRF 정의: 서버가 외부로 요청을 보내긴 하지만, 그 응답이 사용자에게 돌아오지 않는 SSRF. 탐지 핵심: Burp Collaborator 같은 OAST로 내가 통제하는 도메인에 DNS/HTTP 상호작용이 오는지 관찰하라(HTTP가 막혀 DNS만 찍히는 경우도 흔함).
랩1 풀이
랩1 👉 https://portswigger.net/web-security/ssrf/blind/lab-out-of-band-detection
상품 페이지가 로드될 때, 애널리틱스 소프트웨어가 Referer 헤더에 있는 URL을 가져다가 백엔드에서 요청한다.
이 동작을 악용해서 서버가 Burp Collaborator 퍼블릭 서버로 HTTP 요청을 보내도록 만들어야 한다.
노트를 보면,
Academy는 제3자 공격 방지를 위해 임의 외부 도메인과의 통신을 차단해뒀다고 한다.
그래서 직접 만든 서버, ngrok, 개인 도메인 같은 건 안 되고, Burp 기본 제공 퍼블릭 Collaborator 서버만 풀어준다.
즉, Burp Collaborator → Copy to clipboard 한 고유 도메인을 Referer에 넣어야 랩이 Solved 처리된다고 함.
노트에서 시키는대로 하면 될 것 같은데, 버프의 Collaborator 기능 써본적 없어서… 그냥 솔루션을 봤다.
엥 근데 이거 유료버전에서 쓸 수 있는 기능임.. 아.
저는… 무료인 커뮤니티 에디션을 쓰거든요…ㅜ
유료버전에서만 쓸 수 있는 기능으로 풀 수 있는 랩들은 모아서 일주일인가 무료로 유료버전 체험하는거 이용하면?될 것 같은데
지금은 아쉬운대로 대충 솔루션만 정리해두면…
상품 페이지 방문 후 요청 가로채기 → Burp Suite에서 상품 페이지 요청을 Intercept → 해당 요청을 Repeater로 전송 → Referer 헤더 변조 → Repeater 탭에서 Referer 헤더 선택 → 우클릭 → Insert Collaborator Payload 실행 → 원래 도메인이 xxxxxx.burpcollaborator.net 같은 Collaborator 도메인으로 교체됨 → 요청 전송 → 수정된 요청을 서버로 전송 → Collaborator 탭에서 확인 → Collaborator 탭 열고 Poll now 클릭 → 서버가 Referer에 지정된 도메인으로 접근하면, Collaborator에 DNS 및 HTTP 상호작용 기록이 나타난다 → 이게 곧 Blind SSRF 취약점이 존재한다는 증거
요약하면,
Blind SSRF는 응답이 사용자에게 직접 보이지 않는다는 특징 때문에, 단순 Burp Repeater로는 확인 불가.
따라서 외부 상호작용(OAST) 기반 도구(Burp Collaborator)를 이용해야 한다.
Collaborator 도메인을 Referer에 삽입하면, 서버가 해당 도메인으로 실제 요청을 시도 → Collaborator가 이를 기록 → 취약점 존재 확인.
Blind SSRF 공격 시나리오
단순히 Blind SSRF 취약점이 있어 서버가 외부로 HTTP 요청을 보낸다는 사실만 알아낸 것만으로는 곧바로 공격 가능하다고 볼 수는 없다.
백엔드 요청의 응답을 직접 확인할 수 없기 때문에, 애플리케이션 서버가 접근할 수 있는 시스템의 콘텐츠를 탐색하는 데는 쓸 수 없기 때문…
하지만 Blind SSRF는 여전히 다음과 같은 방식으로 활용 가능하다:
내부 IP 대역 무작위 스캐닝: 내부망으로 다양한 페이로드를 보내서, 널리 알려진 취약점을 탐지할 수 있다.
이때도 Out-of-band(OAST) 기법을 함께 사용하면, 내부에 존재하는 패치되지 않은 서버의 치명적 취약점을 발견할 수도 있다.
예시로, 이 랩2 👉 https://portswigger.net/web-security/ssrf/blind/lab-shellshock-exploitation을 풀어보고 싶은데… 이 역시 collaborator 기능이 필요하므로 다음 기회에. 연휴 길 때… 궁금한 유료 랩 모아다가…. 출퇴근 안 할 때 하기로ㅎ(대체 언제쯤)
아무튼 위의 랩은,
Blind SSRF를 악용해, 애플리케이션이 공격자가 제어하는 시스템에 연결하도록 유도한다.
이후 공격자는 서버가 보낸 요청에 대해 악성 응답을 돌려줄 수 있다.
만약 서버 측 HTTP 클라이언트 구현에 심각한 클라이언트 취약점(예: Shellshock)이 존재한다면, 이를 악용해 애플리케이션 인프라 내부에서 원격 코드 실행(RCE) 까지도 가능하다.