PNG Image Metadata Found Leveraging iFrame Injections | Hacker News Reader

PNG Image Metadata Found Leveraging iFrame Injections

threatpost.com

39 pointsOvid24 comments

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.

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.

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.

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

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

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.

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.

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.

By such a definition, any form of expression is encoding, isn't it?

Pretty much, except in coding theory you have to be explicit about your alphabet. Hall took this further, by positing that in television, viewers use individual and heterogeneous decoders.

Anyway, the point is that the channel used to communicate the message in this case is unconventional, and that's why I consider encoding to occur. A casual observer would assume the datastream to encode an image, not a program, and as such the program can be said to be explicitly encoded, rather than implicitly.

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.

Yet another reason to leave javascript off.

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.

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.

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

I can see an argument for this but I'm a web developer and it's important that I experience the web the same way as the vast majority of my customers and users will - otherwise I'm living in a bubble. Same for Adblock.

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.

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.

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

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

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?

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.

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

>relatively new way to distribute malware

>JavaScript code stored in an obfuscated PNG

they reinvent the wheel agian?

Reply on news.ycombinator.com