DNS Rebinding Checklist

Submitted by abb on Mon, 11/22/2010 - 14:15

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.

Attack flow

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.
  • Web browser of the victim loads the page and executes Javascript, provided by the attacker. No user interaction necessary, no security warnings issued.
  • 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.
      • The sub-exploit will try to send UPnP SOAP (HTTP POST) to URL referring to the same host name and port it has been downloaded from. XMLHTTPRequest object accessible from Javascript can be used for this purpose.
      • 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.
        • Normally, XMLHTTPRequest does not let Javascript code specify an arbitrary 'Host' header, so the request will contain 'Host: pXXXX.example.com', which may upset the target server (see below).
        • 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.

    Impact

    • Attacker-supplied Javascript running in the web browser can interact with the internal HTTP service, turning victim's web browser/proxy into a gateway to the LAN.
    • 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

    Checklist

    1. Infrastructure

    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)

    Open questions:

    • 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?

    References

Contacts

+32 (0) 2 215 53 58

Gremwell BVBA
Sint-Katherinastraat 24
1742 Ternat
Belgium
VAT: BE 0821.897.133.