dns-rebinding-attacks

소개 dns-rebinding-attacks

이 문서는 피해자가 이미 불러온 호스트 이름 뒤에 있는 IP 주소를 변경하여 브라우저의 동일 출처 정책을 우회하는 클라이언트 측 기법에 초점을 맞춘 DNS 리바인딩 공격 가이드입니다. 핵심은 동일 출처 정책이 해결된 IP 주소가 아닌 호스트 이름 문자열을 확인한다는 점입니다: 자신의 도메인에 대한 권한 있는 DNS를 제어하는 공격자는 첫 번째 확인 단계(공격자 IP)에서 악성 자바스크립트를 제공한 다음, 동일한 호스트명을 내부 IP로 재확인할 수 있습니다. 이로 인해 브라우저는 내부 서비스에 대한 요청을 동일 출처로 간주하게 되며, 스크립트는 응답 내용을 읽을 수 있게 됩니다.

이 글은 DNS 리바인딩이 SSRF의 클라이언트 측 대응 기법이라는 점을 명확히 설명하며, 실제 적용 시의 장애물과 해결 방안을 상세히 다룹니다. 브라우저는 낮은 TTL(Chrome, Edge, Firefox의 경우 대략 60초)을 무시하는 자체 DNS 캐시를 유지하기 때문에, 이 문서에서는 캐시 만료 대기, 공격자 IP 차단을 포함한 다중 A 레코드 응답을 통한 강제 폴백, 새로운 조정을 위한 서브도메인 플러딩, 서비스 워커 지연 등 우회 전략을 다룹니다. 공격 변종으로는 고전적인 HTTP 리바인딩, WebSocket 리바인딩, 서버 측 TOCTOU 하이브리드, 그리고 빠른 다중 A 레코드 접근 방식이 포함됩니다.

이 기법은 DNS를 통해 원본 확인을 수행하거나, 공격자가 제어하는 도메인으로 클라이언트 측 fetch/XHR 요청을 보내는 애플리케이션을 테스트할 때, 특히 서버 측 SSRF가 불가능한 경우에 활용하십시오. 주요 표적 목록에는 클라우드 메타데이터(169.254.169.254), Docker 및 Kubernetes API, 내부 관리자 패널, Elasticsearch, Redis, Consul/etcd가 포함되어 있으며, IMDSv2의 토큰 요구 사항으로 인해 no-cors 모드에서는 사용자 정의 헤더를 쉽게 설정할 수 없어 리바인딩이 불가능하다는 점이 언급되어 있습니다. 지원되는 도구로는 Singularity, 설정 없이 바로 사용 가능한 rbndr.us 서비스(16진수 IP 서브도메인 형식), whonow, 최소한의 Python DNS 서버 등이 포함되며, SSRF 및 CORS 설정 오류 활용 기법과 상호 참조됩니다.

자주 묻는 질문

DNS 리바인딩은 SSRF와 어떻게 다른가요?

SSRF는 서버 측 공격인 반면, DNS 리바인딩은 피해자의 브라우저에서 실행되는 클라이언트 측 공격입니다. 이는 동일 출처 정책이 해결된 IP가 아닌 호스트 이름 문자열을 확인한다는 점을 악용합니다.

TTL을 0으로 설정해도 즉시 작동하지 않는 이유는 무엇인가요?

브라우저는 낮은 TTL(Chrome, Edge, Firefox의 경우 약 60초)을 무시하는 자체 DNS 캐시를 유지하므로, 이 스킬은 대기, 폴백이 포함된 여러 A 레코드, 서브도메인 플러딩, 서비스 워커 지연과 같은 우회 방법을 다룹니다.

가치 높은 내부 표적은 무엇일까요?

169.254.169.254의 클라우드 메타데이터, Docker API, Kubernetes API, 내부 관리자 패널, 9200 포트의 Elasticsearch, 6379 포트의 Redis, 그리고 Consul/etcd입니다.

리바인딩을 통해 IMDSv2에서 AWS 자격 증명을 탈취할 수 있나요?

쉽지는 않습니다. IMDSv2는 PUT 요청 시 X-aws-ec2-metadata-token 헤더를 요구하며, 리바인딩은 no-cors 모드에서 초기 토큰 요청 시 사용자 정의 헤더를 쉽게 설정할 수 없습니다. IMDSv1은 더 취약합니다.

어떤 도구를 추천하나요?

Singularity(전체 프레임워크), rbndr.us(설정 불필요, 16진수 IP 쌍 서브도메인 사용), whonow(동적 리바인딩 서버), 그리고 최소한의 맞춤형 Python DNS 서버입니다.