Web shell upload via path traversal

Overview of the Lab

This lab demonstrates a file upload vulnerability combined with path traversal, allowing an attacker to control where an uploaded file is stored on the server. By abusing this behavior, it becomes possible to place a malicious PHP file into an executable location and achieve remote code execution (RCE).

The objective is not only to upload a web shell, but to bypass directory restrictions enforced by the application and force the server to store the file in a location where it can be directly accessed and executed.

Vulnerability Context and Entry Point

The application provides a file upload feature intended to store user files in a restricted directory, typically something like:

/files/avatars/

However, the vulnerability lies in how the application handles the filename parameter. Instead of sanitizing or enforcing strict constraints, the server accepts user-supplied filenames and directly uses them when writing files to disk.

This creates an opportunity for path traversal injection, where directory navigation sequences can be embedded into the filename itself.

---

Exploiting Path Traversal in File Uploads

Path traversal relies on directory escape sequences such as:

../

Each ../ moves one level up in the filesystem hierarchy. By injecting this into the filename, an attacker can escape the intended upload directory.

In this lab, the payload used was:

filename="%2e%2e%2fshell.php"

This is URL-encoded, where:

• %2e%2e = ..
• %2f = /

When processed by the server, it becomes:

../shell.php

This instructs the server to store the uploaded file outside the /avatars/ directory, effectively bypassing the intended storage restriction.

---

Server Response and Confirmation

The server response clearly indicates that the traversal was successful:

The file avatars/../shell.php has been uploaded

This is a critical confirmation because it shows that:

• The application did not sanitize traversal sequences
• The file path was interpreted literally
• The file was stored outside the intended directory

At this point, the attacker has successfully controlled the file placement on the server.

---

Achieving Web Shell Execution

After uploading the file using path traversal, the next step is accessing it.

Because the file was saved using:

../shell.php

it resolves to a location outside /avatars/, making it accessible directly via:

/shell.php

Once accessed, the server processes the file as PHP.

If the uploaded payload is a web shell such as:

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

the attacker can execute commands through the browser:

/shell.php?cmd=whoami

This confirms remote code execution, as the server is now executing arbitrary commands provided by the attacker.

Why This Vulnerability Works

This vulnerability exists due to improper handling of user-controlled file paths. Specifically:

• The application does not sanitize ../ sequences
• It directly trusts the filename parameter
• It does not validate the final resolved path
• It allows execution of uploaded files

Because of this, an attacker can manipulate the filesystem path and bypass directory restrictions entirely.

---

Security Impact

The impact of this vulnerability is critical because it enables full control over file placement and execution.

By combining path traversal with file upload, an attacker can:

• Escape restricted directories
• Place files in executable locations
• Execute arbitrary server-side code
• Access sensitive system files
• Maintain persistent access

This effectively leads to complete server compromise.

---

Root Cause Analysis

The root cause is a failure to properly validate and normalize file paths. The application does not enforce strict boundaries on where files can be stored and allows directory traversal sequences to pass through unchecked.

Additionally, storing uploaded files in a web-accessible directory further increases the risk, as it allows immediate execution of malicious files.

---

Mitigation Strategies

Preventing this vulnerability requires multiple layers of protection:

• Strip or block ../ sequences from filenames
• Normalize file paths before writing to disk
• Enforce strict directory constraints
• Store uploaded files outside the web root
• Disable execution permissions in upload directories
• Rename files to random, non-user-controlled values

User input should never be trusted to define file paths.