Saturday, 6 August 2011

DNSWall, Rebinding and client attacks (Part 3).

Continuing from last nights post on DNS Rebinding as well as part 2 today, I will detail and endeavour to show a few defences.

A DNS WALL is a program, service or daemon that runs on or between the network DNS server.

Google has DNSWall, an open-source application with the stated purpose of preventing DNS servers inside your organisation from resolving public names to internal RFC1918 IP addresses. They state that:
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 from Google sits between the internal client host and their organisational DNS forwarder. It is in effect an intermediary proxy server for DNS traffic. By intercepting the DNS queries sent by clients, it can then forward the client’s query, modifying the information receives from the authoritative DNS server when an RFC 1918 request has been received. This means that it will only forward the reply (the destination server IP address) to the client when the IP address being returned is not an RFC1918 address. That is, it will filter private addresses and stop attackers being able to rebind your system to 192.168.x.y, 10.0.0.0/8 or 172.16.a.b addresses.

It is actually a little more complex than that, but any of the following

  •  Invalid IP address: an IP address in the 0.x.x.x range
  •  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 
Troubles with Google’s DNSWall
Google’s DNSWall application modifies the TXID of the original DNS query.

This is the means that they have used to map replies to the original query.

In DNSWall new TXID used is sequentially incremented leaving this open to poisoning attacks if an attacker can insert themselves or in selected other instances. As the TXID is issued starting from 0 and increases sequentially to 65536 before starting again, the poisoning attack is far simpler than it should be. The attacker can guess the TXID and inject a false response such that they could poison the DNS cache of the client’s host.

Not too difficult to fix with a little effort.

Where you can take this…
In coming weeks I will start to document a process to create more than a simple RFC1918 blocker, but to also allow this to be used to filter known block-lists, SPAM relays and also alter administrators when their users are being sent to malicious websites.

Nothing too hard and with minimal cost (other than some time).

No comments: