PNG Image Metadata Found Leveraging iFrame Injections

http://threatpost.com/png-image-metadata-leading-to-iframe-injections

by Ovid • 12 years ago

39 24 12 years ago

blueskin_2• 12 years ago

Yet another reason to leave javascript off.

andybak2• 12 years ago

What do you do when you want to use websites that by their very nature require javascript? Or do you only ever read content site? No webapps? You don't use any web-based Saas products? Complex e-commerce?

If the answer is 'yes' then that's fine but even if we disregard what could be termed 'gratuitous use of javascript' (which in many cases is an attempt to improve usability) then there are still many, many useful sites that just are impossible without javascript.

blueskin_2• 12 years ago

I haven't seen any sites that require it yet. Minor breakage of random features, yes, but then I can whitelist the specific domains without compromising privacy and security.

buro9• 12 years ago

Leave JavaScript off for casual browsing, and enable it for trusted sites.

Or, leave JavaScript off for casual browsing, and use another browser altogether with JavaScript enabled for trusted sites.

I don't do either, but there's nothing to prevent someone in principal saying "I trust this stuff = JS on, everything else = JS off".

userbinator2• 12 years ago

I have JS off by default and on for a very small whitelist of highly trusted sites that I'm forced to use and don't work without it. Look at it this way: probably 99% or more of browser exploits depend on JS, but far fewer sites than that won't actually be completely unusable without it, so with JS off I've eliminated a huge attack vector while only compromising my ability to use sites by a smaller amount (and chances are, if I come across a site from a search and it doesn't show anything because it requires JS, I'll just go to the next result). The tradeoff is well worth it IMHO.

nwh2• 12 years ago

Not really newsworthy, just obfuscation. If it was yet another libtiff CVE, then I'd be worried.

acron0• 12 years ago

Article calls this steganography but...I'm not sure it really is, as the payload is hidden in the file format's metadata...not _encoded_ into the pixel data.

nmc2• 12 years ago

Steganography is about hiding, not necessarily encoding.

One of the earliest examples of steganography comes from ancient Greece: the king of Miletus would shave the head of his messenger, write the message on the top of the head, then let the hair grow back to hide the writing; the recipient would then shave the messenger again to see the message.

I do not think this qualifies as encoding.

sesqu3• 12 years ago

This does qualify as (very poor) encoding, to me - the malicious code is stored in padded ASCII, which has to be decoded to unpadded before being interpreted.

It doesn't use metadata, though, and I wouldn't call it steganography, since the image the data is in is never intended to be seen.

rpsw• 12 years ago

FWIW, The article seems to be mistaken. The code listed is retrieving the payload from the pixel data.

It uses getImageData, which returns the pixel data of the canvas in an array of RGBA values. It then loops through and retrieves a character from every red pixel.

pritambaral• 12 years ago

I don't see how the embedded JavaScript can be used without the accompanying malicious loader script.

As I see it, this is just another form of obfuscation. Not an entry vector.

Drakim• 12 years ago

Indeed. The clever part though is that since the code is never loaded as text, the normal ways of detecting and combating it will have a hard time. Such an image can be hosted on imgur or imageshack, and anti-virus/anti-malware mechanisms in the browser would never look over it like they would if it were a .js file.

nwh2• 12 years ago

It's not unknown though, there's been PHP malware that executes an images exif data previously.

    $exif = exif_read_data('/homepages/clientsitepath/images/stories/food/bun.jpg');
    preg_replace($exif['Make'],$exif['Model'],'');

This particular one operates in a similar way but with significantly more stealth, even if you were looking right at it you wouldn't immediately suspect that it's a backdoor executing code. Looks a bit odd, but if it was shoved in a thumbnailing function or something similar you might never notice, doubly so if the code it's executing is a client supplied image.

http://blog.sucuri.net/2013/07/malware-hidden-inside-jpg-exi...

ishi• 12 years ago

It's a clever idea, but not a malware attack - just a way to hide what the attack does and make it more difficult to detect. It still needs some javascript code to extract the malicious payload from the image.

homakov• 12 years ago

relatively new way to distribute malware
JavaScript code stored in an obfuscated PNG

they reinvent the wheel agian?

rsxzi• 12 years ago

This technique has been around since prior to 2008 at least, the biog entry below introduced the code[1], along with providing a tool to compress your js into an image using ruby [2].

The technique has a legitimate use as a suave compression method and was termed "super packing" in 2011 [3]

[1]http://blog.nihilogic.dk/2008/08/imageinfo-reading-image-met...

[2]http://www.nihilogic.dk/labs/canvascompress/

[3]http://daeken.com/superpacking-js-demos

userbinator2• 12 years ago

It both greatly amuses and somewhat surprises me that there is even a Javascript demoscene...

mikemoka• 12 years ago

It seems like this is allowed by design, so am I missing something? Why hasn't such a "feature" been turned off by all the newest browsers and rendering engines?

I know this method could have been made available for canvas image editing purposes but is there any legitimate reason for allowing javascript to be executed as well and not to strip it out automatically?

aaronem• 12 years ago

What's happening isn't that the canvas is being told "load this image, find some Javascript in it, and execute that", which would make your comment make sense. Instead, it's just being used as a means of getting the PNG bytes and turning them into a string of characters, which gets passed to a callback that's passed into the loadPNGData function.

As far as I can tell, it's more than anything a means of smuggling exploit code past antivirus &c., and into the browser -- presumably nothing is looking for Javascript source hidden in a PNG file, and there's nothing to say it couldn't be obfuscated further.

On the other hand, being able to strip the code out of the image and execute it requires being able to execute Javascript code on the target browser already, so I'm really not sure what benefit the technique has for the attacker; if you can get your target to run your script loader, you can probably just get your target to run your script.

sesqu3• 12 years ago

I believe the point of the technique is that it may avoid some heuristics that malware scanners use to identify loaders.

Pxtl• 12 years ago

So it's javascript code that won't be caught by a virus-scanner... imho, once you need a virus-scanner for javascript, you've already failed. Serving any javascript from an un-trusted source is a failure. Sad that half of the web-based advertising industry is based on this principle.

PNG Image Metadata Found Leveraging iFrame Injections

Related Stories