File upload vulnerability is a type of vulnerability that allows an attacker to upload malicious files to a website, which can then be executed on the server or used to compromise the website. This type of vulnerability can be found in web applications that allow users to upload files, such as file upload forms or forums that allow users to upload images or attachments. 

An attacker can exploit this vulnerability by uploading a malicious file, such as a script or executable, which can then be executed on the server or used to gain unauthorized access to the website.

In this chapter, we will delve into the critical aspect of web application security concerning file uploads. Chances are, most of you have come across web applications that offer the convenient functionality of file upload, often in the form of images, videos, documents, and more.

However, if a web application has poor (or no) security mechanisms to prevent certain kinds of files, such as server-side scripting, then that can result in arbitrary code execution on the server. Even with limited file upload capability, we can execute arbitrary JS (XSS), and CSRF, and run client-side exploits.

How to prevent file upload vulnerabilities? 

File upload vulnerability is a type of vulnerability that allows an attacker to upload malicious files to a website, which can then be executed on the server or used to compromise the website. This type of vulnerability can be found in web applications that allow users to upload files, such as file upload forms or forums that allow users to upload images or attachments.

An attacker can exploit this vulnerability by uploading a malicious file, such as a script or executable, which can then be executed on the server or used to gain unauthorized access to the website. The uploaded file can also be used to gain unauthorized access to sensitive information, steal user data, or launch a distributed denial-of-service (DDoS) attack.

The vulnerability can occur due to several reasons: 

File upload vulnerabilities occur when an application allows a user to upload a file, such as a picture or a document, to a server. If the application does not correctly validate the file, an attacker may be able to upload a malicious file that could compromise the server's security. This can allow the attacker to execute arbitrary code on the server, or to access sensitive information stored on the server.

Several types of attacks can be used to exploit file upload vulnerabilities. For example, an attacker may try to upload a file that contains malicious code, such as aPHP scriptor anexecutable file. The attacker could then access the file from the server and execute the code, potentially gaining access to sensitive data or taking control of the server.

Another type of attack that can be used to exploit file upload vulnerabilities are called "cross-site scripting" (XSS). This type of attack involves injecting malicious code into a website, which is then executed by the victim's web browser. If a user is tricked into uploading a file that contains XSS code, the code could be executed on the server and potentially compromise the security of the system.

Set up DVFU

Let's go straight to demonstrate file upload vulnerability using the Damn Vulnerable File Upload Lab web application. Damn Vulnerable File Upload Lab is designed to practice File Upload vulnerabilities. Before getting started, our first priority is to set up this web application within our local machine.

Follow the below steps to set up the server:

1. To set up the File Upload Lab web application, firstly, we have to clone it from GitHub. 

2. Now, we will have to copy the DVFU directory to the web directory. 

3. Now, let me run the apache2 service.

4. Once the Apache2 service starts, we can easily access the web application through any browser.

If you have noticed, we are presented with various levels of an HTML form that asks us to upload a file.

Let's visit the Level 1 section, and see if we can upload and run our own PHP script on the backend:

In this section, there will be no security restrictions, so it means, we can upload malicious files. Let’s see if we can upload and run our own PHP script on the backend. 

Let's create a simple PHP file containing the following code, which displays the PHP information.

The preceding code executes the phpinfo() when executed by a PHP interpreter. We use this to check if the uploaded PHP file is successfully executed on the server side or not.

We get a successful upload message and path information for the file as well. Let's try to access the file to see if PHP code execution is possible on the server.

Look at that! Our PHP code ran on the server successfully. This payload was benign and only intended for testing. 

Similar to the previous level, Level 3 is also the same, where Developers add a blacklist for the PHP file extension and its other variants but forgot to do something to blacklist.

In this section, Developer adds a blacklist for certain file extensions but forgets something to restrict, which is considered harmful.

Let’s try to upload the previous file extension to see if this file uploaded successfully or not.

Click on "phpinfo.phtml" and click on open.

Now, we will upload this file and see whether it is uploaded successfully or not.

Once uploaded, open the UPLOADED link in another tab.

Look at that! Our PHP code ran on the server successfully. This payload was benign and only intended for testing. 

Let’s move on to Level 4. 

In this section, if we try to upload our previous file, we receive the following error, which means, we can only upload the .gif file extension.

Every document or file has a valid MIME type, which is an identifier consisting of two parts, a type, and a subtype, separated by a forward slash. Web developers, at times, rely on the MIME type of the uploaded file to verify whether it's a safe file or not. For an image upload application, the allowed MIME types can beimage/jpeg, image/gif, andimage/png. 

The following PHP code only allows GIF files by verifying the file's MIME type during the upload process:

Let’s try to upload this file(phpinfo.php) after changing its file extension to gif. 

Now, let’s try to upload it again. 

As you can notice, the upload was successful. 

Let’s try to open this link. 

The upload was successful, but the uploaded file not running as a PHP file, as the file acts as a gif file. We can bypass this check by simply changing the MIME type through an intercepting Proxy. 

