Operating System Command Injection vulnerabilities and the danger they present

Today we’ll discuss Operating System Command Injection vulnerabilities. How much of a threat are they? How can you prevent these vulnerabilities? How NexDAST helps to remedy them? We’ll answer all these questions in detail below!

What are Operating System Command Injections?

Don’t confuse command injection with code injection. A malicious code getting injected into a programming language is a code injection vulnerability. OS command injections are a type of payload that the hacker injects. The payload then gets executed as an operating system command. 

A hacker executes a temporary operating system command on the applications’ server resulting in the risk of the application and data being compromised. OS command injection vulnerabilities are often used as a stepping stool by hackers. This is the worst-case scenario with OS command injections, as it starts with OS command injections and leads to exploitation of other parts of the hosting infrastructure resulting in a  whole host of other systems becoming exposed.

Python, Ruby, Perl, Java, C, PHP. All these programming languages enable users to call a system shell command. This makes them vulnerable to OS Command Injections. Yet, the injected temporary command execution depends on the privileges of the web-server. This is why command injection vulnerabilities aren’t that dangerous on their own. But a hacker can exploit privilege escalation and access more information. With that information, more vulnerabilities can be found and exploited.

Examples of OS Command Injection vulnerabilities

Let’s say you want to buy a keyboard from a website. The application has to first let you see if the keyboard you want is in stock. Users get this information via URLs like this one:

https://Keyboard-website.com/StockStatus?ProductID=111&StoreID=22

The application asks legacy systems to provide the user with stock information. Calling out to a shell command represents this functionality. Product and store IDs are arguments, so the shell command looks something like this:

Keyboards.py 111 22

Users now see if their preferred keyboard is in stock. Yet, there’s an issue here. The application isn’t secured against OS command injections. Hackers can now submit an input which executes a temporary command. It looks something like “& echo randomstring &” in the storeID parameter. The application then executes this command:

Keyboards.py & echo randomstring & 22

What does this command do? It makes the supplied string echo in the output. An efficient way to test for types of OS command injections. The shell command separator ( & ) turns one command into three. Users then see three results:

Error - productID was not provided
Randomstring
22: command not found

The original Keyboard.py command executed, but the expected arguments were missing. This is why we got an error message. The supplied string (Randomstring) echoed in the output. That’s the goal of the injected echo command. But, 22: command not found is showing. Why? Because the 22 original argument executed as a command, causing an error.

Now, let’s cover blind OS command injection vulnerabilities. This occurs when an application doesn’t return the output from a command in its response. Despite this, hackers still have various techniques to exploit these vulnerabilities:

  • time delays
  • redirecting output

Using an injected command to trigger a time delay enables a hacker to confirm if the command was executed. The time it takes for an application to respond is what tells you if the command executed or not. One of the most effective commands for exploiting this blind vulnerability is a ping. This command lets you pick an exact number of ICMP packets to send. That number will be the time needed for this command to run.

Redirecting output is another OS command injection exploit. You redirect the output of the injected command directly into a file. That file is found within the webroot that’s retrieved via your browser.

Preventing Operating System Command Injections

How can you prevent OS Command Injections? The simplest and most effective way is never to use shell_exec or similar calls for host OS commands. Apply the same commands in the programming language that you’re using instead. A problem appears if your programming language doesn’t have a corresponding command to the one you need. In these cases you should use input sanitization. It will help if you do this before you assign the value to the shell command. Whitelist usage is always the safest option when it comes to injections.

Other options of powerful input validation include:

  • Alphanumeric character validation (Confirm the inclusion of only alphanumeric character without whitespace or syntax in the input)
  • Number validation (Confirm that the input is a number)
  • Permitted values whitelist (Confirm against whitelists of allowed values)

You should never avoid shell metacharacter and try to sanitize the input that way. Since that makes the input vulnerable to smart hackers, which they can bypass easily.

How NexDAST can help prevent Operating System Command Injections

The simplest and most effective way to prevent OS Command Injections is to utilize NexDAST. Our black-box security testing solution automatically examines your application. When an OS Command Injection is detected, remediation guidelines are sent to the developer or SecOps team. No need for lengthy and sluggish manual testing with NexDAST. 

Example of NexDAST identifying an OS Command Injection:

vulnerable.com/site/ping?ip=8.8.8.8%3B+%2Fbin%2Fcat+%2Fetc%2Fpasswd

The %3B+%2Fbin%2Fcat+%2Fetc%2Fpasswd part is the vulnerability. NexDAST also provides remediation guidelines that help you remedy this vulnerability as efficiently as possible.

Want to find out more about NexDAST? We’ve covered it in-depth in one of our blogs before, and if you have a problem that NexDAST can help with, request a demo here!