File Upload Vulnerability: Using Non-Executable Files

Published on March 20, 2025


In this section, we’ll explore how file upload vulnerabilities can be abused even when executing uploaded files is not an option. Attackers may still find ways to exploit an unrestricted file upload mechanism by leveraging other vulnerabilities such as Directory Traversal.

Understanding the Lolipop Web Application

We begin by analyzing the updated Lolipop web application at http://lolipop.com:8000.

1. Checking for Admin Access and PHP Files

We first test whether the application still has an admin.php or index.php file.

kali@kali:~$ curl http://lolipop.com:8000/index.php
404 page not found

kali@kali:~$ curl http://lolipop.com:8000/meteor/index.php
404 page not found

kali@kali:~$ curl http://lolipop.com:8000/admin.php
404 page not found

These responses confirm that the application no longer runs PHP.

2. Uploading a Non-Executable File

We attempt to upload a simple text file (test.txt) through the web application’s file upload form.

The upload is successful, but we must investigate whether we can manipulate the process further.

3. Testing for File Overwriting

When testing a file upload feature, it’s crucial to determine whether duplicate file names are handled. If the server rejects duplicates, it may provide clues about file storage or naming conventions.

4. Attempting Directory Traversal

We modify the filename parameter to include a relative path traversal sequence (../../../../../../../test.txt) in an attempt to write outside the web root.

The response includes the ../ sequences, but we cannot confirm whether the file was placed in the intended location.

Understanding Web Server Accounts and Permissions

Web applications running on Apache, Nginx, or IIS use dedicated service accounts, such as www-data on Linux. However, some applications run with higher privileges, increasing the potential for privilege escalation.

1. Overwriting SSH Keys for Privilege Escalation

If the web application is running as root or a privileged user, we may be able to overwrite the authorized_keys file in the root user’s .ssh directory. This would allow us to SSH into the machine using our own private key.

2. Generating an SSH Key

kali@kali:~$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/kali/.ssh/id_rsa): fileup
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in fileup
Your public key has been saved in fileup.pub

We then create an authorized_keys file containing our generated public key.

kali@kali:~$ cat fileup.pub > authorized_keys

3. Exploiting File Upload to Overwrite SSH Keys

We upload our authorized_keys file using the relative path ../../../../../../../root/.ssh/authorized_keys.

Figure 22: Exploit File Upload to write authorized_keys file in root home directory

4. Connecting via SSH

After successfully overwriting the authorized_keys file, we attempt an SSH login.

kali@kali:~$ ssh -p 2222 -i fileup root@lolipop.com
The authenticity of host '[lolipop.com]:2222 ([192.168.50.16]:2222)' can't be established.
ED25519 key fingerprint is SHA256:R2JQNI3WJqpEehY2Iv9QdlMAoeB3jnPvjJqqfDZ3IXU.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
...
root@76b77a6eae51:~#

Conclusion

In this tutorial, we demonstrated how even non-executable file uploads can be leveraged for privilege escalation. By exploiting directory traversal and overwriting system files such as SSH keys, attackers can achieve unauthorized system access.