Anti-DNS Pinning and Java Applets

[David Byrne <davidribyrne () yahoo com>]

This was reported to Sun on July 2nd, but I have not received a response. I do not consider these to be critical 
vulnerabilities, which gives me a clean conscience for disclosure. 

David Byrne



Anti-DNS Pinning and Java Applets

-------------------------------------------------------
Introduction
-------------------------------------------------------
DNS pinning is a technique HTTP clients use to prevent DNS spoofing attacks that would otherwise defeat the browser’s 
same origin policy [1]. Anti-DNS pinning attacks are intended to bypass these controls, essentially turning the client 
into a proxy server [2,3]. In what was probably the earliest documented technique, in 1996, Princeton researchers 
discovered a way to cause an untrusted Java applet to connect to an arbitrary host [4]. This was quickly corrected by 
Sun [5]. More recently, Martin Johns and Kanatoko Anvil documented that LiveConnect [6] in Firefox or Opera allows for 
a similar attack [7].

I have documented two related methods for successful anti-DNS pinning attacks using Java applets. The methods 
documented below work with Firefox 2 and Internet Explorer 7 running either Java 1.5 or 1.6.

-------------------------------------------------------
Standard JVM DNS Behavior
-------------------------------------------------------
Typically, an applet is loaded by the following series of events:
1.    The browser resolves the hostname via DNS, and pins the result in its cache
2.    The browser requests the HTML file from the web server. 
3.    If there is an <APPLET>, <EMBED>, or <OBJECT> tag referencing a Java applet, the JVM is loaded, and passed the 
path to the applet, and the origin server of the HTML document.
4.    The JVM initializes, resolves the origin server’s name and pins the result in its cache.
5.    The applet file (usually .jar or .class) is requested from the server and run.
6.    If the applet is untrusted [8], socket connections are (or at least should be) limited to the origin server, but 
allowing any port.

-------------------------------------------------------
Princeton Attack Summary
-------------------------------------------------------
The Princeton attack [5] showed that the JVM was basing its same-origin policy on the DNS response, not on the actual 
IP address of the origin server. The attack sequence follows:
1.    Victim browser visits a malicious site/domain, and downloads HTML referencing the attack Java applet
2.    The JVM is loaded, and passed the path to the applet
3.    The JVM queries DNS for the server hosting the applet
4.    The attack DNS server responds with two IP addresses; the first belongs to the attack web server, and the second 
belongs to the victim server, presumably on a private network
5.    The JVM loads the applet (class or JAR file) from the attack web server
6.    The applet requests a socket connection to IP address of the victim server
7.    Because the second IP address matches the origin server’s DNS record, the JVM allows the connection

This was Sun’s response [6]
“A fix for the applet security manager is to be more strict about deciding which computers an applet is allowed to 
connect to. The Java system needs to take note of the actual IP address that the applet truly came from (getting that 
numerical address from the applet's packets, as the applet is being loaded), and thereafter only allow the applet to 
connect to that exact same numerical address.”

As the following methods show, recent versions of the JVM do not exhibit this behavior.

-------------------------------------------------------
Princeton Attack – Same Subnet
-------------------------------------------------------
The Princeton attack is still possible with current versions of Java when both IP addresses returned by the DNS server 
are on the same subnet as the client. No reverse lookups, etc. are required. This isn’t a new attack per se, or a very 
large threat, but is revealing about how the JVM’s DNS pinning functions. 

-------------------------------------------------------
Method 1: Modified Princeton Attack – PTR Records
-------------------------------------------------------
As described above, if two IP addresses are supplied for the origin host name by DNS, the JVM will automatically allow 
connections to the first address. If the applet tries to connect to the second address, the JVM performs a reverse DNS 
lookup for both addresses. If the results match the sequence below, the connection is allowed. Thus, if an attacker 
controls the client’s resolving DNS server, or if the DNS server is vulnerable to cache poisoning, matching PTR records 
can be supplied. 

Attack hostname host1 resolves to IP1, IP2
Reverse lookup on IP1 resolves to host2 (can be the same as host1)
Reverse lookup on IP2 resolves to host2
Host2 resolves to IP1 and IP2

Because this requires a secondary vulnerability to allow DNS control, the threat can be significantly limited by using 
good DNS practices. This does not necessarily represent a defect in the JVM.

-------------------------------------------------------
Method 2: Proxy Bypass
-------------------------------------------------------
If the JVM is configured to use an HTTP proxy server, it will still attempt to resolve the origin server hostname 
through DNS, but will retrieve the applet through the proxy server. With this method, the attack DNS server sends the 
proxy server an IP address for the attack web server, but sends the JVM the IP address of the victim host. This allows 
the JVM to successfully retrieve the applet, but causes it to pin the victim’s IP address in its cache. When it loads, 
the applet can establish arbitrary socket connections to the victim.

This can be easily prevented by not allowing internal network resolution of Internet domains through DNS. This can also 
be corrected by changing the JVM behavior to disable DNS resolution of the origin server when a proxy is in use, or 
disabling socket support altogether.

-------------------------------------------------------
References 
-------------------------------------------------------
[1] http://www.mozilla.org/projects/security/components/same-origin.html
[2] http://viper.haque.net/~timeless/blog/11/
[3] http://shampoo.antville.org/stories/1451301/ 
[4] http://www.cs.princeton.edu/sip/news/dns-scenario.html
[5] http://www.cs.princeton.edu/sip/news/sun-02-22-96.html
[6] http://developer.mozilla.org/en/docs/LiveConnect
[7] http://shampoo.antville.org/stories/1566124/
[8] http://java.sun.com/sfaq/






       
____________________________________________________________________________________
Get the Yahoo! toolbar and be alerted to new email wherever you're surfing.
http://new.toolbar.yahoo.com/toolbar/features/mail/index.php

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/