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.
http://www.infoworld.com/archives/emailPrint.jsp?R=printThis&A=/article/08/08/01/A_photo_that_can_steal_your_online_credentials_1.html
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.
Who says it wont display an image? An applet can render an image and do nothing else. Most users wouldn't know that it was an applet. If the users can anticipate there being an image in that location (often, not always) then it makes sense to keep the subterfuge going.
I won't join Slashcott. OTOH, If Beta goes live, I just won't be back until it's fixed. Sorry Dice.
I think you've misunderstood what the hack is doing here. It isn't someone posting a picture which, when downloaded, infects your computer. This is you uploading a picture which infects the server the next time it is viewed. Basically, it looks like a gif when you upload it, but when the server goes to display the image next time it sees java code instead and runs it; theoretically allowing you to craft a java applet that can pull information off of their servers.
I say theoretically because there's still a quite a few barriers to get this to work, or at least there should be if they've set up their server environment at all correctly.
When a web server deals with image files, it transmits the contents, it doesn't parse them. This is not an attack against servers, but against other end users.
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.
Except the attack fails if the image is modified in any way, fails if the server does minimal validation, *and* it only works in IE because that ignores mime types from the server.
I doubt there's an attack surface worth the effort. You can bet facebook does checks.
As a side note, this exact same problem came up not too long ago when .asf files could be disguised as .mp3's and Windows Media Player would play them. It was a problem because .asf files are insecure.
As another example, you can take any image file that Preview will open, rename it with the extension of any other image file that Preview opens, and both Explorer and Preview will still display it... and Explorer will display no indication that it isn't what the extension says it is. It's not as dangerous as the .asf exploit, because all of the picture formats are already "safe" formats, and you can't disguise a .jar as a .gif in this case - Preview won't launch Java (I tried it), which is apparently the problem with the browser in TFA.
In short, extensions (if they are strictly followed) are a good way to avoid exploits like this. Trying to be clever/helpful by opening a file anyway when the extension is wrong is dangerous. At least Windows Media Player warns you (although it doesn't necessarily indicate that there is any particular danger in opening the file, IIRC).
Alexander Peter Kristopeit bought his basement from his mommy for one dollar.
Obscurity: hiding so that the proper user knows the secret will be allowed in.
password: secret word/phrase. Can be brute forced, cracked, found hiden on a post-it, or just plain guessed at. Absolute worst case puts password at 2^8 per character, minus stated password rules.
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