Command Injection

Overview

Command Injection is the abuse of an application's behavior to execute operating system commands. Because the commands run with the same privileges as the application, successful exploitation can lead to sensitive file access, data exposure, and full remote code execution (RCE).

What is Command Injection?

Command injection happens when an application passes attacker-controlled input into a system shell or command execution function, allowing unintended commands to be executed on the server.

• Often called RCE because it enables remote command execution.
• Impact depends on the privileges of the running process (e.g., the web server user).
• Common in apps that run commands for file searching, network checks, backups, conversions, etc.

How it happens (High-level)

Applications sometimes use language features/libraries to execute OS commands (PHP, Python, NodeJS, etc.). If the input is not strictly validated or if the command is passed to a shell, attackers can inject operators to add new commands.

Detection Methods

Command injection is typically identified as one of two types:

• Verbose command injection: direct output is shown in the response (e.g., output of whoami is displayed).
• Blind command injection: no direct output; you infer success via timing delays or out-of-band effects.

Verbose testing

• Try payloads that produce visible output (Linux: whoami, id, ls).
• Watch for changes in the response body, new content, or errors.

Blind testing

If output isn’t visible, use time delays or forced output:

• Timing: sleep 5 (Linux), ping -n 6 127.0.0.1 (Windows), timeout 5 (Windows).
• Forced output via redirection: write output to a file and read it back if you have a read primitive.
• Out-of-band (OAST): use curl/wget to call your server and confirm execution.

Useful Payloads

Linux

• whoami — identify the running user
• id — user + group context
• ls — discover files/configs
• sleep 5 — blind timing test
• ping -c 5 127.0.0.1 — blind timing test
• cat /etc/passwd — test file read (only if safe/authorized)

Windows

• whoami — running user
• dir — list directory
• timeout 5 — blind timing test
• ping -n 6 127.0.0.1 — blind timing test

Prevention / Remediation

Reducing command injection risk usually comes down to removing shell execution from the equation.

• Avoid shell execution: prefer safe APIs instead of calling external commands.
• Do not concatenate input into command strings.
• Strict allowlists: validate input to a narrow expected format (e.g., digits only, hostname regex with tight rules).
• Use parameterized execution: if you must execute, pass arguments as an array (no shell), and reject special characters.
• Least privilege: run the service under a restricted user, limit filesystem/network access.
• Monitoring: log executed commands and unusual parameters; add alerting.

Practical (TryHackMe)

In the practical portion, test payloads to confirm whether command injection exists. If blind, use timing/OAST. Goal: retrieve the flag in /home/tryhackme/flag.txt.

Recap

• Command injection can escalate quickly into full compromise.
• Detect via verbose output or blind side effects.
• Remediate by removing shell calls, strict validation, and least privilege.