We’re always trying to stay ahead of the latest trends, and today we caught a very interesting one that we have either been missing, or it’s new. We’ll just say it’s new. 😉
We’re all familiar with the idea of iframe injections, right?
Understanding an iFrame Injection
The iframe HTML tag is very standard today, it’s an easy way to embed content from another site into your own. It’s supported by almost all browsers and employed by millions of websites today. Use Adsense? Then you have an iframe embedded within your site too.
Pretty nifty, I know. Like with most things though, the good is always accompanied with the bad.
In today’s attacks, especially when we’re talking about drive-by-downloads, leveraging the iframe tag is often the preferred method. It’s simple and easy, and with a few attribute modifications, the attacker is able to embed code from another site, often compromised, and load something via the client’s browser without them knowing (silently).
It would look something like this:
Attackers normally embed a malicious file from another site, often in the form of a PHP file or something similar. This of course is not the only method, but the most prevalent. From a detection and remediation standpoint, these are often fairly straight forward to fix.
New iFrame Injection Method
Today however we found an interesting type of iframe injection.
The uniqueness is not in the implementation of the iframe tag to embed content, but rather in the vector used to distributes the malware. You see, the attacker obfuscated the payload inside a PNG file.
I can almost hear the lot of you snickering, pff.. this isn’t new…. but it’s all in the details my friends.
The iframe was loading a valid file, nothing malicious, it was a javascript file, jquery.js. For all intents and purposed, the file was good. Here, look for yourself:
At first, like many of you, we were stumped. I mean the code is good, no major issues, right? Then we noticed this little function, loadFile(). The function itself wasn’t curious, but the fact that it was loading a PNG was – var strFile = ‘./dron.png.
You’d be surprised how long it takes to stare at the code before you notice something like that. I know, hindsight is a real kicker.
Naturally our next step was to open that curious dron.png file. I mean, what could go wrong?
Well, absolutely nothing, it’s perhaps the most boring thing I have ever seen, lovely. What a waste of time…
But wait, we then noticed this interesting little loop:
Well that’s surely curious. It has a decoding loop. Why would it need a decoding loop for a PNG file?
Like any good researcher, I went about it the easy way. Why worry about breaking down an image when I can just load the image on a test page and take the content. For the win!
After loading it on a test page, this is what we were able to pull from the strData variable:
Do you see what it is doing?
It’s taking the normal behavior of an iframe injection, embedding it within the meta of the PNG file, and just like that we have a new distribution mechanism.
A couple of areas to pay special attention to:
- They use the createElement to use an iframe.
- They place the iframe out of view via the elm.style.position.left and elm.style.position.top elements, positioning the image at -1000px.
- That’s right, you can’t see a negative placement in your browser. Everything you see is positive.
- But you know who can see negative placement? That’s right, the browser itself, and so does Google.
A nice little technique both for drive-by-download and Search Engine Poisoning (SEP) attacks.
Lastly of course we have the payload, which can found on that domain set in the elm.src element.
Why is This Unique and What is the Benefit?
This is unique because in the level of effort being taken to obfuscate the payload. Most scanners today will not decode the meta in the image, they would stop at the JavaScript that is being loaded, but they won’t follow the cookie trail. This also talks to the benefit, at least for attackers, it’s exceptionally difficult to detect.
Do make note however that while in this specific case we’re talking about PNG, the concepts do and can apply to other image file types as well. This only puts more emphasis on the importance of being aware of the state of your web server, understanding what files are and aren’t being added and modified and ensuring that vulnerabilities are not being exploited.
As is often the case, some creative sleuthing and troubleshooting allowed us to spend the time required to find this lovely little gem. Do we detect it now via our Website Malware Scanner? Absolutely!
Stay frosty my friends!
Luke Leal
Rianna MacLeod
Yuliyan Tsvetkov
Krasimir Konov
Tony Perez
Art Martori
Andrey Kucherov
Daniel Cid
20 comments
its called superpacking -> http://daeken.com/superpacking-js-demos,
and it doesn’t necessarily mean its malware
the technique is normally used for the lzma compression because its better than gzip
Did you forget your own debug code in there?
var oText = document.getElementById(“output”);
Will search engines index contents generated using javascript?
The main ones like Google etc can process javascript so it will be very interesting to see if this can be used to push malware directly into the search results themselves.
A worthwhile investigation.
“You’ve done a man’s job, sir. I guess you’re through, huh?”
The very PNG trick mentioned here was designed in 2008 and refined in 2011 and 2012 to become self contained: The image is also an HTML document that loads itself as an image, read its pixels to rebuild a string of characters that is then executed as JavaScript.
This last technique is called PNG Bootstraping and is pretty standard practice in the demoscene and creative coding scene focusing on size optimization.
See http://vimeo.com/43335760 or http://www.p01.org/ for more information about legit uses of these two techniques.
Color me surprised it took 6 years to see this technique used for devious purpose. In retrospect, the dynamic favicon trick seen in Defender of the Favicon ( also from 2008 ) was abused much quicker, in only 2 years, to phish people using tabnapping.
This is actually not really big thing. Encoding algorithm is really simple and nothing you could saw on the internet before, and also nowhere as complicated as some obfuscations I have seen while reverse engineering various malware in JS.
Nevertheless, I did enjoy the article 🙂 Thanks!
I agree, but what it does do is open a new set of attack vectors that most people haven’t considered before. Some of the JS I have pulled apart over the years has been a lot of hard work as I am sure you understand, but at least I wasn’t having to decode images to get to the JS in order to decode that as well.
Except it’s not relatively new:
http://blog.nihilogic.dk/2008/05/compression-using-canvas-and-png.html
Also, see this:
http://jsunpack.jeek.org/
And I wonder where the “injection” is.. the entire code is ran from the attacker’s page. If the objective is to obfuscate the code, and the attacker already controls the code, he can put whatever techniques, obfuscated or not, in that loadFile() function.
So, yeah, not exactly a new PNG script packer, and a dubious claim of “injection” here.
That is very nice and very sneaky. I do a lot of work in and around software security and that is a new one on me. Well done on catching and decoding that and it opens up a whole host of other things to consider now.
Hashes or it didn’t happen…. Rookie mistake…
I have clicked on “http://bestinfo.com” (not the longer url from the code above) by accident and am wondering if I have to worry about malware now? Could you please give me an advise? Would be nice!
It isn’t metadata that’s being read. The function takes the actual image data of each pixel, and then takes the (color? transparency?) code of it, then converts it to a character with
String.fromCharCode.Do you play Dota2? “Stay frosty my friends!!”
I dont get where the string in the png actually gets evaluated? Its seems to stay a string of javascript thatll just popup in the alert to me?
Created a bug report on bugzilla to convince Mozilla of using something like the popup block method/click to play (plugins) to prevent javascript from creating iFrames without the users permission as this is used more and more to push exploits/drive-by downloads unnoticed to the user
forgot the link 🙂
here ya go:
https://bugzilla.mozilla.org/show_bug.cgi?id=969037
Vielen Dank!
Interesting article, but apparently not a new technique. On a side note, as this post is seemingly related to a commercial enterprise, and is definitely code related, I would have thought that more effort would have been paid to the grammar and syntax of the article too. “For all intents and PURPOSED”? That’s pretty funny, but it’s also sad that literacy is becoming so unimportant, including in the comments.
Does this also apply to png-files in emails? If I open an email with a png, is that the same thing? The article also talk about other image-formats. What are they?
Comments are closed.