Exploiting a PHP server with a .jpg file upload
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)
Just to check: you say "last characters of the *file* is '.jpg'..."; do you mean "last characters of the file *name* are '.jpg'..."?
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
Or if using old school bugs naming your file something like `|ls%20-la.jpg` may lead to command injection.
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.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
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
include. Additionally, you may be able to bypass the file extension check if it is insecure.
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".
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/