Monday, 18 February 2008

DNS rebinding attacks

There are many ways to attack DNS. Attacks range from denials of service (DOS), to man in the middle (MIM), to spoofing. The recent inclusion of Unicode entries into DNS may mean a site that looks like 'microsoft.com' could exist but actually point to something else. Perhaps the o's in Microsoft would be Cyrillic instead of Latin. Such attacks are a concern but are beyond the scope of this paper.

The focus of this section of the paper is an attack originally known as the Princeton attack and its derivatives. The Princeton attack is a DNS based attack on JavaScript's domain based security scheme. It's normally accepted that the Princeton attack can not be barred by a useragent and needs to be solved by firewalling. This does not mean that useragents should not attempt to protect against the attack. 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 a solution will be found.

Note: I have “picked on” keygen.us as this is a known spyware site active in the distribution of software cracks and other illegal material. In fact, the site attempts to load a number of Java and other applets for this and other attacks.


What is the same-origin policy?
The same origin policy prevents document or script loaded from one origin from getting or setting properties of a document from a different origin. The policy dates from Netscape Navigator 2.0.

Mozilla considers two pages to have the same origin if the protocol, port (if supplied in the call), and hostname are the same for both pages.


For instance, assume a script in the document at http://store.microsoft.com/dir/other.html executes this statement:
document.domain = "microsoft.com";
After execution of that statement, the page would pass the origin check with http://microsoft.com/dir/page.html.

However, using the same reasoning, company.com could NOT set document.domain to othersite.com.


What is DNS Pinning?
DNS Pinning involves storing the DNS host lookup result for the lifetime of the browser session. The basis of this attack is old. It was described by the Princeton University in 1996.
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. Security researchers have spent a significant amount of time to find ways to bypass this restriction. One result was Anti DNS Pinning and later on Anti-Anti-Anti DNS Pinning, both exploiting a security mechanism of modern browsers called DNS Pinning.

First we need to explain what DNS Pinning is. This requires a bit of background information on the Domain Name System (DNS). When someone requests a Web site such as www.microsoft.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. microsoft.com provided the IP 207.46.193.254. A normal HTTP request sent by the browser to www.microsoft.com may look like this:

  • GET / HTTP/1.1
    Host: www.microsoft.com
    User-Agent: Windows-RSS-Platform/1.0 (MSIE 7.0; Windows NT 5.1)
    MSIE /7.0
    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
Now for DNS Pinning. 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 to. See the example below where an attacker runs keygen.us pointing to IP address 85.17.52.48.


The attacker 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 keygen.us and performs a DNS lookup for that URL receiving 85.17.52.48 with a TTL of 1 second.
  2. JavaScript tells the browser to connect back to keygen.us 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 keygen.us is now located.
  4. The DNS server responds with 207.46.193.254, which points to http://www.microsoft.com/
  5. The user's browser connects to 207.46.193.254 sending a header like:
  • GET / HTTP/1.1
    Host: keygen.us
    User-Agent: Windows-RSS-Platform/1.0 (MSIE 7.0; Windows NT 5.1)
    MSIE /7.0
    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

    Notice that the host has been changed to keygen.us instead of www.microsoft.com and furthermore the cookie is missing. Due to the cached hostname-to-IP pair, DNS Pinning prevents the second lookup of keygen.us.
Normally requests from code embedded in web pages (JavaScript, Java, Flash) are limited to the website they are originating from (same-origin policy). DNS rebinding attack can be used to improve ability of JavaScript based malware to penetrate private networks, subverting the same-origin policy.


Anti DNS Pinning (Re-binding)
Anti-DNS Pinning is what DNS Pinning was meant to defend against. This involves forcing the browser to request a manipulated DNS entry again e.g. by making it seem that the cache expired.DNS Pinning only works on condition that the Web server in being accessed is online and available. This is a result of the belief that if the server appears to be down, a new DNS lookup is necessary to find out whether it has changed or moved. However, an attacker can shut down any server that the attacker controls any time desired to and thereby circumvent the user's DNS Pinning in the browser.
  1. The users browser connects to keygen.us and performs a DNS lookup for that URL receiving 85.17.52.48 with a TTL of 1 second.
  2. JavaScript tells the browser to connect back to keygen.us after two seconds, shortly after the TTL expired. After this the server is instructed to firewall itself.
  3. Now DNS Pinning is dropped due to Anti DNS Pinning. As the DNS is no longer valid, the user's browser connects to the DNS server to ask where keygen.us is now located.
  4. The DNS server responds with 207.46.193.254, which points to http://www.microsoft.com/
  5. The user's browser connects to 207.46.193.254 sending a header such as:
  • GET / HTTP/1.1
    Host: keygen.us
    User-Agent: Windows-RSS-Platform/1.0 (MSIE 7.0; Windows NT 5.1)
    MSIE /7.0
    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

As the IP address has changed, the attackers XMLHttpRequest is reading a different Website (www.microsoft.com), even though the browser believes it is still the same. We are able to break same-origin provisions for Javascript etc using Anti DNS Pinning.

Note however, that the host entry has changed to keygen.us instead of www.microsoft.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 http://www.microsoft.com/. As a consequence, Anti DNS Pinning isn't doing the attacker any good unless the attack is against an intranet or otherwise IP restricted websites, which the attacker could usually not connect to himself because the site is just inaccessible to the public.

This is where Anti DNS Pinning becomes dangerous. Instead of targeting www.microsoft.com, we could possibly launch an attack against intranet.microsoft.com, which was actually considered to be secure being that 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.

Anti Anti DNS Pinning
The name already suggests what this technique is about. Attackers and Researchers have started to investigate how Anti DNS Pinning could be prevented and have resulted with the checking of the correct the Host header. Remember that this has been changed to keygen.us and so indicates an attack.

Not only because it is keygen.us but simply because the Host header differs from the one(s) that has been allowed by the server administrator.

Anti Anti Anti DNS Pinning
Regrettably the header can easily be spoofed using a variety of methods. Thus the previously described technique is not very effective.

Amit Klein published a posting to Bugtraq demonstrating how to spoof the Host in Microsoft Internet Explorer using XMLHttpRequest or Flash.

  • <*script>var x = new ActiveXObject("Microsoft.XMLHTTP");x.open("GET\thttp://attacker.com/\tHTTP/1.0\r\nHost:\twww.microsoft.com\r\n\r\n,"http://keygen.us/",false);x.send();alert(x.responseText);<*/script>

The first question is why?
You visit a site (say you decided that you need a key for that software you downloaded without considering the ethical considerations of not paying). While you are getting the key off the Web page JavaScript code is downloaded and executed by your Web browser. The script scans your entire internal network, detects and determines your Linksys router model number, and then sends commands to the router to turn on wireless networking and turn off all encryption.
This is why rebinding has again become a current issue. It lurked in obscurity for about a decade following the original Princeton attack, but with ad nets and client attacks all the rage, it has again reared its ugly head. So what and why?

Javascript has built-in restrictions to limit abuse - “Same Origin Policy”. This will only allow a script to interact with the site from which it originated by default.

The issue occurs when there was one site on the Internet where a user could download content from multiple sites. This can occur as a result of Translation sites, proxies, etc.

DNS Re-binding is an attempt to subvert the “same origin” policy in a browser. It is based on changing DNS resolution on-the-fly, to alter what the browser considers to be “same origin”. This allows an attacker to “drop” an attack behind a firewall effectively bypassing it.
No re-binding from a-non RFC 1918 address to an RFC 1918 address is allowed, but beyond this, the fixes tend to break little, unimportant things like “Akamaized” websites (see http://research.microsoft.com/~ratul//akamai.html).

Browser doesn’t know microsoft.com from the external IP is any different from microsoft.com from the internal IP by design.

Major web sites have IP addresses spread across the world, and resources acquired from them need to be able to script against one another. Detecting that there’s a cross-IP scripting action happening is only the beginning – what to do after that is what people are trying to figure out


Varieties of DNS Rebinding attacks
What this attack can do?
  • Circumvent firewalls to access internal documents and services.
  • Sending spam and defrauding pay-per-click advertisers.
  • Obtain the (internal) IP address of the hosting web browser
  • Port scan the LAN to locate intranet http servers
  • Fingerprint these http servers using well known URLs
  • And (sometimes) to exploiting them via CSRF (Cross-site request forgery).
Defending Against DNS Rebinding
There are a number of possible solutions:
  • You can defend against these attacks for a site by
  1. disabling the Flash plug-in,
  2. disabling JavaScript, and
  3. disabling any other plug-ins.
  • Implement both host-based (or personal) firewalls in conjunction with a gateway system to restrict browser access to ports 80 and 443. On internal systems, allow access to the
  • Internet through a corporate proxy and not from each host.
  • Ensure that all websites you manage do not utilise a default virtual host, but instead require a valid Host header.

No comments: