O M F G!

I could not believed it really worked while doing it.

Details on my blog:
[www.jungsonnstudios.com]


Errm... anyone some plans on how to fix this? other then to NEVER use MSIE again?

Another one to add to the arsenal, doesn't appear to be embedable though?
Also tried to upload to various image sites, got "invalid content".
Interesting find though and I'm still playing with it.

I haven't tried it yet to upload it to some site orso, so cannot say if that would work. I tryed for firefox to edit a full 100x100 white gif, but can't get it to work on there. I thought maybe Firefox would check on the size etcetera, but doesn't seem to be the case.

Quote:

Also tried to upload to various image sites, got "invalid content".

I don't see the danger in such one click hosters. You can easily check whether you have a valid image by using PHP's getimagesize() function, which will return false if there's anything manipulated. In fact there are some ways to bypass this function but in this case it will work.

That means you can protect your own sites from being hacked this way but in the moment you open IE and go on any other website, you are insecure. Scary :/

So, it appears that when IE runs across something where the MIME type and content don't appear to match it will revert to html mode.

When downloading the file, IE receives image/gif as the MIME type, but when it gets the response, it doesn't find an image (the header is invalid), so it tries html. (Goto to file->properties to verify it says "Type: HTM file"). In firefox, it observes the MIME type and fails to render the image (View Page Info and verify the "Type: image/gif")

If you edit the demo files in a hex editor and fix the headers, IE will simply display a broken image link.

To get the alert, it's sufficient to have only the "<script>alert('xss');</script>" part. The "%137%80%78%71%13%10%26%10%00%00%00%13%00%00%00%01%00%00%00%01" part is output as 62 characters, not as the 20 bytes that were intended because notepad will not make that conversion.

Now, that doesn't mean that this isn't a problem. Any site that allows image uploads based on file extensions without performing further validation is at risk. Since these html-as-image files don't seem to be embeddable in <img> tags, I suspect a link or some other user interaction would be required.

-kogir

Firstly; how is this universal? Universal would be if it is a vulnerability in all, or almost all sites, and almost no-one allows file uploads.

Secondly, its been a known issue for a while: [www.securiteam.com]

There's a good (very recent) write up which explains why/how it works here: [www.splitbrain.org]

And while I don't know about phpBB, I do know vBulletin has patched it in 3.6.3



Edited 1 time(s). Last edit at 02/17/2007 05:32PM by kuza55.

@Kogir, you're aright about that. Petko from gnucitz. contacted me about it.He found this in dec. 2006 and it Doesn't need to have the header in it. (I really need to look more at gnucitiz.'s website, can prevent alot of double findings. But damn.. this isn't just a little issue here, I wonder why I did not knew this before? And the header part, I constructed by looking up the actual file specs of JPG GIF and PNG. GIF has a slighty different one I found out later: GIF98.

@kuza55

Yes, not really Universal in the sense of everything, but generally it affects everything that has an image stored and viewed with MSIE. There are many sites which host images though, and allow you to upload stuff. And even show you the full URL to the image like; (click to zoom in) :)

But I must confess, I don't read many security sites or blogs (not much time while working), and I can thereby miss a few things. Usually I follow RSnake's blog, that way i'm up2date with such bleeding issues.


So this stil seems an issue, and i maybe wrong but i find this one far more dangerous then the UXSS in PDF files.

Quote:

So this stil seems an issue, and i maybe wrong but i find this one far more dangerous then the UXSS in PDF files.

Why do you think that? In my opinion, there's no significant difference, despite the fact that there are most likely more websites allowing image upload, than having pdf files on it out there.

Quote:

For now I recommend not allowing anonymous upload of any files. [www.splitbrain.org]

Quote:

All web sites that allow the upload of files to use in further use are affected. [www.securiteam.com]

While it is true that the possibility to inject code exists, it is absolutely not true that all sites have to be vulnerable to this issue. The first thing you should do is checking whether the file in question is valid. There should be enough ways to do this in any programming language. Additionally you can simply parse the files source code and check it for suspicious strings.

