Backdooring Images

Fri, 15 Dec 2006 04:57:22 GMT
by pdp

An offensive move where a player cuts behind the defenders and receives a pass for a field-goal attempt. basketball-betting-college

OK, we've covered how to backdoor Flash, QuickTime, QuickTime Link, PDF and simple HTML files, but we haven't discussed how to backdoor images yet. In this post I am going to outline some of the techniques available for maliciously infecting Image (Picture) files with JavaScript code. I must worn you that what you are about to read is not intended to describe new issues but rather to clarify and provide scenarios where the discussed attack vectors can be implemented.

First of all I want to drag your attention to the infamous Internet Explorer GIF vulnerability which I believe was the first to bring a lot of attention on JavaScript inside images issue. The vulnerability was one of the most obscured ones and it was successfully used to compromise many bulletin boards and not only. Luckily, Microsoft came up with a patch for it some time ago and if you are on SP2 you are no affected any more. It is essential to understand that this was not the first one. In fact similar issues were found in Netscape and other popular browsers long before it but I will leave this research to you.

The essence of this GIF89 vulnerability is hidden inside the inner working of IE file detection engine. If a file starts with GIF89 header it will be threaded as gif, however if you append right after this header a html document with some malicious JavaScript, than you have a trojaned gif which will not display properly in the browser but will successfully exploit it.

This find was pretty good at the time it was discovered. Given the fact that Internet Explorer is the most popular browser (things are changing) on the planet, a lot of websites that allowed user supplied content in a form of images were left open to many types of web related attacks. This, however, is not the end of the story because today, with IE6 and IE7 a very similar problem still occurs.

What types of other image file issues are still available today? There are a few that are ridiculously simple but also very, very dangerous. In fact, all of these techniques can be used to successfully recreate a worm, similar to the one that hit MySpace last week, to some extend.

You may not be aware of, but there is a bunch of insecure File Handling issues in Internet Explorer. That was discovered long time ago and it was outline in securityfocus here and here and a couple of other places. I don't know why nobody pays any attention on these and I guess I need cover this particular issue some other time.

If you read the BID references you will see that normal files like .jpg and .gif can contain HTML code which upon viewing will execute whatever it is inside, which may as well be a real image so that the user doesn't get too suspicious. Here is how to compose a malicious JPG file for IE.


Save that as .JPG and preview it in Internet Explorer. You need to put it on a web server first.

This is absolutely trivial but as I mentioned earlier it could be used for very destructive purposes. For example, if an attacker decides to hijack several MySpace accounts, he/she could simply put a link to a trojaned image on blogs found in MySpace. The image should be titled with an attractive name so users are more likely to click on it. Once an unaware user fells into the trap, the browser will redirect to the image location which in tern will ask for login credentials to preview the private content. That way, IMHO, attackers can phish many accounts.

I am not a MySpace fan and I don't have an account with them but if it is allowed to upload Image files the situation could get worse because the domain from where the images will come from is the same as the domain you want to exploit, imagine the possibilities.

Sometimes this scenario is quite easily achieved especially on various bulletin boards that don't verify that the user supplied avatar image is an actual image. You can create an account and upload backdoored JPG file. Then reference this file somewhere as a link. If an unaware user clicks on it, you will receive their session and you will be able to do all sorts of other stuff, as well. Here is a hint: attackers can post several other comments containing a link to the malicious JPG on behalf of you. This is how you do a malware infection on BB for example.

I know what you are thinking. This is so easy and virtually everyone can do it and there are so many web applications vulnerable to this issue that it is not even funny. But now you are thinking that Internet Explorer is the worst browser in the world. You are wrong. In fact, Internet Explorer is almost as vulnerable as Firefox and the rest of the browsers are. In fact, this is not even a browser related problem. It is a server side problem. People sanitize user supplied data but do they sanitize links to external or internal files,... nope. The reason for that is obvious: too much work and I don't blame application vendors for not doing that. GMAIL does all of it the right way, though. I did spend some time testing this issue.

Firefox can also be made behave the same way like Internet Explorer. Simply we can change the mime type by composing the following htaccess file.

AddType text/html .jpg

If you put this file somewhere with your image, you will recreate the same effect. The only good thing about this approach is that it is less efficient..

I will leave this subject open because there is a lot one can say and I don't have much time. Has anyone tried Flicker yet?

Archived Comments

