[Full-disclosure] Anti-DNS Pinning and Java Applets

[David Byrne <davidribyrne@xxxxxxxxx>]

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/