If this is done correctly, you should be save.
Anyway I definitely agree that this is highly dangerous. I assume that the safety measure discribed above isn't implemented on many websites, which allows lots of the well known attacks with the help of a bit of social engeneering.

This is quiet old.

As to whether it represents a greater risk, it does... but only in the sense that most (99%) of developers aren't aware of the issue from a client side perspective. With that said, most of the spoilts i seen using this require a combination of

a > being allowed to host an image (sig or avatar, product for auction etc)
b > se'ing the target (usally the admin) informing them there is a problem with the image.

Therefore it requires a number conditions to be meet before it is truly "weaponised".

In relation to a server side perspective, and i am talking about include/require vunerabilities it is well known amongst hackers that when you use includes etc in php, the file called regardless of extension will be parsed as php. Hence a easy attack point for many php sites it to upload a jpg or gif file with text containing a php shell. find a include point in the site that can be easily expoilted and setting the value to the uploaded image.

Hence as Christ1an said you simply filter ALL content (the golden rule!). hell i still run regexs on ip just to be sure.

In relation to the actual issue at hand, here is a fair better overview of how MS determines mime types.
[msdn.microsoft.com]

----------
'Just because you got the bacon, lettuce, and tomato don't mean I'm gonna give you my toast.'

I just had a thought (took me a while, didn't it), that on Windows it should be relatively easy to protect from these attacks, just create a PHP extension which calls the FindMimeFromData function.

You could even set it up as a web service on a dedicated windows box, which you send all images to, to find their mime types (because otherwise you have to do something hack-ish or emulate the windows environment so you can get to use the function).

Quote:

In relation to a server side perspective, and i am talking about include/require vunerabilities it is well known amongst hackers that when you use includes etc in php, the file called regardless of extension will be parsed as php. Hence a easy attack point for many php sites it to upload a jpg or gif file with text containing a php shell. find a include point in the site that can be easily expoilted and setting the value to the uploaded image.

Yeah and trying to find an include point is not as easy as you claim it. If the corresponding programmer is that dumb to let arbitrary code being included, you'll find a lot of more serious vulnerabilities on his site. In this case you definitely have full access to everything on the server, since PHP itself is horribly insecure and exploitable.
I strongly recommend to install Suhosin. Next month will be very very amusingly.



Edited 1 time(s). Last edit at 02/18/2007 09:26AM by christ1an.

I'm sure we can protect our own code and software/servers just like the PDF issue, but problem is how many do? and when we go surfing to other sites, you're never sure if some image contains it, and when I say it's far more dangerous I mean I can embed thousands of javascript code in it, who know how far this can penetrate browsers while we're at it. The PDF issue requires still some sort of obfuscation inside an URL, and is limited in the lines of code you can type after the: #.

But wondering now, are other type also vulnerable? I haven't tried: .doc .pdf .swf .etc

And what about making some Ajax calls inside the uploaded image? It's on the same domain isn't it? :-))

IMHO: I don't really know what Microsoft was thinking here...



Edited 1 time(s). Last edit at 02/18/2007 10:10AM by jungsonn.

Quote:

But wondering now, are other type also vulnerable? I haven't tried: .doc .pdf .swf .etc
And what about making some Ajax calls inside the uploaded image? It's on the same domain isn't it? :-))

IMHO: I don't really know what Microsoft was thinking here...

Maybe you should read this: [www.splitbrain.org] , it should answer at least two of your questions. I think Ajax will work (not tested yet), because after IE has finished it's hit the pot game, the output should be treated like normal HTML. Can anyone confirm?

Quote:

Yeah and trying to find an include point is not as easy as you claim it.

ok, maybe easy wasn't the correct term. But what I am saying is that with an open source web application, i can generally within 10 minutes, determine almost every injection point within an application using my self coded auditing tool.

Quote:

But wondering now, are other type also vulnerable? I haven't tried: .doc .pdf .swf .etc

I have tried many different formats and all seem to be successful except where it uses a plugin to run (except pdf which are vunerable). Please check the link below to see more info on how MS detects mime types.

Quote:

In relation to the actual issue at hand, here is a fair better overview of how MS determines mime types.

[msdn.microsoft.com]

