Introduction
DNS Rebinding(DNS 리바인딩)은 보안 공격 기술 중 하나로, 공격자가 악의적인 DNS 서버를 통해 피해자의 웹 브라우저를 속여 내부 네트워크나 비공개 IP 주소로의 접근을 유도하는 방법입니다. 이를 통해 브라우저의 동일 출처 정책(SOP, Same Origin Policy)을 우회하고 내부 네트워크의 리소스에 무단으로 접근하여 데이터를 탈취하거나 조작할 수 있습니다.
How It Works
공격자는 자신이 소유하고 있는 도메인(e.g. attacker.com)의 DNS 레코드를 제어할 수 있습니다. 여기서는 도메인 주소에 대한 IP 주소(=호스트 주소) 즉, A 레코드에 1.1.1.1 이 설정되어 있습니다.
이후 피해자가 브라우저를 통해 URL attacker.com 에 접속하면, 해당 도메인의 IP 주소가 DNS 캐시에 없기 때문에 DNS 질의(A 레코드)가 발생합니다. 그러면 DNS Resolver 로부터 도메인 attacker.com 의 호스트 주소인 1.1.1.1 을 응답받게 됩니다.
참고로 IP 주소를 반환할 때 TTL(Time To Live) 값을 짧게 설정하여 DNS 캐시가 빨리 만료되도록 합니다. 그 이유는 DNS 캐시가 빨리 만료되어야 공격자가 원하는 시점에 DNS 응답을 다른 IP 주소(예: 내부 네트워크 주소)로 변경할 수 있기 때문입니다.
DNS Resolver 란?
DNS Resolver 는 DNS 서버와 통신하여 도메인 이름에 대한 IP 주소를 찾아주는 중요한 역할을 합니다. 그러나 공격자는 자신의 도메인의 DNS 레코드를 제어할 수 있으므로 NS 레코드에 악의적인 DNS 서버(1.2.3.4)를 설정하여 자신이 원하는 대로 DNS 응답을 조작할 수 있습니다. 이러한 DNS 서버는 공격자가 의도한 대로 DNS 질의에 대한 응답을 변조할 수 있으며, 이는 DNS Rebinding 공격의 핵심 메커니즘이 됩니다.
그 다음 피해자의 브라우저는 공격자 웹 서버(1.1.1.1)로 부터 악성 JavaScript 코드가 포함된 웹 페이지를 받게 됩니다. 이 JavaScript 코드는 피해자의 브라우저에서 실행 되며, 주기적으로 도메인을 재요청(Rebinding)하여 DNS Rebinding 공격을 수행하게 됩니다.
이후 피해자의 DNS 캐시가 만료되면 피해자의 시스템은 다시 공격자의 DNS Resolver 로 DNS 질의(A 레코드)를 수행하게 됩니다. 이때 공격자는 자신의 도메인(attacker.com)의 A 레코드에 대해 내부 네트워크 주소 192.0.0.1 을 반환합니다.
그 결과, 피해자의 브라우저는 공격자가 변경한 DNS 응답에 따라 동일한 도메인(attacker.com)을 통해 내부 네트워크 주소(192.0.0.1)에 연결되어 내부 시스템에 접근하게 됩니다. 브라우저의 동일 출처 정책(SOP)은 도메인 이름만을 검사하므로, IP 주소가 변경되더라도 같은 도메인(attacker.com)으로 인식되어 접근이 허용됩니다.
How to Prevent
DNS Pinning
DNS Pinning(DNS 고정)은 브라우저가 DNS 질의 결과를 일정 시간 동안 고정함으로써 DNS Rebinding 공격으로 인한 IP 주소 변경을 방지하는 기술입니다.
Chrome과 Firefox 같은 최신 브라우저들은 DNS Pinning 을 기본적으로 구현하고 있습니다. 이를 통해 DNS 응답으로 받은 IP 주소를 브라우저 세션 동안 유지하며, DNS 캐시가 만료되더라도 즉시 새로운 IP 주소로 변경되지 않도록 합니다. 하지만 DNS Pinning 메커니즘도 일정 시간이 지나면 DNS 재질의를 허용하기 때문에 완벽한 방어책이 될 수 없습니다. 또한 브라우저 새로고침이나 탭 닫기 같은 사용자 동작으로 인해 DNS Pinning 이 초기화될 수 있습니다.
DNS Record Control
공격자의 DNS 서버가 내부 IP를 반환하도록 설계한 공격을 차단하지는 못하지만, 내부에서 잘못된 리졸빙이 발생하지 않도록 보호해야 합니다. 즉, 로컬 네트워크 DNS 서버에서 내부 IP 주소(e.g. 192.168.x.x, 10.x.x.x, 127.0.0.1)에 대한 DNS 응답을 필터링하여 차단해야 합니다. 이를 통해 외부 도메인이 내부 IP 주소로 리졸브되는 것을 방지할 수 있습니다.
Using HTTPS
HTTPS(SSL/TLS)를 사용하면 DNS Rebinding 공격으로부터 보호할 수 있습니다. HTTPS는 서버의 인증서를 검증하기 때문에 공격자가 DNS를 변조하여 다른 IP 주소로 연결 하더라도, 유효한 인증서가 없으면 연결이 차단됩니다.
즉, DNS Rebinding 공격에서 공격자는 피해자 브라우저의 SOP 정책을 우회하기 위해 내부 IP 주소(e.g. 192.0.0.1)로 요청을 수행합니다. 하지만 일반적으로 내부 IP 주소(e.g. 192.168.0.1)에는 유효한 SSL/TLS 인증서가 없기 때문에, HTTPS 연결 시 브라우저는 인증서 검증에 실패하여 경고를 표시하거나 접속을 차단합니다.
Additional Security Measures
•
WAF(Web Application Firewall)를 활용하여 의심스러운 DNS 요청이나 내부 네트워크로의 비정ㅅ장적인 접근을 모니터링하여 차단합니다.
•
내부 네트워크의 접근 제어 정책을 강화하여 중요한 서비스나 시스템에 대한 접근을 제한하고, IP 기반의 화이트리스트를 구현합니다.
•
DNS Response Policy Zone(RPZ)을 구현하여 악의적인 도메인이나 의심스러운 DNS 응답을 필터링합니다.
DNS Rebinding Tools
특정 도메인에 대한 IP 주소(A 레코드)를 조작하기 위해서는 자신이 소유하고 있는 도메인에 대해서만 가능합니다. 하지만 도메인을 구매하지 않고도 DNS Rebinding 공격을 실습해볼 수 있는 도구들이 존재하므로 아래에 각 도구들의 사용법을 설명드리겠습니다.
rbndr
rbndr 은 DNS Rebinding 취약점에 대한 서비스를 아주 간단하게 테스트하기 위한 네임 서버 입니다.
형식은 다음과 같습니다.
<ipv4 in base-16>.<ipv4 in base-16>.rbndr.us
Plain Text
복사
예를 들어, IP 주소 127.0.0.1 와 192.168.0.1 를 무작위로 반환 하려면 아래의 주소로 만들어집니다.
127.0.0.1 와 192.168.0.1 을 각각 16진수로 변환한 값은 7f000001, c0a80001 입니다.
7f000001.c0a80001.rbndr.us
Plain Text
복사
Singularity of Origin
Singularity 는 NCC Group에서 개발한 DNS Rebinding 공격 프레임워크로, 웹 인터페이스(ref. http://rebind.it:8080/manager.html)를 통해 DNS Rebinding 공격을 쉽게 수행할 수 있습니다.
이 도구는 공격 대상 시스템의 IP 주소와 포트를 지정하여 자동으로 DNS Rebinding 공격을 수행하고, 결과를 실시간으로 모니터링할 수 있는 기능을 제공합니다. 그 중에서 A 레코드 응답 조작을 위한 도메인 설정은 다음의 형식으로 이루어집니다.
s-<Attacker IP>-<Target IP>-<SessionID>-<RebindingStrategy>-e.d.rebind.it
Plain Text
복사
예를 들어, 첫 번째 DNS 질의 응답으로 IP 주소 127.0.0.1 를 보내고 이후에는 192.168.0.1 응답하는 방식(fs, First then always second)인 경우 아래의 주소로 만들어집니다.
s-127.0.0.1-192.168.0.1-TEST-fs-e.d.rebind.it
Plain Text
복사
Hands-On: Executing a DNS Rebinding Attack
DNS Rebinding 공격을 실습하기 위한 전체 구조는 다음과 같습니다.
1.
피해자는 크롬 브라우저를 통해 URL http://s-43.201.55.87-127.0.0.1-TEST-fs-e.d.rebind.it에 접속합니다.
2.
fs 옵션에 따라, Session ID가 test인 첫 번째 DNS 질의에 대해 A 레코드 응답으로 43.201.55.87을 받습니다.
3.
크롬 브라우저는 도메인 s-43.201.55.87-127.0.0.1-TEST-fs-e.d.rebind.it의 호스트 주소 43.201.55.87를 캐시에 저장합니다.
DNS 서버의 부하를 줄이고 응답 시간을 단축하기 위해 DNS 질의 결과를 일정 시간(기본값: 1분) 동안 저장합니다.
4.
이후 피해자의 브라우저는 43.201.55.87 서버 즉, 공격자의 웹 서버로 요청/응답을 반복적으로 수행합니다.
5.
DNS 캐시가 만료되면 도메인 s-43.201.55.87-127.0.0.1-TEST-fs-e.d.rebind.it에 대한 DNS 질의를 다시 수행합니다.
6.
이때 두 번째 DNS 질의에 대해서는 A 레코드 응답으로 127.0.0.1을 받게 됩니다.
7.
크롬 브라우저는 도메인 s-43.201.55.87-127.0.0.1-TEST-fs-e.d.rebind.it의 호스트 주소를 127.0.0.1로 업데이트합니다. JavaScript는 계속해서 동일한 도메인(s-43.201.55.87-127.0.0.1-TEST-fs-e.d.rebind.it)으로 요청을 보내지만, 이제는 실제로 내부 서버(127.0.0.1)로 요청이 전달되어 피해자의 내부망에 있는 서버에 접근하게 됩니다.
8.
이후 피해자의 내부 서버(127.0.0.1)로부터 받은 응답 데이터가 공격자 서버(43.201.55.87)로 전송됩니다.
Setup
.
├── README.md
├── attacker.py # 공격자 웹 서버
├── templates # 공격자 웹 서버
│ └── index.html
└── victim.py # 피해자 웹 서버
Plain Text
복사
공격자 웹 서버(43.201.55.87)
공격자 웹 서버는 인터넷 망(Public Network)에서 접근 가능한 웹 서버입니다. 
DNS-Rebinding-Attack-DEMO 프로젝트에서 Flask 앱 attacker.py 와 templates 폴더를 아래와 같이 이동시킵니다.
DNS-Rebinding-Attack-DEMO 프로젝트에서 Flask 앱 attacker.py 와 templates 폴더를 아래와 같이 이동시킵니다.
이후 attacker.py 를 실행합니다.(명령어: python attacker.py)
공격자 웹 서버(43.201.55.87)에 접속하면 다음과 같은 페이지가 나타납니다. 이 페이지는 현재 접속한 도메인을 iframe을 통해 반복적으로 렌더링하며, 그 결과를 공격자 웹 서버의 /tracking 엔드포인트로 전송합니다.
피해자 웹 서버(127.0.0.1)
피해자 웹 서버는 내부망(Private Network)에서만 접근 가능한 웹 서버입니다. DNS-Rebinding-Attack-DEMO 프로젝트에서 Flask 앱 victim.py 를 가져와 로컬 환경에서 실행합니다.(명령어: python victim.py)
DNS-Rebinding-Attack-DEMO 프로젝트에서 Flask 앱 victim.py 를 가져와 로컬 환경에서 실행합니다.(명령어: python victim.py)
피해자의 로컬 웹 서버는 다음과 같은 페이지를 반환합니다.
Executing the DNS Rebinding Attack
공격자 웹 서버와 피해자 웹 서버 준비가 완료 됐으면, http://s-<공격자 웹 서버>-127.0.0.1-TEST-fs-e.d.rebind.it/ 구조의 URL로 접속합니다.
여기서는 공격자 웹 서버의 IP 주소가 43.201.55.87이므로, 다음과 같은 URL로 접속합니다.
http://s-43.201.55.87-127.0.0.1-TEST-fs-e.d.rebind.it/
Plain Text
복사
처음 요청한 도메인 s-43.201.55.87-127.0.0.1-TEST-fs-e.d.rebind.it의 DNS 질의 결과가 43.201.55.87이므로, DNS 캐시가 만료되기 전까지는 공격자의 웹 서버 응답이 iframe 태그에 렌더링됩니다.
또한, iframe 태그에서 렌더링된 결과가 공격자 웹 서버의 /tracking 엔드포인트로 지속적으로 전송됩니다.
이후 DNS 캐시가 만료되면, 동일한 도메인에 대한 두 번째 DNS 질의 결과로 127.0.0.1 을 받게 됩니다. 이로 인해 iframe 태그는 이제 피해자의 로컬 웹 서버 응답을 렌더링하고 있습니다.
결과적으로 공격자의 웹 서버 로그를 살펴보면, 초기에는 공격자 자신의 응답 데이터만 기록되다가 DNS 캐시가 만료된 이후에는 피해자의 내부망 서버 데이터가 노출되는 것을 확인할 수 있습니다. 이를 통해 DNS Rebinding 공격이 성공적으로 수행되어 브라우저의 동일 출처 정책(SOP)을 우회하고 내부망의 리소스에 접근했음이 확인됩니다.
