DVWA File Upload

In my previous article of DVWA series I have demonstrated how to exploit Command Injection vulnerability at low, medium, and high security in DVWA Web Application and we have also reviewed the php source code which was running on the server.

In this article, I will show you how to exploit File Upload vulnerability in the same web application at low, medium, and high security simultaneously by reviewing their php source code. Again, I am writing this article from very beginners’ point of view, keeping in mind you don’t know anything about File Upload vulnerability.

Before we go to exploit DVWA challenge let me clear your concept on File Upload vulnerability and understand answer to some questions like:

What is a Malicious File?

What is File Upload vulnerability?

Why File Upload vulnerability arises?

How to identify File Upload vulnerability?

Impact of Malicious File Uploads

How to protect application from this vulnerability?

What is a Malicious File?

Any file with any extension which has capability to harm the server, or your computer or mobile phone is malicious file. The malicious file can be a known malware or a file with any malicious content in it.

For example, a php file which has some dangerous php functions like system(), exec(), shell_exec(), etc. can be considered as a malicious file because using these functions anyone can execute OS command on the server and can remotely control the server. Similarly, a malware with extension exe, ps1, msi, etc. can be considered as a malicious file as it will also harm the device. 

What is File Upload vulnerability?

Whenever the web application allows to upload any other extension file to the server [other than the one which is mentioned there] then we say there is a file upload vulnerability or malicious file upload issue.

Suppose there is a file upload functionality in the web application and only jpeg & png extension file is allowed to be uploaded. When an attacker is able to upload any other extension file such as php, jsp, aspx, html, shtml, etc. or even any double extension file such as php.jpeg, asp.png, aspx.txt, etc. then we say there is a malicious file upload vulnerability in the application.

Why File Upload vulnerability arises?

Since an attacker is able to upload other extension(s) file other than the one which is mentioned so there is some type of validation issue with the application. Or the application is not properly validating file properties like its name, type, contents, or size while uploading.

Failing to properly enforce restrictions on above file properties could mean that even a basic image upload function can be used to upload arbitrary and potentially dangerous files instead. This file can contain any server-side script as well which will compromise the whole server when executed on the server.

Based on the execution of the file on the server it is given severity high and sometimes critical [if the malicious file is executed] and given severity medium [if the uploaded file is not executed on the server].

How to identify Malicious File Upload vulnerability?

Steps to identify malicious file upload vulnerability is very simple and are given below.

1. Firstly upload any valid file to check the functionality of the application.
2. Once valid file is uploaded successfully try to upload a malicious file having extensions php, jsp, html, shtml, etc. depending on the web server of the application.

In most cases Apache web server hosts php file, tomcat hosts jsp file and IIS hosts shtml, aspx or asp file. These are not hard coded and may get changed based on the type of server.

Make your malicious file according to the web server which the application is using.

For example, my dvwa application is hosted on Apache web server and is written in php language [I got to know from file extension login.php] so I will create a malicious file with php extension. Similarly, if the application will be hosted on IIS server, then I would create malicious file with asp or aspx or shtml extension.

I have created a file named malicious.php with the following content.

<?php  echo "If you see this means, this file has been executed";  $output = shell_exec('ls -la');  echo "<pre>$output</pre>";?>

Shell_exec() function in the above script is used to execute OS command on the Operating System of the web application where it is uploaded and returns the complete output as a string.

Impact of Malicious File Uploads

Impact of the malicious file upload depends on the restrictions imposed by the web application. For example,

• If the attacker is able to upload very large size file [says > 1 GB] then it will consume unnecessary server resources like bandwidth, disk storage and may also leads to DOS attack.
• If the application is not properly validating the file extension and uploaded malicious file gets executed, then it can fully compromise the server [Refer to low level section below for PoC]. In this case the attacker usually upload a web shell which opens a command prompt to access the compromised server [A web shell is a malicious script that enables an attacker to execute arbitrary commands on a remote web server simply by sending HTTP requests to the right endpoint].
• Sometimes, when the application does not properly validate the content of the file then even after uploading a valid extension file with malicious content in it can be executed by chaining it with other vulnerabilities like Local File Inclusion.[Refer to the high-level section below for PoC].

How to protect application from File Upload vulnerability?

As malicious file upload vulnerability arises due to improper validation of various file properties [like its name, type, contents, or size] while uploading. So primary way to avoid this vulnerability is implementing proper validation on above file properties.

Some of the file upload best practices for developers recommended by OWASP is as follows.

• List allowed extensions. Only allow safe and critical extensions for business functionality
• Ensure that input validation is applied before validating the extensions.
• Validate the file type, don’t trust the Content-Type header as it can be spoofed
• Change the filename to something generated by the application
• Set a filename length limit. Restrict the allowed characters if possible
• Set a file size limit
• Only allow authorized users to upload files
• Store the files on a different server. If that’s not possible, store them outside of the webroot
• In the case of public access to the files, use a handler that gets mapped to filenames inside the application (someid -> file.ext)
• Run the file through an antivirus or a sandbox if available to validate that it doesn’t contain malicious data
• Ensure that any libraries used are securely configured and kept up to date
• Protect the file upload from CSRF attacks

Refer this URL from OWASP for more info.

Now we have learnt the basics. Let us exploit File Upload vulnerability in DVWA application at low, medium and high level.

First of all, login into your DVWA application by default credential admin : password or something else which you have set.

Low Level

We will start from low level and will proceed to high level gradually. Click on DVWA security button on left pane to change the difficulty to low and select File Upload challenge.