Finally, whilst i haven't tested it i believe you could use ajax, as the content is rendered as html so it has all the functionality of html/script.

----------
'Just because you got the bacon, lettuce, and tomato don't mean I'm gonna give you my toast.'

Yeah I was just busy whith XHR'ing an .exe and a batch file that seems to work, only it won't execute remotely ofcorse. But could be used to build a trojan into it to load it locally. Or if that server is running some MS OS you could load some malicious microsoft stuff in theory.

Also not to raise suspicion, one can load a "real" image before the JScript :)

So what can we really do to exploit this thing? I'm alittle out of ideas right now.

BTW: I did some homework, and found it was "known" back in 2004. Some site mentioned something like: "JPEG OF DEATH!" Ghehe.. I like that term.

Yah, actually this is quite an old issue (I've known about it for at least a few years now). But since it's not exploitable without a) having an upload script and b) getting someone to go to it directly in IE, it never seemed that interesting and definitely not a candidate for the cheatsheet since the real vector to get this to work would be to inject an iframe. It's been published a few places. And in fact I was talking with Daniel at Mozilla about this exact issue at RSACon. But it's good to see more people thinking about it.

- RSnake
Gotta love it. http://ha.ckers.org

Still, it's cool to know isn't it? could come to use in some situations :)

'cause I still kinda digg this stuff:
[img15.imgspot.com]

:)

Jungsonn are you sure that your files are valid? Actually I dont think so. In fact nearly all kind of image uploads (one click hosters) are vulnerable to this, which has various reasons:

a) Developers may think they're clever and check files for whether they are valid or not.

b) After they have verified that everything is as expected, they just accept the file.

c) They do not scan the files source code for suspicious strings because they don't expect them. How could you? It's a browser bug and has nothing to do with secure programming or whatever.

d) maybe here is one point missing

Anyway, look here: [img394.imageshack.us]
I'm not sure how many people use this service a day but I assume quite a lot, however it is obviously vulnerable.

The one I uploaded to the imgspot is just an image I grabbed from google and opened it up in an HEX editor, inserting the script somewhere below the header.

In fact, you can check upon an image with Perl or PHP. I'm a little busy on some project now, but I'm building an function for this soon.

Here is my solution

!getimagesize($filename) ? die('nubcake!') : echo('you may continue');

----------
'Just because you got the bacon, lettuce, and tomato don't mean I'm gonna give you my toast.'

@digi7al64

Read [www.splitbrain.org]

You'll see that the images can be valid, but still get interpreted as html by IE.

Edit: Sorry, kuza55 wrote a bit faster

Yeah thats what I already said but in fact it will not work. This function only tries to read the files header and returns some information in an array. If the header is not valid it will return nothing, however in our case you must assume that the file is valid and contains malicious code anyway.

Therefore you must parse the whole source code of the image and check it by using for example regular expressions. I'm definitely not good in dealing with regexps but this should somehow work:

<?php

$contents = file_get_contents('test.png');
if (preg_match('/<[a-zA-Z]+>/', $contents)) {
echo 'I am containing HTML Tags, am I allowed to?';
}

?>

Of course that can not be used and isn't secure at all.



Edited 2 time(s). Last edit at 02/20/2007 01:03AM by christ1an.

hmm ....

Quote:

$img = imagecreatefromstring(file_get_contents('test.png'));
imagepng($img, 'test.png');

kills of any attack vector as it is working on streams which means it doesn't interpret the html as html.

obviously only supports locally hosted png files atm but i think i might make this into a class for uploads etc.

With that said, please try and defeat~


EDIT: here is the code (as viewed in notepad) - also when tested with normal images there appears to be no side effects.

Before

�PNG

   
IHDR   
   
   �wS�   5tEXtComment <script>alert('JavaScript executed')</script>d>   IDAT�c���? ����Y�    IEND�B`�

After

�PNG

   
IHDR   
   
   �wS�   IDAT�c���? ��X�k    IEND�B`�

----------
'Just because you got the bacon, lettuce, and tomato don't mean I'm gonna give you my toast.'



