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 126.96.36.199 www.l.google.com. 82 IN A 188.8.131.52 www.l.google.com. 82 IN A 184.108.40.206 ;; 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: 220.127.116.11#53(18.104.22.168) ;; 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 22.214.171.124 IP address; if that doesn’t work, it will try 126.96.36.199 and finally 188.8.131.52. 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 184.108.40.206 www.myevilsite.org 82 IN A 192.168.1.1
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.