Securebits Blog

DNSWall is a proof-of-concept (PoC) tool developed by some security researchers from Stanford University as a protection mechanism against DNS rebinding attacks. In their research paper “Protecting Browsers from DNS Rebinding Attacks”, Collin Jackson et al. discuss the DNS Rebinding vulnerabilities, attacks, and defenses.

DNS rebinding attack exploits the web browser same-origin policy. The same-origin policy states that a web browser can run scripts (e.g. Javascript, Flash, etc) that communicate with ‘another’ web site as long as the original website and the second one share the same origin. The same-origin policy defines three conditions: (a) same protocol, (b) same port, and (c) same hostname. For example, the address "http://www.securebits.org" and the address "https://www.securebits.org" do not share the same origin, and thus, cannot script against each other. The web browser does not allow scripts from "http://www.securebits.org" to communicate freely with "https://www.securebits.org". On the other hand, the address "http://www.securebits.org:8080" and the address "http://www.securebits.org:8080/somefolder/" are said to have the same origin because they share the same protocol (http), the same port (8080) and the same hostname (www.securebits.org).

An attacker can exploit this policy by rebinding the hostname of a particular website to an IP address that is different than the original one. Usually, the attacker would build a website that is under his/her control. He/she also controls the DNS server that resolves the DNS queries related to that website. When the victim accesses the website for the first time, the DNS server gives out the correct IP address. However, later on, the attacker rebinds the hostname of the website with a false IP address - usually an IP address that the attacker does not have access to – so that any subsequent link to the website will be directed to that IP address. By doing this, the attacker can script against the IP address – he/she can port scan, bypass firewall, access systems, etc.

To illustrate this with an example, let’s say that the victim’s machine is behind a firewall and has the IP 10.10.10.5. In the same network, there is a printer with the IP 10.10.10.8. The printer can be accessed through a web interface and normally does not prompt for username/password since it is in a private network and is only accessible by trusted systems within the network. The attacker, who is outside in the Internet, would build a website "www.example.com", and also control a DNS server that resolves the hostname "www.example.com" to the IP 65.54.43.32. Through social engineering tricks, the attacker would trick the victim to visit the website "www.example.com". Initially, the browser will send a DNS query to resolve that name and eventually will get the IP 65.54.43.32. When the client visits the website, the contents of the website are downloaded. The attacker sets a script (Javascript or Flash) that initiates a connection to the “hostname” (www.example.com). By the time this script is executed by the browser, the browser needs to query the DNS again to resolve the hostname "www.example.com". At this time, the attacker’s DNS server will reply with the IP address 10.10.10.8, basically rebinding the hostname to a different IP. Now, the script will actually initiate the connection with the local printer and can re-configure it.

This type of DNS rebinding attack is called “Firewall Circumvention” and it is one of the typical attacks using DNS rebinding technique. The example above mentioned “a printer” as an example; however, any internal device, such as a DSL router, switch, server, etc, can be a target of DNS rebinding attack.

Dnswall is a program that runs on the corporate network DNS server. Its sole purpose is to prevent the resolving of public names to internal IP addresses. According to the authors:

“By blocking outbound traffic on port 53, a firewall administrator for an organization can force all internal machines, including HTTP proxies and VPN clients, to use a DNS server that is configured not to resolve external names to internal IP addresses. To implement this approach, we developed a 300 line C program, dnswall, that runs alongside BIND and enforces this policy.

[…] Many consumer firewalls, such as those produced by Linksys, already expose a caching DNS resolver and can be augmented with dnswall to block DNS responses that contain private IP addresses. The vendors of these devices have an incentive to patch their firewalls because these rebinding attacks can be used to reconfigure these routers to mount further attacks on their owners”

The Dnswall program runs as an intermediary proxy DNS server between the client and the real forwarder server. It intercepts the DNS queries sent by clients, forwards the query with little modification, receives and forwards the reply to the client only when the IP address in the answer payload is public. If the answer IP address is private/multicast, the Dnswall sends NXDOMAIN reply. Particularly, the program checks for IP addresses in the following ranges:

- Invalid IP address: an IP address that starts with 0; i.e. 0.x.x.x
- Node-Local IP address: 127.x.x.x
- Link-Local IP address: 169.254.x.x
- Site-Local IP address: 10.x.x.x, 172.x.x.x, 192.168.x.x
- Multicast IP address: 224.x.x.x

The program can run with the following arguments:

     ./dnswall -b (bind ip) -B (bind port) 
       -f (forwarder ip) -F (forwarder port)

Where ‘bind ip’ is the listening IP address, ‘bind port’ is the listening port number, ‘forwarder ip’ is the IP of the real DNS server, and ‘forwarder port’ is the port on which the forwarder is listening.

Finally, an important point to mention is that the Dnswall program forwards DNS queries after modifying the TXID of the original query. This is done to map the replies with their original queries. However, the new TXID used is sequentially incremented, starting from 0 to 65536. This opens the door to the opportunity of DNS cache poisoning. An attacker would predict the TXID and inject a false response to poison the DNS cache of the client machine. The code snippet that handles this is:

  // Replace the id with our own query identifier
  *((short *)&msg[0]) = htons(current_query);
  current_query++;
  if (current_query >= 65536)
   current_query = 0;

Administrators who seriously want to deploy Dnswall needs to do a little modification to this code to prevent the poisoning attacks. Mainly, a randomization algorithm should be used to select new TXID, or at least preserve the same original TXID.