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.

DNS Multiple Race Exploiter (DNS_MRE) tool is now an official FreeBSD Port. The port page is:
http://www.freshports.org/dns/dns_mre/

I would like to thank Tomoyuki Sakurai who ported and is maintaining the port.

Some people from the security community have commented on my tool DNS MRE (Multiple Race Exploiter). HD Moore, the original author of Metasploit Project, has pointed out the uniqueness of this tool in that it can poison/overwrite the DNS cache by utilizing a CNAME record in the answer. He also noted the static TTL used in all fake replies which can make an IDS/IPS signature. Tahir from HatSecurity has pointed the same thing about the static TTL …

Thanks for that;

The next version will contain the following features:

1- Automatic finding of Name Server IPs of the target domain. This only works if the attacked DNS server supports recursion. For DNS server configured with forwarder, the user (attack/pentester) has to manually find the forwarder IP.

2- Randomized TTL values in all replies. Or the user can set the TTL value for all the replies

3- A better algorithm to attack "patched" system, that is, poisoning a patched system in the shortest possible time. This can take the following format:
* There is no sleep() between iterations
* There is no sleep() between query and reply (maybe except the first iteration)
* Sending Multiple queries before sending their corresponding replies.

4- Concerning the source IP addrss of the replies, the user should choose between:
* Using the local IP address
* Using static spoofed IP address
* Using dynamic spoofed IP addresses

5- Poisoning a DNS Server that sends a DNS query with Additional RR of DNSSEC (the server is saying it's willing to accept DNSSEC but is not required)

After Dan’s discovery of the DNS cache flaw, I decided to develop a tool to test our DNS servers in my company. A successful working tool was developed two days after Dan’s webinar. The tool was then enhanced with other features. Currently, version 1.0 is released.

http://www.securebits.org/dnsmre.html

…Continuation of the previous entry…

Dan's Discovery
Although the attack discovered by Dan Kaminsky is still about DNS cache poisoning, the attack has a unique feature that exploits an inherent DNS implementation. The attack can successfully poison the cache even though the cache might already contain the entry (hostname and IP) the attacker wants to set. For example, if the cache contains an entry like www.securebitsorg -> 65.65.65.65, the attack can successfully overwrite it.
The attack happens as follows: the attacker sends many a DNS Query packets to the DNS server to be poisoned, and after sending each query packet, he also sends a reply packet. The query packets ask for non-existent names under specific domain (for example: 00001.securebits.org, 00002.securebits.org, 00003.securebits.org, etc). Since the DNS server under attack is not the authoritative server for the domain securebits.org, it will poll the address through recursive queries. Typically, the Name Server which will give the final answer is the authoritative Name Server of securebits.org, that is, ns.securebits.org.

The fake replies sent by the attacker along the queries have the source IP address as ns.securebits.org. Also, they all have the same TXID. Another thing to note is that the destination port address must match the source port address of the packets sent by the DNS server. The attacker can easily guess this at the beginning by issuing a query to a name under a domain he controls. The source port number will be used as destination port number in all the replies. Since the TXID is 16 bits, in average, it takes around 30,000 replies to hit the correct the TXID; and the cache is poisoned …

Until here, the cache is poisoned with a record for a non-existent name like 12345.securebits.org. Since the attacker is more interested in setting a record for www.securebits.org, the reply can be a more sophisticated; it can contain additional Resource Record (RR) that says www.securebits.org is at 33.33.33.33

A few notes to bear in mind:

- The attack works regardless of the cache contains a record for the name that attacker wants to inject.

- Almost all DNS servers can be attacked/poisoned. Even with the patches released by vendors, the attack process can take couple of hours instead of couple of seconds.

- To block this attack using an IDS/IPS, a signature would be multiple DNS reply packets with the same source IP address and the same TXID.