We are inside challenge page. First of all, we will check its functionality then will proceed with the exploitation part. Let us upload a simple image hacker.jpg and check where it is being uploaded.

Our file is uploaded to the path ../../hackable/uploads/ directory. The part of the above screenshot indicated by arrow 4 represent two directories above the current directory. So, the uploaded folder path is http://localhost/dvwa/hackable/uploads/. You can see the file hacker.jpg in the below screenshot.

Let us upload our malicious file malicious.php which we have previously created and we found malicious.php uploaded successfully.

The uploaded file can be accessed using the URL http://localhost/dvwa/hackable/uploads/malicious.php. As you can see the output of $ ls -la command in the below screenshot.

Source Code Analysis

Let us analyze the source code of low-level security. Code present in Block 1 accepts the file from user and save it in a temporary folder. Block 2 checks whether file can be transferred to upload folder or not. And block 3 shows the message of successful file transfer to upload directory.

One thing to be noted in below source code that there is not any check implemented on file extension and other file properties like its size, content type, etc. That’s why we can upload our malicious php file instead of image file.

Medium Level

Now change the dvwa security to medium as shown below.

We got the same page as we had in low level challenge. Let us upload our renamed malicious file malicious-medium.php [with the same content]. This time we got an error, and it appears that the application is validating file extension.

Source Code Analysis

On analyzing the source code, we found blocks indicated by arrow 1,4 and 5 is same as we have seen in low level security. Block no 2, extracts the file information and store them in different variables. Block no 3 is the one which needs to be focused more. It checks the content type of the file which is being uploaded. Files with content type image/jpeg and image/png are allowed only and others are blacklisted. Also, it checks the file size. If the size of the file is greater than 100000 bytes [100 kB] then it will block the upload.

In our file malicious-medium.php the content-type was application/octet-stream [see below screenshot] that’s why it was blocking upload. Although the second condition for file size was valid.

Bypass

We can bypass the security by changing the content type of the file to image/jpeg during file upload. Simply upload the malicious-medium.php file and before uploading to server intercept it in burp proxy. Then replace the content type from application/octet-stream to image/jpeg or image/png as shown in the screenshot given below and forward the request.

We found that our malicious file got uploaded in the same folder uploads.

On accessing the file through the URL http://localhost/dvwa/hackable/uploads/malicious-medium.php we can see our uploaded file got executed.

High Level

Change the DVWA security level to High as shown below.

Let us upload our renamed malicious file malicious-high.php. This time too got the same error as was in medium level. I even tried to convert the content-type to image/jpeg [as we did in medium level] before uploading but it didn’t work. There may be some other checks or restrictions applied in high level security. Let us check it by analyzing the source code.

Source Code Analysis

On reviewing the source code found a unique block denoted by arrow 1. This block strictly checks the following image properties:

• File extension [should be png, jpeg or jpg only. File with other extensions is blocked]
• File size [should be less than 100 kB] and
• Image file signature [using getimagesize() function].

Failed to validate any of the above image property will block the upload.

In our file malicious-high.php the image signature as well as image file extension were not present that’s why it was not uploaded.

Bypass

Since malicious-high.php file didn’t have image signature and image file extension so what if we create a file having both the above image properties. If so, then we will be able to upload the file and will bypass the restrictions. But there is one problem that file with any image extension [jpg, jpeg, png] will not execute if we directly access it from its upload folder [as we did at low and medium-level security]. But if we access that file using some other vulnerability like LFI we will be able to execute the malicious code present inside that image file.

You may be surprised how a file with an image extension executes malicious code but that is true. LFI doesn’t check the file extension instead, it directly executes the code present inside the file.

In a nutshell I am going to follow the given below steps to upload malicious file.

1. Select a valid file with jpg or any other allowed image extension and before uploading it capture its request in Burpsuite.
2. Then remove all the content of the file except the starting few lines to preserve file signature.
3. Add malicious php code [payload] as shown below and forward the request. Your file will be uploaded.

Our jpg file with malicious content got uploaded.

Executing the Uploaded File

If we try to access the file using the URL http://localhost/dvwa/hackable/uploads/hacker.jpg we will get below error because our uploaded image file contains error and is forged.

To access this file via LFI vulnerability set the security level of dvwa to low then choose LFI vulnerability. Now simply go to the URL http://localhost/dvwa/vulnerabilities/fi/?page=C:\xampp\htdocs\dvwa\hackable\uploads\hacker.jpg [if your dvwa is installed on Windows OS] to trigger the LFI vulnerability to execute your uploaded file. If your dvwa is installed on Linux OS then go to the URL http://localhost/dvwa/vulnerabilities/fi/?page=/var/www/html/dvwa/hackable/uploads/hacker.jpg to execute the code inside the uploaded file and you will get the result. For a better view, you can check the result in source code through the URL View-source:http://localhost/dvwa/vulnerabilities/fi/?page=C:\xampp\htdocs\dvwa\hackable\uploads\hacker.jpg.

From the above result, we can confirm that we have successfully exploited the high-level challenge too.

So, we have successfully exploited File Upload vulnerability in DVWA web application at low, medium and high level security.

Thanks for reading this article on Malicious File Upload. Hope you would have learnt something new from it or have refined your concept on File Upload vulnerability. For any query and suggestion feel free to write us at [email protected].

References

https://cheatsheetseries.owasp.org/cheatsheets/File_Upload_Cheat_Sheet.html

https://portswigger.net/web-security/file-upload

https://owasp.org/www-community/vulnerabilities/Unrestricted_File_Upload