16

I would like to ask a question regarding the classic uploading an image and executing php code exploit on a website.

So I have been trying out this exploit a website I'm supposed to hack (It's set up for us to try and hack it)

The webpage allows us to upload an image, and while changing the mime type using TamperData is easy, the webpage apparently checks if the last characters of the file is '.jpg' or '.jpeg' before allowing the image through.

Regardless of the placement of the PHP code(I've tried just php code, php code pasted at the end of the image file, php code in EXIF headers etc), the website just shows the image file when I open it after uploading (or an error in the case of plain php code saved as .jpg), since the extension is always jpg.

So in such a case, what should be done to execute the file as .php? (null bite poisoning does not work, neither does uploading the code as vuln.php.jpg or vuln.php;.jpg. Both just shows the image)

Improve this question
4
  • 1
    Just to check: you say "last characters of the file is '.jpg'..."; do you mean "last characters of the file name are '.jpg'..."?
    – CBHacking
    Jan 27, 2016 at 18:56
  • 1
    Are you sure it checks for .jpg or .jpeg not just jpg or jpeg, or maybe trailing spaces or other characters are allowed? If the latter you can do a double file extension attack. The double extension attack only works if the second extension is not a known mime type. So shell.php.jpeg could work if .jpeg isn't a valid mimetype (it is by default). Otherwise shell.php.jpg123 would also work
    – wireghoul
    Jan 28, 2016 at 2:50
  • Or if using old school bugs naming your file something like |ls%20-la.jpg may lead to command injection.
    – wireghoul
    Jan 28, 2016 at 2:55
  • symcbean.blogspot.co.uk/2016/06/…
    – symcbean
    Dec 3, 2016 at 23:29

3 Answers 3

Reset to default
14

Regardless of the placement of the PHP code [...], the website just shows the image file when I open it after uploading

Yes, that is how it should be. The server would be seriously vulnerable if it would interpret .jpg files as .php files depending on the content instead of the extension.

So in such a case, what should be done to execute the file as .php?

Without some kind of vulnerability in the code itself, you can't execute image files as PHP files, as any decent server would not allow this.

Without knowing more about the code, we can't do more than guess. If it's supposed to be vulnerable on purpose, I would guess that the extension check is probably broken.

You might try:

  • .htaccess: the extension check may interpret this as no extension, and it may be fine with that. If the server parses the .htaccess file, you can then gain code execution with image files via AddType application/x-httpd-php .jpg.
  • vuln.jpg.php: the check may check the first, not the last extension.
  • vuln.php5, vuln.php4, vuln.phtml, etc: the check may be a blacklist check, not a whitelist check, which may miss some extensions which may be interpreted by the server as PHP files. You can easily test this with a madeup extension such as foobar, if it passes, it's a blacklist filter.
  • LFI: You may have a directory such as misc with subdirectories uploads and configs, where configs contains PHP files, and uploads contains the image uploads. Then you may have code such as include "misc/" . $filename. Lets say that there is a check for directory traversal, so this should be bad code, but generally still somewhat secure, right? Well, included .jpg files are parsed and executed as any other file would be, and thus PHP code inside it will be executed. This example is a bit far fetched, but it's not completely inconceivably that something like this may exist.

tl;dr: You can execute jpg files as PHP files via .htaccess or via include. Additionally, you may be able to bypass the file extension check if it is insecure.

Improve this answer
2
  • 3
    Related to trying to bypass the filename check: try using a null byte as in foo.php\0.jpg. The language that processes the "ends with .jpg" check probably treats null bytes as a legal character. System calls for writing files stop reading the filename at the null byte. If the language's file writing functions don't abort on strings containing null bytes, then this could allow the filename to pass the "ends with .jpg" check but then get saved as "foo.php".
    – Macil
    Jan 28, 2016 at 2:04
  • 1
    While not the answer to your problem, the .htaccess file can be a self contained shell: github.com/wireghoul/htshells
    – wireghoul
    Jan 28, 2016 at 2:47
1

Just a thought - while not really hacking the server, being able to upload a jpg file with embedded self executing js from the exif, which can then cause mayhem on the client machine, would certainly be a security issue from the user's perspective. see: http://blog.trendmicro.com/trendlabs-security-intelligence/jpeg-files-used-for-targeted-attack-malware/

Improve this answer
1

When using TamperData some servers won't work. But using exif editor will work fine.

.jpg will be replaced to .php in http headers or burp suite

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .