Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×
Security IT

A Photo That Can Steal Your Online Credentials? 235

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.'"
This discussion has been archived. No new comments can be posted.

A Photo That Can Steal Your Online Credentials?

Comments Filter:
  • by Channard ( 693317 ) on Friday August 01, 2008 @03:23PM (#24438833) Journal
    Just imagine - something as innocent as lolcats could be a potential minefield. God only knows what goatse would do.
    • by Anonymous Coward on Friday August 01, 2008 @03:25PM (#24438869)

      4chan is fucked, /b/ is going to spend all day trying to hack eachother.

    • by ya really ( 1257084 ) on Friday August 01, 2008 @03:30PM (#24438997)

      Just imagine - something as innocent as lolcats could be a potential minefield. God only knows what goatse would do

      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.

      • .. but just think about how many people happily forward links to all their friends? Who then happily click on the links. Granted, your average Slashdot reader might be too IT literate to fall for this, but Joe Public certainly isn't.
      • Re: (Score:3, Informative)

        by gd2shoe ( 747932 )
        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.
      • Re: (Score:3, Informative)

        by MozeeToby ( 1163751 )

        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

      • by clone53421 ( 1310749 ) on Friday August 01, 2008 @05:00PM (#24440719) Journal

        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.

        • The opposite is true - for this to work the extension must be wrong and the server must not use any fingerprinting the validate the file (just looking for GIF89a at the start is normally enough).

          Ignoring the extension is precisely what should be done.. the server is accepting a .jar just by renaming it as a .gif therefore the server is broken.

          • No, for it to work, the browser needs to ignore the .gif extension - and the MIME-type sent by the server that says "this is an image/GIF" - and say "hey, this looks like an applet, better fire up Java!"

            • Both the server and the browser should check that the content and the extension are consistent. Furthermore, the server should enforce consistency on both upload and download.

              • Frankly, it wouldn't really matter IF the browser would quit trying to be so "helpful". If the server says "this has a .gif extension, I'll send it using content-type: image/GIF", and if the browser would (1) require anything in an <IMG> tag to be an image and (2) require anything with a .gif extension or a content-type: image/GIF header to be opened as a .gif, this exploit wouldn't be possible: you'd just get a broken picture icon.

                • Re: (Score:3, Informative)

                  by clone53421 ( 1310749 )

                  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

                • What would be good is what I proposed _years_ ago:

                  http://osdir.com/ml/mozilla.security/2002-10/msg00029.html [osdir.com]

                  Then even if someone manages to slip in javascript or other html naughties into an allowed content-type=text/html that's uploaded or emailed to the site, it still won't work on the target's browser.

                  (if the browser supports the feature, and the website encloses all stuff that _should_ be "plain old harmless stuff" with such tags).

                  Basically when the browser sees such tags, it will go "Ah, between these

        • Re: (Score:3, Insightful)

          by mopower70 ( 250015 )

          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

          • 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.

            I can name a file anything I want.

            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. "Hide file extensions" is dangerous for this very reason: "readme.pdf.exe" looks like "readme.pdf" and that's just WRONG. If they'd get rid of that stupid "feature", then "readme.pdf" wou

            • Re: (Score:3, Interesting)

              by Rob Kaper ( 5960 )

              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.

              • by TheLink ( 130905 )

                Huh. Magic databases are a contributor to the problem not the solution.

                The problem is browsers are NOT respecting the mime type AND are using a "magic database" to decide whether something can be executed. It's not that relevant whether magic database is from the O/S or from the browser. The main issue is the browsers are NOT respecting the mime type.

                With magic databases stuff that contains executable stuff can get executed no matter what it is called.

                The way to protect against the "magic database" is to se

      • by Rinikusu ( 28164 )

        There's a few games that I quite enjoy that are java applets.
        NES Golf [everyvideogame.com]
        Stuff over at Puppy Games using LWJGL [puppygames.net]
        etc.

        So, don't knock it.

    • by The Ultimate Fartkno ( 756456 ) on Friday August 01, 2008 @04:10PM (#24439899)

      God only knows what goatse would do.

      Talk about a gaping security hole...

    • Just imagine - something as innocent as lolcats could be a potential minefield. God only knows what goatse would do.

      I don't know about online credentials, but Goatse and Tubgirl have been stealing something for years- peoples' minds.

  • by Paradigm_Complex ( 968558 ) on Friday August 01, 2008 @03:27PM (#24438919)
    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!
    • I'll be disappointed if the command to begin the attack isn't:

      GIFAR, kree!

    • by pcgabe ( 712924 )

      Do you pronounce GIF (graphics interchange format) with a soft G? How do you pronounce "graphics"? Does it sound like a tall animal?

      • The developers pronounce it with a soft 'G,' [wikipedia.org] as in the peanut butter brand. When it comes up in conversation, most people I've heard use a soft 'G' in GIF. (I can't think of an exception, honestly.) It may be a local/regional kinda thing, like pop vs soda vs coke.

        I've heard "Ubuntu" pronounced every way imaginable.
        • by pcgabe ( 712924 )

          Oh, I know, but as GIF did not enter English via a Romance language (eg, Italian), and all OTHER words that begin with gi- are pronounced with a hard g, and everyone I know (except for one guy) pronounces it with a hard g, and the hard g pronunciation is by far the more common one (despite your personal anecdotal evidence to the contrary) especially with people who don't know the word's origin, I'm going to say that hard-g GIF is the more correct pronunciation.

          Or to quote Erik Macki: "English is full of wor

  • please... (Score:5, Funny)

    by pohl ( 872 ) on Friday August 01, 2008 @03:27PM (#24438929) Homepage

    ...won't someone think of the PORN!?

  • Oh no (Score:4, Funny)

    by fortyonejb ( 1116789 ) on Friday August 01, 2008 @03:28PM (#24438953)
    As if tub girl wasn't insidious enough... Now she's going to steal my accounts?
  • by Lord Kestrel ( 91395 ) on Friday August 01, 2008 @03:34PM (#24439113)

    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.

    • Actually, my guess is that this is some sort of automatic file type detection where the browser tries to detect the type of file and use the appropriate plugin (thus causing the JRE Applet Plugin to potentially get selected). If that's the case, NoScript may not recognize it, though disabling Java should fix it.
    • by khasim ( 1285 )

      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

      • Even if Facebook is whitelisted, the applet wouldn't run because it's hosted on a different site.

        NoScript checks both the embedding site and the embedded (Java) object against the whitelist to determine if it can be run.

      • No it would just take facebook to do better validation, and any other site that allowed this to happen.

        I have my doubts it would even work in the real world, otherwise facebook need a kick up the arse as they should have seen it coming.

  • "Upgrade to a hybrid today and get 20% more mileage on your phishing messages"
  • by CustomDesigned ( 250089 ) <stuart@gathman.org> on Friday August 01, 2008 @03:35PM (#24439123) Homepage Journal

    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).

    • by Bogtha ( 906264 ) on Friday August 01, 2008 @03:59PM (#24439669)

      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].

  • Linux (Score:5, Funny)

    by Darkness404 ( 1287218 ) on Friday August 01, 2008 @03:35PM (#24439139)
    Well, this proves it again, by making Java so hard to install, Linux avoided yet another threat.
    • emerge jdk

      Yeah, you're right...that was hard.

      Java has never been hard to install, it just isn't installed by default just like Nvidia drivers. Although, I just gave a Gentoo example where nothing is installed by default.
      • Well, actually on my (eee)Xubuntu install I'm still having a bit of trouble getting Java to work for vNES, though I think it has more to do with my screen being so tiny then a flaw in Ubuntu or Java.
      • by hansraj ( 458504 ) *

        You are such a cheerful person. You must be a thousand years old.

  • Thumbnails (Score:2, Insightful)

    by omnichad ( 1198475 )
    What site doesn't resize the uploaded image for display? That wouldn't result in "compressed code" it would just be an image.
  • YouTube? (Score:3, Insightful)

    by LM741N ( 258038 ) on Friday August 01, 2008 @03:39PM (#24439213)

    I am very curious whether some similar type of exploit could be used on YouTube uploads. Well, I guess we'll know soon.

    • Re: (Score:2, Interesting)

      by jebrew ( 1101907 )
      Not likely, youtube transcodes anything uploaded, so unless you've got a way to slip the code past a transcode and subsequent wrap into a .flv, then you're not going to hone your pwnage.

      Now as for taking down some youtube servers using this exploit, while it's unlikely, is definitely more possible. Though I'd imagine their transcoders aren't written to execute code if a supposed videostream is mislabeled.

  • 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

    • 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 file content not the MIME type - do they still do that? If so, I guess IE might see the file as a JAR not a GIF, but nothing else would.

      IE up to version 7 still does this, but unless the IE programmers are a lot smarter than we think, IE should see this combined file as a ZIP file, which is all a JAR file is.

      Using a very recent version of "file" (Fedora 9), I get the following:
      $file foo.jar
      foo.jar: Zip archive data, at least v2.0 to extract

      If "file" can't figure it out, I'd be surprised if the IE programmers can.

    • It's a two-cut - short in the front, long in the back...

      GIF in the front, ZIP (JAR) in the back. Just append them. It's an old stego trick. Of course we can hide the "zip" part as well -- append a block of zero to the end of the file.:

      $ cat Chess_knight_icon.png a.zip >a.png
      $ file a.png
      a.png: PNG image data, 21 x 21, 4-bit colormap, non-interlaced
      $ unzip -v a.png
      Archive: a.png
      warning [a.png]: 257 extra bytes at beginning or within zipfile
      (attempting to process anyway) ..listing elided to

  • by ak_hepcat ( 468765 ) <slashdotNO@SPAMakhepcat.com> on Friday August 01, 2008 @03:56PM (#24439591) Homepage Journal

    * 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)

      by ignoramus ( 544216 )

      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

    • Even better, just truncate (or tweak) the image metadata.

      If it was a JPG it would be a good idea to do this to protect user privacy anyway - I'm not familiar with the GIF metadata though.

  • There are websites still using Java applets? I thought those died years ago.

  • TFA says that a user needs to be logged in for this attack to work. This sounds as if the mechanism is the same as or similar to a cross-site request forgery. Shouldn't it be possible to stop the attack with similar countermeasures, such as tokens that need to be submitted along with the request for sensitive information?

  • 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
    Rename the result to .gif or .zip. Both work. You can also substitute JPG instead of the GIF, or any other file type that ignores trailing garbage.

    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.

  • Anyone who knows much about web browser security will almost certainly have enough to replicate this attack very quickly. The recent DNS flaw was replicated based only on the knowledge that there was a DNS spoofing flaw, some rumours and a few patches.

    It would be much better to go with full disclosure, so that at least everyone has access to the same info and can take steps to prevent the attack. It would be impossible to try and inform every affected software developer, including open source projects, and

    • Re: (Score:3, Informative)

      by Tony Hoyle ( 11698 )

      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.

  • "Jif" would be a better combo, imo. No, I didn't RTFA.

I tell them to turn to the study of mathematics, for it is only there that they might escape the lusts of the flesh. -- Thomas Mann, "The Magic Mountain"

Working...