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.
"Upgrade to a hybrid today and get 20% more mileage on your phishing messages"
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.
What site doesn't resize the uploaded image for display? That wouldn't result in "compressed code" it would just be an image.
I am very curious whether some similar type of exploit could be used on YouTube uploads. Well, I guess we'll know soon.
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.
Wow...RTFA...I was way off. But I don't quite understand what would make Java open these image files... Do they have ".jar" extensions? shouldn't facebook and the like be...I don't know...not allowing those?
* 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.
How is password protection security through obscurity? I can think of no case where this is true.
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
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.
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).