Segfault ethical hacking week 14

File Upload Vulnerabilities 

Hello! Welcome to my blog where I consistently document my penetration testing studies. Today, we're going to take a deep dive into a powerful vulnerability that can lead to a direct server takeover: File Upload Vulnerability.

What is a File Upload Vulnerability?

As the name suggests, it is a vulnerability that allows an attacker to upload any arbitrary file they want to the server. While it may seem simple, this vulnerability is extremely critical as it enables a wide range of attacks, from taking over the server's control via a 'Web Shell' to orchestrating DoS attacks and phishing campaigns.

• Cause: This vulnerability occurs because the server fails to properly validate the extension or content of the uploaded file. The server doesn't distinguish whether the uploaded file is an image or an executable file and simply allows it.

• Location: It can be found anywhere a file upload function exists, such as on forums, media galleries, or profile picture uploaders. You can easily check for this vulnerability by intercepting and analyzing the file upload request with a proxy tool like Burp Suite.

Attack Scenarios Using File Upload Vulnerabilities

So, what can an attacker do once they discover a file upload vulnerability?

• Upload a Web Shell: This is the core of the attack. By uploading a malicious script file that can be executed by the server (e.g., in PHP, JSP, ASP), the attacker gains the ability to issue commands to the server through a web browser. This is effectively the same as seizing control of the server.

• Denial of Service (DoS) Attack: The attacker can crash the service by uploading a file that is too large for the server to handle, or by uploading numerous files to exhaust the server's storage (disk space), thereby paralyzing normal operations.

• Upload a Phishing Page: An attacker can upload a fake login page (an HTML file) that looks identical to the real site. They can then lure users to this page to steal their usernames and passwords.

• Distribute Malware: Attackers can upload files containing malware to high-traffic forums, infecting the computers of an unspecified number of users.

• Deface Attack: This involves overwriting the website's main page (index.html or index.php) with a different file created by the attacker, thus altering the website's appearance.

💡 Server-Side vs. Client-Side Attack

• SQL Injection and Web Shells are Server-Side Attacks because they directly attack the server's database or system.

• XSS and CSRF are Client-Side Attacks because the malicious script operates within the user's web browser (the client). By uploading a file containing a malicious script, it's also possible to launch a Stored XSS attack.

Core Attack: An In-Depth Analysis of Web Shells

The crown jewel of file upload attacks is undoubtedly the Web Shell attack. It's so common that the terms "File Upload Vulnerability" and "Web Shell Attack" are often used interchangeably.

1. What is a Web Shell?

A web shell is a script that runs on the server and provides the attacker with a "web-based shell," allowing them to remotely execute commands. For example, here is a simple PHP web shell:

PHP

<?php
    // Executes the value of the 'cmd' URL parameter as a system command and prints the output.
    echo system($_GET['cmd']);
?>

If this file were uploaded to the server as webshell.php, the attacker could execute the ls -al command (to list files) on the server by simply entering the following URL in their browser, and see the result on their screen:

http://[Target-Site].com/uploads/webshell.php?cmd=ls -al

Gaining the ability to execute commands means you have completely compromised the server.

2. Key Challenges of a Web Shell Attack

1. Upload Executable Code: The attacker must create and upload a web shell that is compatible with the target server's language (e.g., PHP, JSP, ASP).

2. Find the Path of the Uploaded File: Even if the web shell is uploaded, it's useless if the attacker doesn't know its exact location (URL). Finding this path is the biggest hurdle in a web shell attack. The path can often be found by uploading a file and then copying the image address or file download link from the page where it's displayed.

Bypassing Weak Security Logic

Security administrators are aware of the dangers of file uploads and implement various defense mechanisms. An attacker must bypass these security logics.

• Content-Type Manipulation: If the server only checks the file's MIME type (Content-Type), an attacker can bypass this by uploading a web shell (webshell.php) and using Burp Suite to change the Content-Type in the request packet to something like image/jpeg.

• Bypassing Extension Filters:

  • Case Sensitivity: If uploading webshell.php is blocked, try mixing the case, like webshell.PhP or webshell.pHP.

  • Using Alternative Extensions: If the server only blocks .php, try other extensions that the PHP engine might still execute, such as .phtml, .php3, or .php5.

  • Using Special Characters: In some cases, adding a space or a special character after the extension can bypass the filter.

• Path Traversal: If the server has disabled execution permissions on a specific folder like /uploads/avatars/, an attacker can manipulate the save path. By including ../ (which navigates to the parent directory) in the filename, like ../webshell.php, they can attempt to save the file in a different, executable directory.

• Embedding a Web Shell in a Normal Image (Using a Hex Editor): This is one of the most sophisticated and common methods.

  1. Prepare a normal image file (e.g., normal.jpg).

  2. Open the image file with a Hex Editor and insert the web shell code, like <?php system($_GET['cmd']); ?>, at the end of the file or within its metadata.

  3. The server checks the file's signature (Magic Number) at the beginning, identifies it as a valid image, and allows the upload. However, this file is now a potential web shell that can be executed by the PHP engine. (Note: The method of execution can vary depending on the server configuration.).

Important Considerations for Penetration Testing (Crucial!)

When you discover a file upload vulnerability during a real penetration test, you must never upload an actual web shell. This is a highly aggressive action that directly impacts the system.

1. No Live Web Shells: If the goal is simply to check for the vulnerability, the standard procedure is to upload a harmless text file (test.txt) or an image file to confirm that a file can be uploaded and its path can be identified.

2. If You Must Verify Executability: If you absolutely need to prove that an uploaded file can be executed, it is best to upload a file with a very simple and harmless code, such as one that just prints "Hello World".

3. Always Get Permission: If you need to perform a demonstration by uploading a real web shell, you must first discuss it thoroughly with the client (or the person in charge) and obtain written permission before proceeding. Uploading a web shell without authorization can be considered a criminal act.