May 11th, 2009

UPDATE: Unfortunately, this method of anti-DNS pinning does not work quite as we had observed in the lab. As it happens, browsers (IE and FF), if given multiple IP addresses in a DNS response, will always try a private IP address first, regardless of the order in which the IP addresses are listed in the DNS response. If all of the IP addresses in the response are private IPs, then the browser will try them in order (which is why this technique worked during our lab testing, since all of our lab IPs were non-routable). Unfortunately, this prevents the use of this attack as we had previously described. It can still be used in some circumstances, such as an internal attacker attempting to leverage IP-based ACLs, or it can be used to give an external attacker access to Web services running on the localhost (such as CUPS, or bittorrent clients). We’re leaving all of our original post below as even these limited scenarios may be useful attack vectors; in the mean time, we’re going back to the drawing board to examine more traditional anti-DNS pinning attacks.

Anti-DNS pinning is a technique for kinda-sorta circumventing the same domain policy enforced in Web browsers. While it does have some limitations, it is great for using a client’s browser to access restricted internal resources (such as a router’s Web interface). The problem is that whenever I see people talk about anti-DNS pinning, they make it more complex than it really should be. They focus on DNS cache time outs and forcing browsers to re-request DNS lookups and so forth. This is really all unnessesary; all an attacker really needs to do in order to thwart DNS pinning is to use DNS load balancing.

What’s so great about using DNS for load balancing? Any decently sized Web site does it; it’s pretty much standard procedure. Take a look at the DNS lookup for www.google.com and think about how it works for a second:

; <<>> DiG 9.4.3-P2 <<>> www.google.com
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57946
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 7, ADDITIONAL: 0

;; QUESTION SECTION:
;www.google.com.			IN	A

;; ANSWER SECTION:
www.google.com.		262385	IN	CNAME	www.l.google.com.
www.l.google.com.	82	IN	A	64.233.161.147
www.l.google.com.	82	IN	A	64.233.161.99
www.l.google.com.	82	IN	A	64.233.161.104

;; AUTHORITY SECTION:
l.google.com.		3802	IN	NS	f.l.google.com.
l.google.com.		3802	IN	NS	d.l.google.com.
l.google.com.		3802	IN	NS	c.l.google.com.
l.google.com.		3802	IN	NS	e.l.google.com.
l.google.com.		3802	IN	NS	b.l.google.com.
l.google.com.		3802	IN	NS	a.l.google.com.
l.google.com.		3802	IN	NS	g.l.google.com.

;; Query time: 0 msec
;; SERVER: 71.252.219.43#53(71.252.219.43)
;; WHEN: Mon May 11 15:23:53 2009

;; MSG SIZE  rcvd: 212
,

When your browser navigates to www.google.com, it will first try the 64.233.161.147 IP address; if that doesn’t work, it will try 64.233.161.99 and finally 64.233.161.104. Now, let’s say that we own a domain name, myevilsite.org, and we want to attack your internal router, located at 192.168.1.1. When your browser tries to navigate to myevilsite.org, it will perform a DNS lookup, and our DNS server will respond with the following:

;; ANSWER SECTION:
www.myevilsite.org	82	IN	A	12.34.56.78
www.myevilsite.org	82	IN	A	192.168.1.1

The browser will cache these IP addresses and first attempt to connect to 12.34.56.78, which is the IP address for the myevilsite.org Web server. The browser will load up our Web page that contains some JavaScript that we have crafted to assist us in this attack, and as soon as our Web server has supplied the browser with this page, it will shut down (note that the server itself is still up, just that there is no longer a service listening on port 80).

Our JavaScript then attempts to make a connection back to www.myevilsite.org via an XMLHttpRequest. Since this is within the same domain policy of the browser, the browser allows the request and attempts to connect back to 12.34.56.78; except that now the browser will recieve a TCP RST packet because there is no longer a service running on port 80 at that IP address. Upon seeing this, the browser will then try the next IP address in the list – which is 192.168.1.1. The browser thinks that it is still connecting to www.myevilsite.org, but it is actually connecting to your internal router. Since the browser sees this as still within the scope of its same-domain policy, our JavaScript that is running in your browser has full access to your router’s Web page.

Using this method, we can circumvent the DNS caching mechanism employed by the browser almost instantaneously (we don’t have to wait for anything to time out or reset or whatever). Granted, we still need to log in to the router, or otherwise bypass the login, in order to view or change settings, but we have now completely broken your firewall’s security, your browser’s security, and any anti-CSRF security that may have been implemented in your router’s Web application.

Now, think about the number of people that you know who leave their router’s login set to the default. Now think about the number of routers with security vulnerabilities that allow us to view / change settings without a valid login. Now think about people who change only the administrative login, but leave user accounts set to their defaults (this is basically anyone who uses a D-Link, since even the D-Link set-up CD ignores the unprivileged User account). That’s a lot of people who’s WPA keys we can steal, DNS settings we can configure, VOIP settings we can spy on, etc.

I wish I could say that this was all my idea, but it’s been around since at least 2002. I can say that it works very well however, and on our internal lab it takes less than a second to carry out the attack and glean all of the router’s WiFi security settings in either Firefox 3.0 or IE7. We are working on a tool to help streamline this attack, which we will hopefully have out in the coming weeks, so keep a look out for it.