On GIFARs

The Black Hat Briefings 2008 are fast approaching. As I mentioned in my previous post on stealing password hashes I am speaking with Nate McFeters and Rob Carter; you can find the abstract for our talk here.

One of the areas that we'll be talking about is some quality research carried out by Billy Rios (Billy was originally speaking due to speak with us but is no longer; he is giving his Bad Sushi talk though, so check it out). Billy realised that you can make a JAR archive look like a GIF image (dubbed a "GIFAR"), or in more general terms, that you can make a JAR look like many other file types. He is not alone in this observation; PDP has also been working on similar ideas. Now many websites allow you to upload specific types of content - images for example. Most web applications will check the extension of the uploaded files and many will also do some content inspection to make sure the file is what the extension says it is.

This means we can upload a JAR on to a publicly accessible page (e.g. a profile page). This has interesting implications. Suppose you end up running malicious content in your browser. Ordinarily it would not be able to fully interact with other websites you might be logged into (CSRF does not constitute full interaction); this is a tenet of the same origin policy implemented by all browsers. However what if the malicious content contains an APPLET tag that references the JAR file uploaded to the target site? The Java browser plugin sees a codebase URL of the target site and consequently adds a SocketPermission allowing the applet to connect back to it and make full requests.

But that is only part of the story. It turns out that when an applet makes an HTTP request to a website the Java browser plugin will slap on the relevant cookies from the browser cookie store (even if the applet is unsigned). This initially surprised me - as far as I can remember older versions of the JRE never supported this. A little digging into how this is accomplished in IE revealed there is a class, com.sun.deploy.net.cookie.IExplorerCookieHandler that contains the following native methods:

JNIEXPORT jstring JNICALL Java_com_sun_deploy_net_cookie_IExplorerCookieHandler_getCookieInfo
   (JNIEnv *env, jobject sender, jstring url)

JNIEXPORT void JNICALL Java_com_sun_deploy_net_cookie_IExplorerCookieHandler_setCookieInfo
  (JNIEnv *env, jobject, jstring url, jstring value)

These methods call the Wininet functions InternetGetCookie and InternetSetCookie respectively. Now if only there was a way of calling these functions with arbitrary URLs... (seriously I don't have one! At least I don't yet.)

So to summarise, once the malicious content references an applet on the target site, it can send arbitrary requests and parse the responses; if you are logged are, these requests will be made with your cookies, giving the applet full control of your account.

Billy's research is getting a fair amount of press (with some creative headlines) prompting Nate to make some further clarifications on his blog. In some of the articles that are appearing credit is wrongly being attributed to me/my employer/Nate/Black Hat hackers/those pesky kids/our new GIFAR overlords and so on, so I'm setting the record straight: this is Billy's baby.

Anyway, that's a brief summary of the issue. Hopefully I'll have time to put out another post before Black Hat. If not, hope to see you there.

Cheers

John