Using Non-Executable Files
In this section, we’ll examine why flaws
in file uploads can have severe consequences
even if there is no way for an attacker to execute the uploaded files.
We may encounter scenarios
where we find an unrestricted file upload mechanism, but cannot exploit it.
One example for this is Google Drive,
where we can upload any file, but cannot leverage it to get system access.
In situations such as this, we need to leverage another vulnerability
such as Directory Traversal to abuse the file upload mechanism.
Let’s begin to explore the updated “Mountain Desserts” application.
We’ll first notice that the new version of the web application
still allows us to upload files.
The text also reveals that this version of the application is running on Linux.
Furthermore, there is no Admin link at the bottom of the page,
and index.php is missing in the URL.
Let’s use curl to confirm whether admin.php and index.php still exist.
The output shows that the index.php and admin.php files
no longer exist in the web application.
We can safely assume that the web server is no longer using PHP.
Let’s try to upload a text file.
We’ll start Burp to capture the requests and use the form on the web application
to upload the test.txt file from the previous section.
The file was successfully uploaded according to the web application’s output.
Let’s review the upload request in Burp.
We’ll select the POST request in HTTP history,
send it to Repeater, and click on Send.
We receive the same output as we did in the browser,
without any new or valuable information.
Next, let’s check if the web application
allows us to specify a relative path in the filename
and write a file via Directory Traversal outside of the web root.
We can do this by modifying the “filename” parameter in the request.
The Response area shows us that the output includes the ../ sequences.
Unfortunately, we have no way of knowing if the relative path
was used for placing the file.
It’s possible that the web application’s response
merely echoed our filename and sanitized it internally.
For now, let’s assume the relative path was used for placing the file,
since we cannot find any other attack vector.
If our assumption is correct, we can try to blindly overwrite files,
which may lead us to system access.
Before moving forward,
let’s briefly review web server accounts and permissions.
Web applications using Apache,
Nginx or other dedicated web servers often run with specific users,
such as www-data on Linux.
When using programming languages that include their own web server,
administrators and developers often deploy the web application
without any privilege structures by running applications as root
or Administrator to avoid any permissions issues.
This means we should always verify whether we can leverage root
or administrator privileges in a file upload vulnerability.
Let’s try to overwrite the authorized_keys file in the home directory for root.
If this file contains the public key of a private key we control,
we can access the system via SSH as the root user.
To do this, we’ll create an SSH keypair with ssh-keygen,
as well as a file with the name authorized_keys
containing the previously created public key.
Now that the authorized_keys file contains our public key,
we can upload it using a relative path.
We will select our authorized_keys file in the file upload form
and enable intercept in Burp before we click on the Upload button.
When Burp shows the intercepted request,
we can modify the filename accordingly and press Forward.
If we’ve successfully overwritten the authorized_keys file of the root user,
we should be able to use our private key to connect to the system via SSH.
We should note that often the root user does not carry SSH access permissions.
However, since we can’t check for other users by,
for example, displaying the contents of /etc/passwd, this is our only option.
The target system runs an SSH server on port 2222.
Let’s use the corresponding private key of the public key
in the authorized_keys file to try to connect to the system.
Before we proceed, in the Directory Traversal Learning Unit,
we connected to port 2222 on the host mountaindesserts.com
and our Kali system saved the host key of the remote host.
Since the target system of this section is a different machine,
SSH will throw an error because it cannot verify the host key it saved previously.
To avoid this error, we’ll delete the known_hosts file
before we connect to the system.
This file contains all host keys of previous SSH connections.
We’ll use -i to specify our private key and -p for the port.
We could successfully connect as root with our private key
due to the overwritten authorized_keys file.
Facing a scenario in which we can’t use a file upload mechanism
to upload executable files,
we’ll need to get creative to find other vectors we can leverage.