Recently I have done a couple of tests which made me consider DNS rebinding attack in details. Considering relatively large number of "moving parts" involved into the attack, I figured it worth making a checklist which can be used to do this kind of evaluation. Below is the draft which I am working on. In particular I intend to add references and explanations/testing guidelines to the checklist. Not sure about PoC exploits.
Infrastructure of the attacker
Attacker needs one web server and one DNS zone to prepare for the attack.
- Web server listening on a public IP address and serving:
- www.example.com: webpage containing the main loop of the exploit
- p*.example.com: webpage containing subexploits code
- DNS servers at example.com serving the following data:
- www.example.com: one A record pointing public IP address of the web server of the attacker
- p*.example.com: two A records pointing to
- Public IP address of the web server of the attacker
- Public or private IP address of the target HTTP service.
- Use of public IP permits attack against browser strongly preferring private IPs over public ones (IE)
- Private IP address can be targeted with browsers not considering IP addresses when making decision where to connect to (Firefox)
Infrastructure of the victim
Typical victim: a computer with a web browser on LAN behind a NAT box and/or a proxy.
- LAN using private IP addresses behind a firewall, inaccessible from the Internet.
- DNS server used by LAN hosts or the proxy.
- A host on the LAN, with web browser and Internet-connectivity
- via NAT
- via HTTP proxy server located on the LAN
- via HTTP proxy server located outside of the LAN or DMZ or provider
- HTTP server on the LAN, normally inaccessible from the Internet. Attacker should know or guess IP address and port the server listens at. Possible targets are web admin interfaces of a firewall or UPnP listeners of Internet gateway.
Taking DNS rebinding against UPnP listener as an example, the attack flows as following:
- An attacker tricks victim into opening URL pointing to the landing page.
- The main loop of the exploit (with some delay) arranges an subexploit to be loaded into some IFRAME by pointing it URL pXXXXXX.example.com, where XXXXXX is a large random number.
- The browser (or proxy) resolves pXXXXXX.example.com using public DNS.
- The attacker's DNS server responds with two A-records (in random order) pointing to:
- Public IP address of attacker's web server
- IP address of a target HTTP service
- If victims DNS server blocks DNS responses containing private IP addresses, the attack fails.
- If no proxy is used
- If browser or proxy prefers private IP addresses over public ones (IE, (what proxy?)), it always picks the private IP address and the attack would fail.
- If browser or proxy has no preferences (Firefox, (Squid, ...?))
- Browser/proxy has chosen private IP address (50% probability), the attack would fail.
- Browser/proxy has chosen a public IP address (50% probability), it will contact attacker's server and fetch the sub-exploit and has a chance to succeed.
- If browser/proxy does DNS pinning and does not obey DNS TTLs (IE, (what proxy?)), the request will be forwarded to attacker's server again and the attack fails.
- If browser/proxy does no DNS pinning and obeys zero TTL returned by the attacker (Firefox ,(Squid?)), it will ask attacker's DNS server to resolve the name again. Who return two IPs: one of the attacker and one of the target HTTP server.
- With 50% probability (or 25% among the iterations of the main loop) the web browser/proxy will choose IP address of the target HTTP server.
- The browser will use XMLHTTPRequest to connect to the IP address of the target HTTP server and submit HTTP request supplied by the attacker.
- There is an option to supply basic HTTP authentication credentials.
- Some proxies supposedly can be tricked into injecting a custom headers to bypass this restriction. This will lift the mitigation factor listed below.
- If the browser/proxy has no network-level connection to IP address and port of the target HTTP server, the attack will fail.
- The target HTTP server receives the request
- If the server validates HTTP Host header, it will reject the request and the attack will fail.
- If the server does not validate Host header, it will process it. The attack succeeded.
- Attacking UPnP HTTP service on Internet gateways will let an attacker to open an arbitrary TCP/UDP tunnel into the internal network.
Scope of the review
The following components take part in the attack and have to be reviewed:
- DNS servers used by the Internet client host or proxy
- HTTP proxy (optional)
- HTTP servers exposed to the clients
- Internet client itself, typically a web browser
1.1 Does DNS server allows private IP addresses in DNS responses?
1.2 Does browser use proxy?
1.2a Does proxy implement DNS pinning?
1.2b Does proxy have access to internal HTTP servers sensitive to CSRF?
2. Client side (not relevant if clients use HTTP proxy)
2.1 Do web browsers used by the clients implement DNS pinning?
2.2 Do clients have access to internal HTTP services sensitive to CSRF?
3. HTTP service
3.1 Does HTTP service listen on public (non-RFC1918)?
3.2 Does HTTP service accepts arbitrary "Host" header?
3.3 Can HTTP service be easily overloaded? (TBD)
- What is the impact of "bypass proxy for local addresses" option in the browser?
- What browsers and proxies implement DNS pinning?
- What browsers and proxies prefer private IPs over public?
- What addresses are considered private? 169.254/16 (link-local) too?