Wednesday, December 17th, 2008

SUN Fixes GIFARs

Last week, Sun released a patch for a vulnerability I reported to them.  The patch I’m talking about fixes the “GIFAR” issue.  I was unable to speak on the issue at Black Hat (for various reasons), but Nate McFeters did a great job of presenting the concept of GIFARs at Black Hat USA along with a simple example of how an attacker could use a GIFAR in an attack.  Now that the issue has been patched, I’d like to cover some of the things related to “GIFARs” that I thought were interesting (including a few items that were not mentioned at Black Hat).

Before we begin, I’d like to thanks Chok Poh from Sun’s Security team.  Chok was vital in fixing the GIFAR issue.  This patch required some significant thought as to how to best handle this issue.  Chok was very responsive and was smart enough to understand the impact of the unusual issue.  I’d also like to thank the Google Security team.  Google was our “guinea pig” for testing some of the pieces related to GIFARs and despite having to redesign some of their application behavior, they were gracious and very worked diligently to protect their users.  Now, on to the show!

As shown by Nate at Black Hat, creating the GIFAR is simple, we simply use the “copy” command on Windows or the “cat” command on *nix.  There are a few different places that talk about this technique (pdp has a great write up), but I first learned of the technique from Lifehacker.com in this post.  Once the GIFAR is created, we examine the file in a HEX editor.  The header of the file looks something like this:

header

The footer looks something like this:

Footer

We now have a file that is both a valid GIF and valid Java JAR.  We now upload our GIFAR to our victim domain (in this case Google’s Picasa Web).  Google attempts to ensure the file is a valid GIF (which it is) and takes ownership of the GIFAR on their domain.  Once Google has taken ownership of the GIFAR, I can reference the applet on my attacking page via the APPLET tag.  I think the items above were well covered at Black Hat and it is these concepts that represent the essence of a generic GIFAR attack… but Google is smart and they understood the dangers of insecure content ownership before GIFAR, so let’s looks at how we bypassed these Google specific protections.

When we first examined the GIFAR we uploaded to Picasa Web, it wasn’t actually served from the google.com domain.  The actual domain it was served from lh4.ggpht.com.  Below is a screenshot of the domain Google was using to serve the user supplied images.

Google Alias

After some investigation, we realized that ggpht.com was actually an alias for google.com.  So, we could manually change our request from lh4.ggpht.com to lh4.google.com.

lh4.google.com

Bingo!  Now we are on a google.com domain!  From here, a lot of attackers begin to think “Java has raw sockets…”.  It’s one of the first avenues we approached, but we quickly discovered that raw sockets aren’t as useful as other techniques.  Instead of raw sockets, we chose to use Java’s HTTPUrlConnection object.  We chose the HTTPUrlConnection object for two very good reasons.  The first reason is HTTPUrlConnection uses the browsers cookies when making request to domains.  So, if our applet is stored on lh4.google.com and the user is signed into Google, we get to piggy back off the victim’s cookies.  We’ll get to the second reason here in a bit.

httpurlconnection1

Now, even though we are now on the google.com domain, we still have a problem.  The Java Same Origin Policy allows the applet to connect back to the domain that served the applet (I’ve covered this behavior before in previous posts).  Considering the applet was served from lh4.google.com, the attacker is allowed to use the applet to connect back to lh4.google.com and only lh4.google.com.  The problem here is lh4.google.com doesn’t store anything interesting.  This problem leads us to the second reason we chose the HTTPUrlConnection object.

Java’s HTTPUrlConnection object has a method named “setRequestProperty”.  Using setRequestProperty we can set arbitrary HTTP headers for our GET and POST requests.  We use the setRequestProperty to set the HOST header for the HTTP request, allowing us to “jump” from the lh4.google.com domain to any other google.com sub domain.  As a simple example, I had discovered a contact list at http://groups-beta.google.com/groups/profile/contacts?out=&max=500 (Google has removed this contact list).  I set the URL object passed to the HTTPUrlConnection object to http://lh4.google.com/groups/profile/contacts?out=&max=500.  I also set the HOST header to groups-beta.google.com.

host

When the request is made, Java checks the value of the URL object to ensure the Same Origin Policy is enforced.  Since the domain of the URL object is lh4.google.com, everything checks out and Java lets the request through.  Once Google receives the request, it checks the HOST header to determine where the resource should be served from.  The HOST header specifies that the resource should be served from groups-beta.google.com, so despite the fact that the URL points to lh4.google.com, Google serves the contact list from groups-beta.google.com.  In this example, I stole a user’s contact list but it could have been any content from a number of Google sub domains.

All your contacts are belong to us

It’s easy to blame Java (Sun) for this issue.  After all, it was their JRE that had a relaxed Jar parsing criterion which allowed GIFARs to be passed as Jars.  In many respects some blame could be placed on Sun, but in my opinion (as humble as it is), this is ultimately a web application issue.  When a web application chooses to take ownership of a user controlled file and serves it from their domain, it weakens the integrity of the domain.  This isn’t the first time an image was repurposed like this, IE has had MIME sniffing issues with images, Flash had crossdomain.xml issues with images, and now we have GIFARs.  The impact of these attacks could have been minimized if web applications that took user controlled files served those files from a “throw away” domain.  As an application developer, you can prevent these types of attacks in the future by using a separate domain for user influenced files.

Posted by xssniper | Filed in Web Application Security

  • Pingback: links for 2008-12-17 (Jarrett House North)

  • kapp

    dude awesome xplanation on GIFAR…really liked the post!!

  • http://rajatswarup.blogspot.com rajat swarup

    As usual awesome stuff man! Reminds me the same situation where the mismatch between proxies and web servers to use different “Content-Length” headers when more than one content-length header was specified to perform cache poisioning attacks. Just that in this case there’s a mismatch between JVM (client side plugin) and the web app in what they consider a valid HTTP request! :-)

  • Pingback: Easy Server Side Fix for the GIFAR security issue « SecureThoughts.com - Inferno's Blog on Application Security

  • http://www.securethoughts.com Inferno

    Hi Billy,

    I have found another server side fix for the GIFAR issue and also referenced this article at my blog
    http://securethoughts.com/?p=35.

    Thanks,
    Inferno

  • Pingback: Top 10 técnicas Web Hacking del 2008 | CyberHades

  • Smitha

    Hi Billy,

    I am student from Penn State working on a project related to some issues in Web 2.0. We were researching this issue and when we tried the patch by Sun (we installed the latest version of Java and updated our JRE) , we found that we could still run Gifars. Could you please shed some light on why this could happen.
    It would also be great if you could give us some insight into how the patch by Sun works to fix this issue

    Thanks,
    Smitha

  • Dave

    Nice to see everyone saying “NICE POST” when they really have no clue of what your talking about.

  • Alain

    You suggest that web sites use a throw-away domain for user uploaded content.

    However, this won’t help for exactly the same reason that it didn’t help in your google example: the malicious user would just use the same conn.setRequestProperty(“Host”, “realdomain.victim.com”); hack that you used in your example.

    So, rather than needing only a throw-away domain, you’d actually need a throw-away server or a least a throw-away IP. Which is lots harder to come by for small website operators.

    And it is the conn.setRequestProperty hack that make this a java bug rather than a website bug. Indeed, conceivably the same hack could be used without any cross-site-scripting vulnerability or chimera file by customers of a virtual hosting service who wish to attack other customers of the same service.

  • Pingback: 10 tecnicas de hacking web: « Hackerpedia.