Launch Burp Suite from the application menu.

Tap on the Proxy tab, and turn on intercepting mode. 

Now, go back to the Firefox browser and change the proxy setting to Burp suite using the Foxy Proxy extension.

Now, let's try to upload the gif file again. Once, we click on the upload button, we will automatically intercept HTTP headers.

Here, we will have to change the file name to .php extension. 

If you have noticed, the MIME-type is an image and the subtype is a gif. 

Once we forward the headers, we will receive a successful upload message. Since, this time, the MIME type matches one of the image file's MIME types, we successfully bypassed this check and uploaded the file to the server.

As you can notice, we have received the successful upload message. Once uploaded, open the UPLOADED link in another tab.

Look at that! Our PHP code ran on the server successfully. This payload was benign and only intended for testing.

Let’s move on to the Level 5 section. 

In this section, if we try to upload the .php file, we will receive the following error message. 

Let’s try to upload "phpinfo.php" again after changing the content type. 

But similar to the previous, we have received the same problem.

If we try to upload a gif file, we will receive a successful upload message. 

Since, the uploaded file is in form of image format, which means it can’t run as a PHP file.

Similar to the previous level, if we try to change the file format name to PHP, we will receive a similar "Failed" message. 

The following PHP code does not allow HTML, or PHP files during the upload process:

There are two ways in which we can trick Apache to execute a file with a safe extension as PHP. 

• TheSetHandler method
  
• TheAddTypemethod

Using Set Hander Method

We uploaded the following.htaccessfile, which tricks Apache to execute any file containing ".gif" as a valid PHP file by forcing through theSetHandler directive:

Open a text editor and type the following code. 

Now save it as .htaccess. 

Remember to save this file in a fresh directory(like Download, Document), where there will be no hidden files and directories.

Now, We will have to upload the .htaccess file, which tricks Apache to execute any file containing .gif as a valid PHP file by forcing through the SetHandler directive.

Now, we upload the file with the name phpinfo.gif. 

Once it is uploaded, we can access the file.

As you can notice, this safe .gif file gets executed as a valid PHP file.

Using the AddType method

Similar to the SetHandler method, here, we instead map a new file extension, such as .lol, which gets executed as a PHP file.

To achieve this, we upload the following as the .htaccess file.

Then we upload a file with .lol as the file extension, say phpinfo.lol, and then, access the file from a browser.

Observe the file extension in the URL, it's .lol, which gets mapped to PHP and is executed accordingly.

Let’s move on to the Level 6 section. 

Here, If we try to upload any file which contains PHP and HTML codes can easily be detected.

In this section, there's a function, called getimagesize() function, which basically reads a file, and returns the size of the image, if a correct image file is provided. In case an invalid file is thrown, then the getimagesize() function silently fails. The property of this function is used to verify if the file is an image or not.

However, there are techniques that can effectively lead to the bypass of this protection. Consider the following PHP code, which uploads the file whengetimagesize() passes through and returns an error in case of an invalid image file is tried for upload:

However, there are techniques that can effectively lead to the bypass of this protection. We can easily bypass such checks by adding the Magic code of the same file extension.

You can find out the proper magic code below the link: 

Copy the GIF signature code on "phpinfo.gif".

Now, the file should get uploaded without any problems. But, we will have to modify the file name to .php through Burp Suite.

Now, we shall go ahead and access the file. 

Look at that! Our valid GIF file containing our PHP script was uploaded successfully and was executed as expected. 

So, here, we've successfully defeated the getimagesize() function and uploaded our payload.

Let’s move on to the Level 7 section. 

Here, in this section, if we try to upload any file, then we will not receive any link, on which the file is uploaded.

The following PHP code will allow XSS files. But, we can find out the file location using cross-site scripting file upload vulnerability. 

Save a file with the following cross-site scripting code. 

Now, upload it. Once we upload this file, we will prompt us with the domain name. 

Let’s try to find out, there will be the uploaded file are located. 

The file is uploaded within this same directory.

Let me change this PHP file name to the PHP info file. 

As expected, we have successfully accessed the PHP file.

Netcat is often called the Swiss Army knife of hackers and penetration testers. Netcat allows reading/writing to TCP/UDP connections and has a large set of functionalities, ranging from port scans to file transfer mechanisms. However, here, we'll use Netcat to access a reverse shell. 

First, we'll need a PHP script that is capable of creating TCP connection-based reverse shells. Open a new terminal and copy the php-reverse-shell command. 

After this, we have to configure the reverse shell PHP file by providing a proper IP and port, so that it can connect with the NetCat listener.

Once the php-reverse-shell.php file is configured, upload the file:

Before that we initiate the reverse shell, we need to create our NetCat listener. Let's create a listener on port 1234.

As soon as we click on the link, our Netcat gets a reverse shell from the server, and we can happily execute commands through this interactive command shell.

This continuous reverse shell is very useful when we want to exploit further into other systems or execute a privilege escalation exploit.