Friday, 5 August 2011

DNSWall, Rebinding and client attacks (Part 1).

A few technologies have done wonders in helping protect us from rebinding attacks. OpenDNS / NoScript / DNSWall are key in this effort, but it seems that not many people know what they do.

I will note how OpenDNS and NoScript help defend our networks rebinding another post, but for now I will talk of DNSWalls and why they are necessary.

A DNSWALL is an application, service, daemon etc. that filters the RFC 1918 private addresses out of DNS responses. A reverse DNS wall stops your RFC 1918 addresses from being returned.

For this post, I am focusing on the DNSWALL as a fix for certain types of rebinding attacks. I cover DNS and many of the issues it still faces in more depth in my SANS paper from 2008.

Other attacks against browsers and clients that will be written about in the coming weeks include Cross Site Request Forgery (CSRF) and iFrame attacks.

Rebinding to attack RFC 1918 addresses
In attacking an RFC1918 host, in this example a user’s browser on the internal address of 10.1.1.1 (we have not listed the external address, but there will be a firewall or other NAT device used so that the user may connect to the Internet), the attacker cannot directly send packets to the user.


Here, the user has called a webserver controlled by the attacker at www.badguy.com and it has been initially resolved to an external IP address that the user can connect to across the Internet.

The user starts by making a query to DNS and the initial reply is a valid internet address. For this example I will use 203.34.22.10.

Next, the user’s browser (with Flash and the trimmings) makes a call to the attackers web server:
GET / HTTP/1.1
Host: www.badguy.com
Initially, the attacker’s external web server will respond with HTML code such that the web page is sent to the user and can be displayed in their browser.

A DNS rebinding attack is used by an attacker to exploit the web browser’s same-origin policy. The same-origin policy is used by the web browser when it runs script code ( such as JavaScript, Flash, and other active code) that connects to different web sites when and if the original website and the one that the original one is connecting to share the same origin.

The same-origin policy defines three conditions:
  1. (1) the same protocol (e.g.. TCP) has to be used,
  2. (2) the same port (e.g. 80, 81, 8080 etc.) has to be connected to, and
  3. (3) the same system has the same hostname.
Consequently, http://www.badguy.com and https://www.badguy.com are not both in the same origin as far as a web browser is concerned. The web browser will not allow these two sites to run scripts against each other as these sites have different port numbers (a violation of point 2 above as well as point 1 – protocol http vs. https).
This means that your web browser will (should) not allow scripts from http://www.badguy.com to interact and share data with https://www.badguy.com.
However, the addresses below are all of the same origin:
  1. http://www.badguy.com/attack_scripts
  2. http://www.badguy.com/user_data
  3. http://www.badguy.com
This is as these share the same:
  1. protocol (http over port 80),
  2. port (TCP port 80) and,
  3. hostname (www.badguy.com).
Attackers use the ability to rebind the hostname of a website to an IP address that is different than the original one for the attacks I am documenting here. In particular, by using TTL (time to live) and IP address caching times that differ from the browser to flash and other sources, the attacker can have the user’s host, the user’s browser and the flash application all see different IP addresses.

This starts when the attacker sets a small TTL making the user’s system ask the DNS server for the attackers IP address again. The first call to the DNS server of course will have returned a valid publically routable IP address so the user can get to the attacker’s web server, but a subsequent call to the DNS server could return an internal RFC1918 address.

Exploiting timing differences, the attacker can use the differences in the pinning (I will explain this in the next post and then link it) times of the browser and the script applications (such as Flash) to their advantage.
The browser may remember the IP of the external system, but flash may cache a new IP address obtaining an internal 10.1.1.0/24 address. In this way, the attacker can point your browser and flash application towards an internal system.

This can be used for something as simple as scanning an internal server or event the range of addresses inside the network or for connecting to trusted systems.

As many internal Intranet sites are trust-based (either caching credentials or even using the account of the logged on user or worse, just their IP address), an attacker could attempt to user this trust as a means to log into the internal system and extract data.

More to come…
In the next couple days, I will continue on this post as well as explaining how a DNS Wall can help stop an attacker from mapping your internal network.

At the end of the day, it is never a good idea to allow external Internet hosted DNS servers to return un-routable RFC1918 addresses to your server.

There are a number of things that you need to do to stop this, first, stop your users from connecting to external DNS servers (and it is amazing how many organisations do not filter outgoing UDP and TCP 53 at their firewalls). Next, and I will detail this in more depth in the coming post, install a DNS wall using an application such as Google’s DNS WALL or OPENDNS.

As your systems cannot connect to RFC 1918 addresses on the internet (they cannot be publically routed) you lose nothing by blocking these and gain much.

No comments: