Web shell upload via extension blacklist bypass

This lab demonstrates how weak file upload defenses—specifically extension blacklisting—can be bypassed by manipulating how the server interprets file types. The core idea is simple but powerful: the application checks what the file is called, while the server decides how the file is executed. By exploiting that gap, you achieved code execution.

Objective of the Lab

The goal is to upload a web shell despite restrictions that block dangerous extensions like .php. The application attempts to prevent remote code execution by rejecting files with known executable extensions, but it does not enforce how uploaded files are ultimately handled by the server.

---

Initial Defense Mechanism

The application uses a blacklist to block uploads containing extensions such as:

• .php
• .phtml
• .php5

This creates a superficial barrier. If a user tries to upload shell.php, the request is denied. However, if the file uses an unrecognized extension, such as .shell, it passes validation.

The flaw here is that the system assumes:

“If it’s not .php, it won’t execute.”

This assumption is incorrect.

Key Exploitation Technique

The breakthrough came from injecting the following directive into the HTTP request body:

AddType application/x-httpd-php .shell

This line is an Apache configuration directive. It tells the server:

“Treat any file ending in .shell as PHP code.”

This effectively redefines how the server processes files. Instead of relying on .php, the server will now execute .shell files using the PHP interpreter.

Why This Works?

There are two separate systems involved:

1. Application-Level Validation

• Checks file extension
• Blocks known dangerous types
• Allows .shell because it is not blacklisted

2. Server-Level Execution

• Uses MIME-type mappings
• Executes files based on configuration
• Now treats .shell as PHP due to AddType

The vulnerability exists because these two systems are not aligned. The application trusts extensions, while the server trusts configuration.

---

Payload Upload

After successfully injecting the directive, you uploaded a file like:

exploit.shell

Containing PHP code such as:

<?php system($_GET['cmd']); ?>

Even though .shell is not normally executable, the server now interprets it as PHP. When accessed via the browser:

/uploads/exploit.shell?cmd=whoami

the command is executed on the server.

---

Role of HTTP Request Manipulation

A critical part of this lab is that the AddType directive was introduced through the HTTP request body. This suggests that:

• The server processes user input in a context that affects configuration
• Input sanitization is insufficient
• There is trust in user-supplied data where there should not be

In many real-world scenarios, this behavior is seen when .htaccess files are uploaded or when backend systems improperly merge request data into configuration.

---

Apache Internals Behind the Attack

Apache uses the mod_mime module to map file extensions to MIME types. When a request is made:

1. Apache checks the file extension
2. It maps the extension to a MIME type
3. It determines which handler should process the file

When mapped to:

application/x-httpd-php

the file is passed to the PHP interpreter.

By adding:

AddType application/x-httpd-php .shell

you modified this mapping. As a result:

• .shell → treated as PHP
• Execution occurs regardless of original extension intent

Why Blacklisting Is Ineffective?

Blacklisting fails because it:

• Blocks only known extensions
• Ignores server-side behavior
• Cannot account for configuration manipulation

Even if more extensions were added to the blacklist, attackers could:

• Use uncommon extensions
• Chain configuration-based attacks
• Exploit parsing inconsistencies

This makes blacklisting unreliable as a primary defense.

Conclusion: This lab highlights multiple critical security weaknesses that, when combined, lead to full remote code execution: the application relies on extension-based filtering instead of validating actual file content, allows user-controlled input to influence server behavior, permits execution within upload directories, and fails to isolate uploaded files from application logic. To properly mitigate such risks, a layered defense approach is required, including strict whitelisting of safe file types (such as .jpg or .png), validating file signatures (magic bytes) rather than trusting extensions, disabling script execution in upload directories, storing uploaded files outside the web root to prevent direct access, and blocking any form of configuration injection (such as disallowing .htaccess uploads or preventing user input from affecting server directives). The key takeaway from this lab is that file extension checks are not real security—they are merely assumptions; by injecting AddType application/x-httpd-php .shell, you effectively redefined how the server interprets files, transforming an allowed extension into executable code. Ultimately, the “Web shell upload via extension blacklist bypass” lab serves as a clear example of how superficial defenses fail against a deeper understanding of system behavior, reinforcing a core cybersecurity principle: security must be enforced at the execution layer, not just the input layer, which is what distinguishes basic testing from advanced exploitation.