Shell Shocked: Achieving RCE via OS Command Injection in a Stock Checker

OS Command Injection is a critical vulnerability that allows an attacker to execute arbitrary operating system commands on the server running an application. While many vulnerabilities allow you to manipulate database records or bypass application logic, command injection hands you direct control over the underlying infrastructure.

In this walkthrough, I’ll break down how I exploited a seemingly harmless e-commerce “Check stock” feature to bypass input validation and execute system-level commands.

2. The Reconnaissance

The methodology begins with mapping the application’s functionality. The target featured a standard e-commerce utility: checking the inventory level for a specific product at a specific retail location.

I fired up Burp Suite to intercept the traffic and see what was happening under the hood. When I clicked the “Check stock” button for the London store, the HTTP request revealed a simple POST request passing two distinct parameters in the body: productId=1 and storeId=1.

Thinking about the underlying architecture, how does a backend actually check stock across different locations? It might be querying a database via an API, but it could also be taking those parameter values and passing them directly as arguments to a legacy internal shell script. If the latter is true, and the input isn’t sanitized, we have an injection point.

3. The Exploitation

To test the hypothesis, I sent the request to Burp Repeater. If the application was blindly appending my input to a system command, I could potentially break out of the intended command and chain my own using shell metacharacters.

I chose the pipe character (|), which in Unix-like systems tells the shell to take the output of the first command and pass it to the next, effectively executing both. I modified the storeId parameter from 1 to 1 |whoami.

The attack was a success. The backend application failed to sanitize the pipe character. It executed its intended inventory script, hit the pipe, and subsequently executed whoami. The server responded with a 200 OK and returned the name of the current executing user—peter-IfvjeY—directly into the HTTP response, which was then rendered on the front end.

4. Business Impact & Remediation

The Business Impact This is a worst-case scenario for a business: full Remote Code Execution (RCE). An attacker isn’t just looking at the user name; they can run commands with the privileges of the web server. This allows a threat actor to read sensitive configuration files, exfiltrate environment variables containing API keys, or establish a reverse shell to pivot deeper into the corporate internal network.

Remediation To prevent this, the development team needs to rethink how the application interacts with the underlying system:

1. Avoid Shell Commands: The most effective fix is to never call out to OS commands directly from the application layer. Developers should use robust, built-in language APIs or libraries to perform system tasks.
2. Strict Input Validation: If calling a shell command is absolutely unavoidable, the application must implement strict, whitelist-based input validation. Only allow known-good characters (e.g., strictly alphanumeric).
3. Escape Metacharacters: Any user-supplied data passed to a shell must be thoroughly escaped to ensure characters like |, ;, &, and $ are treated as literal strings, not executable operators.