Edited 2 time(s). Last edit at 02/20/2007 03:32AM by digi7al64.

Looks nice digi7al64! that just might work out perfectly.

Have you tried to compare the results in an hex-editor? just to be sure the headers and content aren't messed up?

That may work but not perfectly I think.

imagecreatefromstring() is horrible slow and if you haven't got a fast server, you'll get in trouble.

Edit: Okay, I started to write a function in PHP that verifies whether a image file has been manipulated or not. It works pretty good so far but it's not finished yet. I spend the last two hours with writing regexps and need a break now. I think I can finish it tomorrow, well tested against the XSS cheat sheet.

(No, it's not going to be a function with 20 different regexps.)



Edited 1 time(s). Last edit at 02/20/2007 02:20PM by christ1an.

@jungsonn - thanks, but I want to do some more testing, atm it only works against the spiltbrain POC becuase it removes the comments field... I would like to test it with the xss elsewhere in the image to see how that effects it.

Also the only reason the splitbrain POC works is that is it less then 256 bytes which means when IE scans the buffer to determine the mime type it still find html syntax in the comments tag which then overwrite the png mime type. firefox and opera handle the image normally as they should becuase images can have content within the meta data. Also, I believe given a bigger image, the comments field would be pushed further into the object meaning it won't reside in the first 256 bytes and hence it will fail to fire in IE.

@christ1an - the idea is for the parsing to occur at upload and not at run time on every request. Hence it is only needed once. As for performance issues, a believe a small trade off in speed is worth it.

Remember in web development you have 3 key areas

> Functionality
> Usability
> Security

The trick is deciding which 2 you want.

----------
'Just because you got the bacon, lettuce, and tomato don't mean I'm gonna give you my toast.'

@digi7al64: Yes, thats clear. I just mentioned this performance weakness because on my local webserver (ASUS P4, 480MB RAM) the function crashed nearly everything. It's not that bad on a well performing webserver.

As I said, I tried to implement a PHP function which detects manipulated image files. Essentially it just checks the first 256 bytes for HTML tag looking strings. While reading the code please consider that I never really worked with regular expressions that are more complex than to verify an email adress. I just read a short tutorial and started so there will definitely be mistakes.

I'll implement a new version tomorrow, just wanted to present this one today, hoping to get some feedback until tomorrow.

Enough said, here's the link: [php-classes.net]

Edit:

Quote:

Also the only reason the splitbrain POC works is that is it less then 256 bytes which means when IE scans the buffer to determine the mime type it still find html syntax in the comments tag which then overwrite the png mime type. firefox and opera handle the image normally as they should becuase images can have content within the meta data. Also, I believe given a bigger image, the comments field would be pushed further into the object meaning it won't reside in the first 256 bytes and hence it will fail to fire in IE.

Sorry I do not agree with that. In fact the test.png file from splitbrain is less big than 256 bytes but thats simply not the point. It could have any size to make the trick working. The only determination microsoft does in this moment is checking the first (yeah I repeat myself) 256 bytes. Everything that follows will be ignored. Now if the hard-coded "HTML test" succeeds, you'll get text/html outputted.
That means: Grab an arbitrary - lets say - PNG file. Throw it into a tool like TweakPNG and simply edit somewhere in the first bytes. The string '<body>' in a tEXt chunk should be enough to create the illusion that this was HTML.
If this is done correctly, you can add another chunk anywhere, containing arbitrary javascript code. I even checked the mhtml issue, it works.

Regards,
- [christ1an.blogspot.com]

_______________________
[php-ids.org] Web Application Security 2.0



Edited 2 time(s). Last edit at 02/21/2007 12:56AM by christ1an.

Does it not work in jpegs?

I put <script>alert('xss')</script> in a comment right after the header with hex editor and it just loaded the image properly. :-\

EDIT: Have just checked out tweakpng and you are correct in that you can insert "html" chunks in after the hdr and the image still remains valid. However i am still interested to see how php handles this.

----------
'Just because you got the bacon, lettuce, and tomato don't mean I'm gonna give you my toast.'



Edited 1 time(s). Last edit at 02/21/2007 09:49PM by digi7al64.