10

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)?

8

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.

  • 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 '15 at 16:26

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