Friday, April 4th, 2008

Insecure Content Ownership

Taking ownership of someone else’s content is always a tricky deal.  Nate McFeters and I spoke about some of the issues related to taking “ownership” of someone else’s content last year at Defcon, but we continue to see more and more places willingly accepting third party content and happily serving it from their domain.  I came across an interesting cross domain issue based on content ownership that involved Google.  Google has fixed the issue, but I thought the issue was interesting so I’ll share the details… but before I do… I wanted to mention the efforts put forth by the Google Security Team (GST).  Fixing this issue was not trivial… it involved significant changes as to how content was served from Google servers.  Needless to say, the GST moved quickly and the issue was fixed in an amazingly expedient and effective manner… KUDOS to the GST!

    

On to the issue:
I discovered that users could upload arbitrary files to the code.google.com domain by attaching a file to the “issues” portion of a project.  The uploaded file is then served from the code.google.com domain.  Normally, these types of attacks would make use of the Flash cross domain policy file and the System.security.loadPolicyFile() API, however due to the unique path of each project, the cross domain capabilities of Flash are very limited in this instance as policy files loaded via loadPolicyFile() are “limited to locations at or below its own level in the server’s hierarchy”. 

    

Address Bar

     
Flash isn’t the only option here though.  Java has a different security policy and uploading a Java class file to the code.google.com domain gives me access to the entire domain, as opposed to only certain folders and sub folders. 

    

Sounds pretty straight forward huh?  Well, I ran into some issues as the JVM encodes certain characters in its requests for class files made via the CODE attribute within APPLET tags.  After poking around a bit, I realized that requests made via the ARCHIVE would be sent as is, without the encoding of special characters.  With this newfound knowledge in hand, I created a JAR file with my class file within it and uploaded it to code.google.com.

      

Issues Upload

    

Now, the CODE attribute is a required attribute within the APPLET tag, so I specified name of the class file I placed within the JAR file.  When the APPLET tag is rendered, the JVM first downloads the JAR file specified in the ARCHIVE attribute, the JVM then makes the request for the class file specified in the CODE attribute.  In this instance, the request for the class file specified in the CODE attribute will fail as the class file is not on the code.google.com server (even if it was, we wouldn’t be able to reach it as requests made via the CODE attribute are encoded).  The failure to locate the class file causes the JVM to begin searching alternate locations for the requested class file and the JVM will eventually load a class file with the same name located inside of the JAR file…

    

Applet Code  

    

Once the class file is loaded, the JVM will fire the init() method and Java’s Same Origin policy allows me to use the applet to communicate with the domain that served the applet class file (as opposed to the domain that hosts the HTML calling the APPLET tag).  Here’s a screenshot of the PoC page I was hosting on XS-Sniper.com. 

     

Proof of Concept

    
I don’t think there is a tool on the market today that even attempts to detect something like this and I’ve met many “security professionals” that have no idea that vulnerabilities like this even exist.  This isn’t the first time I’ve come across a cross domain hole based on content ownership.  I’m expecting we’ll see a lot more of these types of vulnerabilities in the future as cross domain capabilities becomes more prevalent in client side technologies and as content providers become more and more comfortable in taking ownership of others content.

Posted by xssniper | Filed in Uncategorized

  • http://www.gnucitizen.org pdp

    Excellent, I’ve seen a few of these issues myself and they do work like a charm. For all of you who think that XSS is simply echoing HTML, please take this work as a case study.

    cheers

    P.S. btw, comment tracking via e-mail will be very, very useful thing to have on this blog :)

  • foo

    Why not just upload an html file to code.google.com and once that’s loaded have it call back to your domain?

  • Pingback: Zero Day mobile edition

  • http://xs-sniper.com xssniper

    pdp: Paranioa has set in and I like to see all the comments before they are posted on the page. Not so much to moderate the content… but for other, reasons :)

    foo: It’s not that simple, depending on the content-disposition and the content-type returned by the Google Server, the HTML page wouldn’t be rendered by the browser, it would merely present a download prompt. Luckly, both Flash and Java pretty much ignore the content-type and content-disposition headers (file extension as well). I’ve got another item thats right up your alley though and I’ll discuss it in a later post.

  • foo

    Cool, good stuff. So, did google fix this by hosting the content on a separate domain?

  • xssniper

    foo: Google now serves the files from thier own “safe” domains. The fix wasn’t trival at all, I”m sure it took a significant change to the application logic and server configuration.

  • Venom23

    Did I understand it right…
    1. The Applet loads
    2. searches for the Class-File on the server (due to the codebase attribute)
    3. Does not find it there
    4. finds it in the local JAR file
    5. executes it locally
    6. the local class file is able to access relevant domain data of the current user like it’s password

    how nice …

    is this a general problem with domains hosting applets? If i am able to upload such an applet, wouldn’t this enable me to steal user credentials on any other domain as well?

    what does the local codecrossdomain.class ?

    really impressive

  • xssniper

    @Venom23: The jar file is not local, it was uploaded to the code.google.com server. There was some trickery involved as when the JVM makes the request for the CLASS file found in the CODE attribute, it encodes portions of the request. The ARCHIVE attribute doesn’t have this problem.

    Hosting applets on your domain can be a problem if you expose the wrong functionality. Java’s same origin policy works in a way that allows the applet to communicate with the server that served the applet. So, if you have a URLConnection object that accepts arbitrary URLs in your applet….. you’re asking for trouble. It’s a good point, I may put out some more information about the differences between various Same Origin Policies and some of the nuances of each.

  • Blake Frantz

    April 4th, 2008 at 11:11 am

    xssniper said:

    foo: It’s not that simple, depending on the content-disposition and the content-type returned by the Google Server, the HTML page wouldn’t be rendered by the browser, it would merely present a download prompt. Luckly, both Flash and Java pretty much ignore the content-type and content-disposition headers (file extension as well). I’ve got another item thats right up your alley though and I’ll discuss it in a later post.

    I’ve conducted some initial research on how browsers respond to various content-type, disposition, and content combinations. Results can be found here:

    http://www.leviathansecurity.com/pdf/Flirting%20with%20MIME%20Types.pdf

    Feedback welcome.

  • Pingback: How hosting foreign files risks your users security « BroddlIT

  • Pingback: pbnetworks » Blog Archive » Insecure Content Ownership via Google code

  • Vladimir

    wow, that really is a huge vulnerability in many modern systems, i dont see it being patched anytime soon.

  • Pingback: blafra » Blog Archive » Content Ownership and Validating File Types

  • http://r00tin.blogspot.com rob

    brilliant. i love it when these types of technologies attempt to infer what you were trying to do.

  • wheelq

    Hi,

    is it possible to reveal the code of a jar file? I’m a beginner in java and I don’t know how to read the values from the page that is loading the jar/ class file

  • Rupesh

    Hi,

    Is it possible to share the trickery behind this exploit ? Im wrkin as an application security consultant. I would love to hear more on such explots.

    Regards,
    Rupesh

  • http://www.gmail.com kartheepan

    hi is it possible to restict the request for the resource jar file for applet loading.because we can use the jar file anywhere in our website by calling from applet archive.Hence is there any possiblity for validation of user ownership to verify and provide the jar file in response.