Message-ID: <431920.16268.qm@web34304.mail.mud.yahoo.com>
Date: Mon, 9 Jul 2007 19:29:29 -0700 (PDT)
From: David Byrne <davidribyrne@...oo.com>
To: full-disclosure@...ts.grok.org.uk
Subject: Anti-DNS Pinning and Java Applets

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/

Powered by blists - more mailing lists