Slashdot Mirror
A Photo That Can Steal Your Online Credentials?
TedSamsonIW writes "InfoWorld reports on a new potential ploy for stealing Web user's private information: Researcher has found that by placing a new type of hybrid file on Web sites that let users upload their own images, they can circumvent security systems and take over Web surfers' accounts. 'They call this type of file a GIFAR, a contraction of GIF (graphics interchange format) and JAR (Java Archive), the two file-types that are mixed. At Black Hat, researchers will show attendees how to create the GIFAR while omitting a few key details to prevent it from being used immediately in any widespread attack.'"
There's no actual pictures involed though, just a java applet masquerading as a gif file to the browser (so no kitties harmed). Now, they could give a user a link saying, "Here bez sum picz of lolcatz, come lookz," which would then cause them to "download" what they think is a gif (though it will never show an image). I'm not sure about others, but I tell my browsers to ignore java. Anything written as a java applet is not worth viewing anyways, aside from security risks.
Things like a properly constructed white-list for Noscript, not allowing Java by default, etc. will all protect you from this.
It's a shame that security tools that can help mitigate some of these attacks are difficult to understand and use for many users.
Wait, aren't they doing that already? Well, between faps anyways...
For large sets, this will be our guide even unto death, for the LORD will work for each type of data it is applied to...
it sounds like what they are doing is creating a specially crafted Java archive (jar) that is disguised as a gif. You upload it to a site, the site stores it on their domain eg: images.somesocialsite.com The attacker would then make a webpage on his site, http://attacker.com/loadgar.html and in it would tell it to include the jar file from images.somesocialsite.com - in this situation the jar would be considered to be "from" the images.somesocialsite.com which would put it in the proper zone to be able to read *.somesocialsite.com cookies.
Security through obscurity does, in fact, keep things secure for a period of time. Hell, password protection is security through obscurity.
This is sort of a weak attack, if I understand what they're doing. The web browser sees the file as an image when you upload it. The server, on the other hand, sees it as a JAR file, and when it is accessed the next time, executes it. If it works, this is a pretty decent hack, but to actually get user information, you'd need a bit more info. First, they need the JVM installed on the server (which they probably have, but it's not a given). They also need a database schema, an open hole to get the information back to the hacker, and most importantly, DB passwords. So, even if this comes out 0-day, your myspace profile is probably safe.
In terms of creating something which is both a gif and a jar, it's a simple case of cat myimg.gif myapplet.jar. The fact that you can cat a gif and a zip file and get something which conforms to both specifications has been known for years. The interesting bit will be the way they turn the Facebook img tag into an applet tag or otherwise persuade the browser to execute the applet.
The article was light on details, but it sounds like an extension of a known attack, and if this is the case, then it's not Windows, but Internet Explorer. Internet Explorer ignores the Content-Type header in various circumstances, in violation of the HTTP 1.1 specification.
This matters because services like Facebook serve these fake "images" provided by their users to Internet Explorer and explicitly tell Internet Explorer that they are images. Internet Explorer then happily ignores them and tries to guess what type of file it is on its own. If the file looks a bit like HTML and you click on a link to it, Internet Explorer will happily execute Java and JavaScript on that page within the security context of the domain serving it.
If you've wondered why these types of services force you to save images when you try to view them outside of the context of a web page, now you know why. It's because it's the only reliable way to ensure that Internet Explorer doesn't execute it. Think of it as a straight-jacket to stop a mentally ill person from hurting themselves.
It's okay though, Microsoft are fixing the issue in Internet Explorer 8. By making Internet Explorer respect the HTTP 1.1 specification? Of course not! By adding a new proprietary header attribute.
Bogtha Bogtha Bogtha
JAR files are just ZIP archives. ZIP archives are based on the end of the file, where the central directory is located (this is also why you can often unzip a self-extracting exe using a normal unzip application). GIF files, like most other files, are based on the beginning of the file. ZIPs don't care if you shove data in front of them. GIFs don't care if you shove data after them.
$ cat file.gif file.zip > file.gizip .gif or .zip. Both work. You can also substitute JPG instead of the GIF, or any other file type that ignores trailing garbage.
Rename the result to
I'm not sure if there's some kind of trick that is needed for the exploit to work, but the fact that you can make a file that works both as a zip and as almost any other file type has been known for ages.
There's no actual pictures involed though, just a java applet masquerading as a gif file to the server (so no kitties harmed).
You're slightly mistaken. The server thinks it's a GIF; the browser figures out that it's actually an applet and starts Java. Since it's coming from the same server, the applet is able to interact with the rest of the page and see the site's cookies, and it can then transmit whatever stuff it discovers to a third party. As you said, not having the Java plugin would thwart the attack.
Also, I hate to get on my soapbox, but file extensions are a good thing. In this case, the extension is the only thing that the user has to tell them what sort of content is being delivered... when the file type doesn't match the extension (or MIME type), the browser should complain. This "magic" stuff where the extension is ignored is dangerous.
Alexander Peter Kristopeit bought his basement from his mommy for one dollar.
If you missed it, that was a thinly-veiled jab at Apache. Check out Bug #13986. You know you aren't doing well when an author of the HTTP 1.1 specification shows up on your bug tracker to post a "WTF?" comment :).
Bogtha Bogtha Bogtha
Correct. The code hidden in the image file will be executed by whatever browsers view it, not executed by the server. Even if the server does parse it, it would just be looking for a signature. It has enough similarity to fool the server into thinking its a valid GIF file, but the end users browser will render it as a JAR file (or possibly both).