Have you tried this in IE 7 yet? I can't get it to work.
Adriaan GraasAdriaan Graas
Hi, I am following your blog for a little wile now, and I think it is really great that you point out so much issues. In this post you say that these are not browser vulnerabilities, but server side problems. I don't really get that. Extensions don't matter. So the browser looks to the content-type header what it is. When it says its html, does that mean that it should handle it as html? A image is most likely embedded in html or css. The browser should know by then (by tag or css) that it should handle it as image, and then ignore the header. It would be more clean if the browser takes the websites source as first priority how to interprent the file, instead of just accepting the header, imho. This would solve a lot of security issues. Images which are not included by website source should then be handled as the content-type header says. I hope you understand my english, and please correct me if I'm wrong. Adriaan
Will, it works on IE7 SP2. I have tested it on my machine. Make sure that you put the files on a server first. Download WAMP and start from there. Adriaan, your English is good. I understand what you are talking about and I am on your side. Sure, browser can do some additional checks to verify that what it is receiving is what it says. Unfortunately, I can clearly see that this is not the case and it never be. The problem here is that the Internet/Web is almost infinite. There are so many different file types out there that it takes a big afford just to put them into a database. Browsers, should take this a lot more seriously, sure, but is it feasible. I don't know. Maybe they should be able to check for the most popular file types such as JPG, PNG, JS, CSS, GIF... etc. However, I can see how in certain situation this feature can break one or another company corporate application. So, from all browsers out there, only Firefox, Opera and a few others may implement this feature in the near future. I hope they do. IE will support all legacy stuff no matter what. You are bringing some interesting points here. Let's see if browser vendors will take your advice seriously.
Well, I'm pretty sure most people developing serious applications nowadays know about this issue. And so most applications at least check the headers of the files to make sure that they are the appropriate headers. Some like vBulletin go further and do a limited scan on the first part (200 bytes in vBulletin's case) of the image to make sure that anyone using an old version cannot be attacked. (The odd thing about vBulletin though is that the patch is actually rather recent, which makes you wonder about why it has suddenly become something they wanted to guard against) MySpace goes further and makes sure that it is a valid image and can be rendered. I'm not sure how it does it, but one of the possibilities I've thought of would be using something like the GD library to detect what type of picture it is then try and load it and if it fails then don't move it to a web-accessible directory, and simply remove it. So barring a vulnerability similar to the IE GIF one mentioned in this post I don't think there are going to be any similar issues.
Also attacker my use servlet not only to display image but also hijak the session id of the user, by giving extension of gif or jpeg or other image extension to the servlet name like myavatar.jpeg which performs both tasks; display image and hijak sessionID
Hi, Interesting discussion indeed. Content checking is an ever coming up issue, and I think that browser vendors/creators should care. However it's not on the file type recognition part but on the processing part where the stake lies. If a file has a .jpg ending it should be handled as JPEG and not be parsed as HTML (as in our above example), that's all about sticking witzh standards. It's the same (many years now) with bad HTML code. Why should a browser interpret bad/non standard HTML code ? The result can be unexpected even not speaking about the security issue it implicates. just my 5 cents, pst
I'm almost sure that embed both image and id theft in a servlet can't bypassed since the http header may be altered before posting response, even if browser sanitize the image and find it innocent he will never ever detect the id theft because it a server-side stuff
I just attempted this on my MySpace and it didn't allow me to upload it. I also tried on facebook and that did not work either. Check this site, I'm sure with not too much imagination you could derive a very slick exploit from this idea and the one on this site.
An URL not an Image: To perform this trick you should be able to feed an url to the "spy" image which is hosted in a server of yours, so you have to feed an URL to the image not upload the image itself (actualy the servlet). in another word Myspace is expected to save the URL in its database not the image itself.
This doesnt work on myspace.
Nor can Mehtap! I want to say that your site better throughout the World Wide Web :) Thank you. Keep it.
"In fact, this is not even a browser related problem. It is a server side problem" I don't agree. If server sends header: Content-Type: image/jpeg then IE (as any other browser) should render the image as an image, not parse it as HTML! This is a huge bug on IE side, and while the server can remedy things by carefully examining the images, that really should not be needed. This is clearly another IE bug.
andrew, in a way it is a server-side problem because developers allow uploads of files based on their extensions. IE shouldn't try to detect the mime-type of everything it pulls from the web but also developers should sanitize everything that comes from the user in order to prevent the wrong data going into the wrong pace.
pdp, I disagree - mime types and headers are there to ensure correct handling of the data sent. It is the way things should work and IE clearly violates that. Without this IE bug there would be no security problem at all. Also, web developers should not care if the images are valid (and even valid images can contain JS!), at least not from security point of view. They should take care that they are served the right way (and not executed on the server), that they are small enough, that they have correct extension and mime type header - but that's all. I think IE is to blame, but yes, web developers must deal with it... :(