I have been asked recently by
Ronald Koh and some other guys to make a writeup on DNS Pinning, aka. circumventing the same origin policy with Anti DNS Pinning. Although this is nothing really new and some explanations of this do in fact already exist, I think it is a good idea to talk about it once again though for mainly two reasons.
Firstly, this theme is known for it's rather high complexity and only a very limited number of individuals actually understand what is behind it. Therefore bringing peoples attention on it would surely not be amiss.
Secondly, there is no bullet proof solution to protect against this and the more people understand what it is about, the higher are the chances that we'll come to a solution somewhen in future. Four eyes are likely to see better than two, so lets start.
The same origin policy is an access restriction implemented in most modern browsers that prevents a script loaded from one origin to access documents from a different origin in any kind. Hence, it is neither possible to set nor get information from that foreign origin. However, since the time this security measure has firstly been initiated by I believe Netscape, security researchers have spent a significant amount of time to find ways to bypass this restriction. One of the results finally was Anti DNS Pinning and later on Anti-Anti-Anti DNS Pinning, both exploiting another security mechanism of modern browsers called DNS Pinning.
Now it may sound reasonable to start explaining what DNS Pinning actually is, fortunately this turns out pretty easy with a bit of background information on the Domain Name System (DNS). When someone requests a Web site such as www.example.com, the browser needs to perform a DNS lookup on that domain to get the associated numerical address (IP) of the server that hosts the Web site in question. In the next step, the browser sends a query to that IP that moreover contains the domain, a specific Web page and other variables to be able to ultimately retrieve the requested data.
So lets assume the DNS lookup on www.example.com provided the IP 111.111.111.111. A normal HTTP request sent by the browser to www.example.com may look like this:
GET / HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.4) Gecko/20070515 Firefox/2.0.0.4
Accept: */*
Accept-Language: de-de,de;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Cookie: secret authentication token 12345
This is where DNS Pinning comes into play. As a protection attempt against Anti DNS Pinning, the browser caches the hostname-to-IP address pair until the browser window gets closed, regardless of what the actual DNS time to live (TTL) is set for. I have visualized a scenario that DNS Pinning protects against below. In this example an attacker runs www.attacker.com pointing to IP address 222.222.222.222.
Moreover he has full access to the DNS server entry, which is set to a TTL (DNS timeout) of 1 second. When viewing his Web site in a browser, malicious JavaScript will be executed that tells the browser to connect back it's current location in 2 seconds and then pull the returned data to a different server the attacker controls.
1) The users browser connects to www.attacker.com and performs a DNS lookup for that URL receiving 222.222.222.222 with a TTL of 1 second.
2) JavaScript tells the browser to connect back to www.attacker.com after two seconds, shortly after the TTL expired.
3) Since the DNS is not longer valid, the user's browser connects to the DNS server to ask where www.attacker.com is now located.
4) The DNS server responds with 111.111.111.111, which points to www.example.com
5) The user's browser connects to 111.111.111.111 sending a header like:
GET / HTTP/1.1
Host: www.attacker.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.4) Gecko/20070515 Firefox/2.0.0.4
Accept: */*
Accept-Language: de-de,de;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Now what is important to notice here is that the host has been changed to www.attacker.com instead of www.example.com and furthermore the cookie is missing. Due to the cached hostname-to-IP pair, DNS Pinning prevents the second lookup of www.attacker.com which is why this attack was doomed to fail from the very beginning.
Anti DNS Pinning
As already mentioned earlier, Anti DNS Pinning is what DNS Pinning was meant to protect against - forcing the browser to request a manipulated DNS entry again e.g. by making him believe that his cache expired.
Well, on August 14, 2006,
Martin Johns came up with a concept of how this can be done. He essentially discovered that DNS Pinning only works on condition that the Web server in question is actually online and available. On the one hand this makes sense because if the server appears to be down, a new DNS lookup is necessary to find out whether it has changed or moved in some way. However on the other hand an attacker can shut down his server whenever he wants to and thereby circumvent the user's browser's DNS Pinning. Again, I have visualized this attack:
1) The users browser connects to www.attacker.com and performs a DNS lookup for that URL receiving 222.222.222.222 with a TTL of 1 second.
2) JavaScript tells the browser to connect back to www.attacker.com after two seconds, shortly after the TTL expired. Afther that the server is told to firewall itself.
3) Now DNS Pinning is dropped due to Anti DNS Pinning. Since the DNS is not longer valid, the user's browser connects to the DNS server to ask where www.attacker.com is now located.
4) The DNS server responds with 111.111.111.111, which points to www.example.com
5) The user's browser connects to 111.111.111.111 sending a header like:
GET / HTTP/1.1
Host: www.attacker.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.4) Gecko/20070515 Firefox/2.0.0.4
Accept: */*
Accept-Language: de-de,de;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Since the IP changed now, the attackers XMLHttpRequest is reading a different Website (www.example.com), even though the browser believes it is still the same. So now you may understand why I introduced this article with explaining what the same origin policy is. We are able to break it using Anti DNS Pinning.
Anyway, again there are a few things to notice. Firstly, the host is still changed to www.attacker.com instead of www.example.com, plus there is no cookie data sent in the header. Taking this into account one may wonder why anyone would do Anti DNS Pinning instead of requesting www.example.com on foot.
Well, in fact Anti DNS Pinning isn't doing the attacker any good unless we are talking about an intranet or otherwise IP restricted websites, which the attacker could usually not connect to himself because the site is just inaccessable to the public. This is where Anti DNS Pinning becomes really dangerous. Instead of targeting www.example.com, we could possibly launch an attack against intranet.example.com, which was actually considered to be secury since it is hosted behind a corporate firewall.
Not only we can read data from those protected pages but also use the so gained information to launch CSRF attacks against intranet applications. Pretty bad.
Kanatako provided a well working example of this on his Website. I recommend to check this out:
http://www.jumperz.net/index.php?i=2&a=1&b=7Additionally he
describes on sla.ckers.org how his script works in detail. If you read it carefully, you will see that it is exactly what you have just learned while reading.
Anti Anti DNS Pinning
The name already suggests what this technique is about. Some people starting thinking about how Anti DNS Pinning could be prevented and ended up with checking for the correct the Host header. Remember that this has always been changed to www.attacker.com and so indicates an attack.
Certainly not because it is always www.attacker.com but simply because the Host header differs from the one(s) that has been allowed by the server administrator.
Anti Anti Anti DNS Pinning
Unfortunately this header can easily be spoofed in more than one way so that the previously described technique doesn't turn out to be very effective. Amit Klein published a posting to Bugtraq where he showed how to spoof the Host in MSIE using XMLHttpRequest or Flash.
var x = new ActiveXObject("Microsoft.XMLHTTP");
x.open(
"GET\thttp://attacker.com/\tHTTP/1.0\r\nHost:\twww.example.com
\r\n\r\n,
"http://www.attacker.com/",
false
);
x.send();
alert(x.responseText);
I hope that this article could help you to get a better understanding of DNS Pinning and it's mutations. However if you think that this is just a theoretical construct, you're still very much mistaken. Check out
RSnakes stories, especially
Death By 1000 Cutts.
Good stuff!
Aviv Raff On .NET
(22 unread)
CGISecurity.com: Your Web Site and Application Security Resource (125 unread)
christian's weblog (25 unread)
Irongeek's Security Site (159 unread)
Jeremiah Grossman (85 unread)
milw0rm.com (520 unread)
Packet Storm Security Advisories (440 unread)
SecuriTeam.com (262 unread)
Security Vulnerability Research & Defense (47 unread)
SecurityFocus News (173 unread)
Securityvulns news channel (407 unread)
Taking Network Security to the Streets (28 unread)
The Register - Security (594 unread)
IceСμbeς (15 unread)
Linmagazine (281 unread)
netcraft Bytes :) (47 unread)
Digg (4381 unread)
----- Anti-Malware ----- Analysis and Defense (16 unread)
Apple Fun (25 unread)
Technorati Search for: aviv.raffon.net (263 unread)
Determina Zero-Day Protection (6 unread)
Security - RSS Feeds (265 unread)
Exploit Prevention Labs (28 unread)
Software Vulnerability Exploitation Blog (22 unread)
F-Secure Antivirus Research Weblog (109 unread)
George Ou (10 unread)
heise security (468 unread)
invisiblethings' blog (35 unread)
JScript Blog (18 unread)
PandaLabs (52 unread)
SecuriTeam Blogs (85 unread)
Security Fix (163 unread)
HP ASC Portal (30 unread)
Sunbelt Blog (296 unread)
Wired: Threat Level (626 unread)
WabiSabiLabi's blog (23 unread)
WatchGuard Wire (58 unread)
Errata Security (90 unread)
PaulDotCom Community Blog (12 unread)
Billy (BK) Rios (23 unread)
Farfromr00tin (23 unread)
aut disce, aut discede (17 unread)
pwn* (16 unread)
SecurityDot Vulnerabilities (525 unread)
