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 184.108.40.206.
Next, the user’s browser (with Flash and the trimmings) makes a call to the attackers web server:
GET / HTTP/1.1Initially, 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.
The same-origin policy defines three conditions:
- (1) the same protocol (e.g.. TCP) has to be used,
- (2) the same port (e.g. 80, 81, 8080 etc.) has to be connected to, and
- (3) the same system has the same hostname.
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:
- protocol (http over port 80),
- port (TCP port 80) and,
- hostname (www.badguy.com).
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.