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.'"
Just imagine - something as innocent as lolcats could be a potential minefield. God only knows what goatse would do.
I warned you all! I've known for years the bad guy from Aladdin would eventually tire of stealing stuff from mysterious caves and start breaking into computers!
"A witty saying proves nothing." - Voltaire
...won't someone think of the PORN!?
The "cue the foo posts in 3, 2, 1..." posts will commence with no subsequent foo posts in 3, 2, 1...
As if tub girl wasn't insidious enough... Now she's going to steal my accounts?
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.
The mime type says "GIF", but if it looks executable, try to run it anyway. Or maybe it is just Windows. TFA didn't mention which software does this (other than "the browser"). At one point they blame Sun. Huh? Does the GIF have an applet tag? Or does this attack involve running a malicious applet at evil.com, which then loads a JAR from facebook.com (which was uploaded as a GIF) and the JRE runs it as if it came from facebook. *That* would be a Sun problem (and not a "browser" problem).
Well, this proves it again, by making Java so hard to install, Linux avoided yet another threat.
Taxation is legalized theft, no more, no less.
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.
* resize the image
* crop the image 1x1 pixel smaller
* convert the GIF(ar) to PNG or JPG
* optimize the GIF file
* shrink/reorder the color palette
* edit the comments
Gosh.. really, anything that affects the actual data package, but doesn't visibly hamper valid pictures.
Support FSF: Stop thinking with your wallet, and think with your imagination. (cc/non-commercial)
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.
NEVER EVER TRUST ANY DATA THE USER SUBMITS!
MMO Quests are like orgasms:
You may solo them, I prefer them in a group.
The part I don't get, is that images.somesocialsite.com is presumably sending it as an image/gif mimetype, so why is the browser running it (passing it to the JVM)? This sounds like a browser bug.
I'm guessing you have it backwards. The referencing webpage marks up the file as a Java object. I imagine the GIF part is to get past the socialsite server's image validity tests so that it will agree to host the file.
In my experience, the server should be sending the file with a MINE type of image/gif, so the brwoser should be treating the file as a GIF.
Something I actually tried to do, once:
I uploaded an SVG image to an image hosting website. But, the website, not "knowing" what a SVG file is, sent "Content-type: text/plain". (SVG is XML based, so is actually text.) Several web browsers, including FF and others, dutifully displayed the actual XML text.
I then tried making a webpage included the type attribute, specifiying "xml/xml+svg". The web browsers continued to display the XML text.
Given this observed behavior, I would expect that, when servering up a GIF file, either the server failed to include "Content-type: image/gif", or the browser ignored the contact type from the server. Either of these, IMHO, is a bug.
PS, FYI, I ultimately got the SVG file to be displayed correctly by re-uploading it as an XML file. The server then sent "Content-type: xml/xml" and the web browsers figured out what to do with it.
Don't try to out wierd me, three-eyes. I get stranger things than you, free with my breakfast cereal. --Zaphod Beeblebr
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).