Slashdot Log In
A Photo That Can Steal Your Online Credentials?
Posted by
ScuttleMonkey
on Fri Aug 01, 2008 02:20 PM
from the free-fear-mongering dept.
from the free-fear-mongering dept.
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.'"
Related Stories
Submission: A photo that can steal your online credentials by Anonymous Coward
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
I can haz ur eebay de-tails? (Score:5, Funny)
Re:I can haz ur eebay de-tails? (Score:4, Funny)
4chan is fucked, /b/ is going to spend all day trying to hack eachother.
Parent
Re:I can haz ur eebay de-tails? (Score:4, Informative)
Wait, aren't they doing that already? Well, between faps anyways...
Parent
Re:I can haz ur eebay de-tails? (Score:4, Funny)
Parent
Re:I can haz ur eebay de-tails? (Score:4, Informative)
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.
Parent
Re: (Score:3, Informative)
Re: (Score:3, Informative)
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
Re:What the hell are you talking about? (Score:4, Informative)
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).
Parent
Re:I can haz ur eebay de-tails? (Score:5, Informative)
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" [wikipedia.org] stuff where the extension is ignored is dangerous.
Parent
Re: (Score:3, Insightful)
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" [wikipedia.org] stuff where the extension is ignored is dangerous.
Then please don't because you have no idea what you're talking about. File extensions are arbitrary, irrelevant, meaningless naming conventions based on absolutely nothing, while "magic" is determined by examining the actual contents of the file.
If you understood what you were talking about and you wanted to label anything "dangerous", you'd be saying that relying on file extensions to convey any serious information about the content of the data is stupid and potentially dangerous. I can name a file any
Re: (Score:3, Interesting)
I knew somebody would flame me for my opinion, but look at the facts.
File extensions are, currently, the sole determining factor that Windows machines use to determine what a file is.
That's a shortcoming of Windows, it's not a shortcoming of other systems such as the magic database.
Yes, but extensions aren't interchangeable. Your malicious .exe won't run if you rename it .pdf. It's a safety feature, and it's very useful.
Then why does malicious Java archive run when you rename it .gif? I thought they weren't interchangable?
Furthermore, on the internet, the extension is the only way a user can tell what a file is.
You can't trust something as arbitrary as a filename, extension or content-type given by a remote server. You have to check the file itself. Now I won't expect an end user to do this manually, which is why the magic database is so useful.
Since TFA states that the server thinks the so-called GIFAR is a .gif, it'll send a content-type: image/GIF header. It's dangerous and stupid for the browser to ignore (1) the .gif extension AND (2) the image/GIF content-type and launch Java.
It's fine for the browser to ignore them because the server cannot be trusted to supply the correct information. It's dangerous and stupid for the browser to run Java code without warning, especially if it allows it to be done from inside the img tag because it can know the data is not a valid image by simply checking it first.
I do think it's a flaw of the server to not verify this itself when storing the so-called image, but it's a bigger flaw of the client to trust every server will do this and no single server will abuse it.
Re: (Score:3, Informative)
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 t
Re:I can haz ur eebay de-tails? (Score:5, Funny)
God only knows what goatse would do.
Talk about a gaping security hole...
Parent
At last, after all my years of searching... (Score:5, Funny)
Re:At last, after all my years of searching... (Score:5, Funny)
I'll be disappointed if the command to begin the attack isn't:
GIFAR, kree!
Parent
please... (Score:5, Funny)
...won't someone think of the PORN!?
Re: (Score:2)
I'm sure they already have.
Re: (Score:2)
Re: (Score:2)
Oh no (Score:4, Funny)
As usual, safe browsing practices protect you (Score:3, Informative)
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.
Re:As usual, safe browsing practices protect you (Score:4, Informative)
Parent
Possibly not. (Score:2, Troll)
First off, what idiot mod'ed you "Troll"?
Secondly, if the user whitelists FaceBook then that would PROBABLY also whitelist the picture/jar that is the exploit which would be downloaded from FaceBook.
Yeah, the security is an issue. At least for right now. It might take a major re-write to kill this exploit. Probably a sandbox where EVERYTHING from a web page would be temporarily stored, then analyzed to see what it was and what the web page reported it as. Probably by digging into the headers of each file an
Advert on hacker message board (Score:2, Funny)
I thought only Windows did this: (Score:5, Insightful)
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).
Re:I thought only Windows did this: (Score:5, Informative)
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 [msdn.com].
Parent
Re:I thought only Windows did this: (Score:4, Informative)
If you missed it, that was a thinly-veiled jab at Apache. Check out Bug #13986 [apache.org]. 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 :).
Parent
Linux (Score:5, Funny)
Thumbnails (Score:2, Insightful)
YouTube? (Score:3, Insightful)
I am very curious whether some similar type of exploit could be used on YouTube uploads. Well, I guess we'll know soon.
print page (Score:2, Informative)
My speculation (Score:2)
This sounds like those tricks where someone writes a code module that compiles in both a C++ compiler and a Pascal compiler, by playing with anomolies in the syntax of the language. Only someone has made a JAR file that looks like a valid GIF file.
I fail to see how this will work though. Even if I could craft such a file, it will have .GIF extension which will make it serve-up as image/gif MIME type so it won't be loaded by the JVM. Now we know that older versions of Internet Explorer will look at the fi
Workarounds for websites (Score:5, Insightful)
* 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.
Re: (Score:3, Insightful)
You're right, of course. Problem is mainly that it's one of those "if everybody does X, all will be fine" solutions.
Right now, all sites that provide for image uploads would need to act or all users would have to disable Java. Reminiscent of the recent DNS caching issue, or 3/4 of the proposed solutions for spam... there's a long turnaround, if it works out at all.
And if we somehow made the applet file format different, more strict to avoid it masquerading as another file type, how would that affect the ji
JAR = ZIP, and GIF+ZIP = old news (Score:5, Informative)
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.
and the fix is also known (Score:4, Insightful)
NEVER EVER TRUST ANY DATA THE USER SUBMITS!
Parent
Re: (Score:2)
We might say the same about you. Try to be considerate and civil, it makes you look like less of a tool.
Re:But What's the Use (Score:5, Informative)
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 [attacker.com] 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.
Parent
Re: (Score:2)
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.
Re:But What's the Use (Score:4, Interesting)
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.
Parent
Re: (Score:2)
The point was to slow the kids down by making them figure out the fine details themselves, giving browsers and image sites time to fortify against this attack.
Re: (Score:3, Informative)
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 i
Re: (Score:2)
Re: (Score:3, Insightful)
How is password protection security through obscurity? I can think of no case where this is true.
Re: (Score:3, Informative)
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.
Re:Mmhhmm....those pesky details... (Score:5, Informative)
Parent
Re: (Score:2, Interesting)
Or Jafar [wikipedia.org]
Jafar's name seems to be derived from a character named Jafar or Giafar in tales of the Arabian Nights, who is the Vizier to the 9th century Abbasid Caliph Harun al-Rashid; this character in turn was based on a real-life vizier, Ja'far bin Yahya Barmaki. Harun and Giafar were the protagonists of many stories in Arabian Nights, but Giafar was never presented as a villain. Harun did have the real Ja'far bin Yahya Barmaki beheaded after a dispute arising from allegations that Ja'far had engaged in an affair with the Caliph's sister. The original tale of Aladdin, a Syrian story not originally attached to the Arabian Nights, features two characters who correspond to Disney's Jafar. One is an unnamed vizier who is jealous of Aladdin but does not serve as a real villain; the other is the major antagonist, an evil magician from the Maghreb in North Africa who introduces Aladdin to his magical lamp.
...
He is shown to be scholarly and learned in arcane lore, his secret chamber filled with strange devices and stacks of tomes, and, as such, he operates more on the level of an alchemist throughout the film's duration than an actual magician. Instead of casting spells, he relies on previously prepared potions capable of producing magical phenomena...
Re: (Score:2)
they are suggesting that BadGuy could upload a 'gif' which is really a jar file to his facebook page.
Then any logged-in facebook user who viewed that 'picture' could have their facebook login cookie stolen.
BadGuy could then use that cookie to look through the private part of your profile, change your password, etc..
Re: (Score:2)
Indeed.
But you can't normally put your own custom applet up and have it downloaded and run from somewhere under, say, facebook.com. This has implications... the simplest to imagine is that your browser will gladly provide facebook cookies to facebook applets--which is why this particularly affects the type of sites where people stay logged
Re: (Score:3, Informative)
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.