Sign up ×
Information Security Stack Exchange is a question and answer site for information security professionals. It's 100% free, no registration required.

I came across this advisory recently and I'm a bit confused by both exploits, but specifically the file upload vulnerability. I don't understand how to actually exploit this condition (or even why this exists as a condition).

I tried using a shell like this and inserting it into the comments section of the EXIF data, but I couldn't find any way to execute the code afterwards.

Can anyone assist? Why is it that a condition like this even exists? Is this vulnerability actually a vulnerability? Or is it just a PoC showing that you can upload things inside things (but not actually exploit them)?

share|improve this question
I believe that this is relevant… – Adi Apr 29 '13 at 7:57

1 Answer 1

up vote 8 down vote accepted

What they're saying is the following:

  • The upload page does not enforce file extensions, and allows you to upload an image file with an extension of .aspx.
  • You can embed code inside a JPEG's EXIF comment tag, and it will survive the resize process (i.e. the comment tag is not stripped)
  • When viewing the file, the server parses the file data as a normal ASPX page. The server outputs the binary data before the EXIF tags, sees the <% and then executes the code in the EXIF comment tag, stops parsing when it finds the %>, then outputs the remainder of the binary data.

I'm not sure whether this actually works, since I haven't tested it, but it sounds legit. A similar trick works with PHP, whereby any file upload system that allows you to upload an image with extension .php will allow you to exploit the EXIF tags by injecting <?php /* code here */ ?> into them.

share|improve this answer
In combination with a local file include vulnerability this would be quite powerful - ie not having to rely on poor extension filtering. I assume include(evil_image.jpg); would execute the embedded scripts.. – lynks Apr 29 '13 at 17:35
@lynks If the script is dropped into the webroot, then the attacker wouldn't need the include(), it can be executed directly. +1 sounds legit. – rook Jul 21 at 16:26

protected by Iszi Jul 21 at 14:11

Thank you for your interest in this question. Because it has attracted low-quality answers, posting an answer now requires 10 reputation on this site.

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.