How an OS Command Injection Spells Game Over For a Company

When it comes to the top types of vulnerabilities that can make a company keel over, experts all across the cybersecurity field agree that injection flaws fit the bill. Injection flaws can allow threat actors to relay malicious code via vulnerable applications onto a system, be it an operating system, a database server, LDAP server, and really anything that accepts scripting as input. 

Injection flaws, specifically Operating System (OS) Command Injection and Standard Query Language (SQL) Injection, take positions in the OWASP Top 10 list and the SANS Top 25, showing agreement throughout the industry that these are the most dangerous types of vulnerabilities out there.  

And not without good evidence. OS Common Injection played a big role in the Equifax data breach, hackers leveraging the vulnerability to leak the data of over 143 million US citizens. 

What is OS Command Injection? 

OS command injection is where threat actors leverage a vulnerability in an application functionality to execute OS commands on a system. Due to the fact the vulnerability comes from applications, no operating system is immune to this kind of cyber attack.  

These types of vulnerabilities often crop up due to lack of input sanitization as well as developers executing OS commands in an unsafe, possibly slapdash manner. This widens the attack surface and opens up companies who used these flawed applications and their operating systems to cyber attacks from threat actors. 

What makes OS Commands so devastating when they fall into the hands of threat actors is that they are the keys to absolute power on your operating systems.  

Attack vectors 

Essentially, threat actors can leverage the functionality of apps that include OS commands against systems by altering the parameters of scripts being sent to a Shell interpreter, which then passes it to the operating system. For example, if you had an application designed to delete logs and it uses RM OS command to achieve this, a threat actor could insert text that alters what is deleted. 

Threat actor could then easily devastate a company by: 

• Switching the file meant to be deleted, where by utilising the dot dot convention and pathways, an attacker can tell the system to travel up and down the file directory and land on another, more critical file to delete, like an important system library, which would cause a denial of service. 
• Inject arbitrary malicious OS Command, where the threat actor uses the OS command syntax to inject another operating system command that is catastrophic. In Linux, they could achieve this by using semicolons to add further commands and create chain commands, so that when the original command executes, the more malicious ones follow, such as an RM-RF slash command, which deletes the entire file system for many operating systems when enacted.  

Suffice to say, the latter is the worst-case scenario because a threat actor can use chain commands to overwhelm systems with a tsunami of destructive, all-powerful code.  

OS Command Injections can be utilised to: 

• Perform full system takeover.  
• Create denial of service.  
• Leak sensitive information, like passwords, cryptographic keys, user personal information, and confidential business data.  
• Allow threat actors to move onto other computers on the network. 
• Allow threat actors to both move onto other systems and use your system as a launching pad for further attacks, utilising botnets and/or performing cryptomining.  

As soon as a malicious actor has the capability of doing operating system commands, they really do whatever they want on that machine. 

It’s extremely important for developers and organisations to be aware of ways to mitigate this attack vector. 

How do you prevent an OS Command Injection?   

Preventing an OS command injection is paramount for businesses to survive in the modern world and a constantly evolving threat landscape. Here is a list of recommendations to mitigate the risk of OS Command injection occurring in applications and help safeguard organisations against this type of attack. 

1. Don’t execute OS commands 

This may sound a little peculiar and on-the-nose at first, but executing OS commands isn’t always necessary for applications to perform tasks. In fact, OS commands are a tool which, in the majority of cases, is rather heavy-handed. You can use safer, more lightweight means which are either built-in to the coding language you’re using or by utilising third-party libraries. 

An example of this can be found in Java, where instead of using the OS command RM to delete a file, you can use an in-built function. If you want to copy a file, same story. There are examples of that in Java and in other languages. 

By avoiding OS commands by using safer alternatives, the benefit is you can significantly reduce the attack surface by using tools which are more restricted to specific tasks. For example, while with an OS command a person can specify any command they want, a library function designed to delete a file can only delete a single file elsewhere in the system.  

This is where you may wonder why OS are used at all. Most of the time, a developer uses an OS command to introduce a quick fix, often due to not fully knowing the language they’re working with. They make the operating system do the heavy lifting as a shortcut, but this can open up a wide attack surface as consequence and is ill-advised.  

2. Have applications run at least possible privilege level 

Often people have applications run as superuser and root user, but in the majority of cases this isn’t needed and creates a bigger attack surface by adding more attack vectors that could have been easily avoided. 

When a threat actor compromises an application that runs at a high-level privilege, they can do a lot of damage. For example, if an application running as a root user can delete files, malicious actors can make it delete all kinds of critical operating system files, while if it only runs as tomcat user, their access and damage capability is limited. 

This recommendation is applicable to many other cybersecurity vulnerabilities, not just injection.  

3. Use explicit paths   

The way applications are found by operating systems and executed is based on system path settings. The problem with this is that you don’t necessarily require full pathways to find files, but not using full pathways can make yourself open a specific type of attack vector.  

If there's a shared folder for users on a system that’s writeable for any general user and that folder appears in the path before the actual folder containing the executable for the application, a threat actor may drop a malicious version of the application that the operating system will run into first and mistake for the legitimate one.  

To avoid this, you should always use the explicit, full path that outlines exactly where the right executable is for your operating system. This is also recommended for preventing DLL hijacking. 

4. Don’t run commands through shell interpreters 

There are various shell interpreters that take commands and pass them onto the operating system. These include SSH (cross-platform), bash (Unix), as well as CMD and PowerShell (Windows). 

Using OS commands and a shell interpreter can open you up to greater risk because shell interpreter syntax can give threat actors additional power due to things like chain commands, like with Linux’s semicolon. Chain commands allow an attacker to throw a volley of malicious actions at a system practically all at once, such as:  

• Downloading malicious code 
• Deleting files 
• Creating web shells 

This can wreak havoc on a system. This is and many more is why it is generally recommended that you avoid OS commands all-together, but if you have to for some reason utilise an OS command, there is another mitigation tactic. By running the OS command directly without the shell interpreter, you make any shell syntax a malicious actor might add useless. 

Shell syntax includes: 

• Semicolon.  
• Pi. 
• Ampersand. 
• Beck quotes. 
• Dollar sign. 

It’s important to note that this doesn’t completely erase the danger of malicious actors doing additional damage.   

There are ways that hackers can still circumvent this to do multiple commands, like using a single command like a shell script that is packed with some exploit that could trigger OS command execution on the parameters as they are passed in. 

5. If you have to run OS commands, use proper functionality 

If you still have to execute OS commands due to a real business need, it’s important to execute them correctly.   

For example, in Java there’s different ways to run an OS command. One common, ill-advised practice is having a full string of executables and parameters, which makes new parameter injection more likely as the hacker is more likely to be able to jam malicious scripts into an opening. 

To avoid this pitfall, it’s important to make sure that you’re using the safest functionality available. 

6. Don’t allow user input to directly reach the place where you execute the command unchanged, if possible  

Instead of allowing users to just specify a particular file when using OS commands, you can instead use symbolic IDs. Essentially, you could have numeric IDs that correspond to specific files, so when parameters come in an ID is passed in, a translation table in the code converting the number to its real filename and then deleting the file.  

The reason this is safer is because the threat actor can’t really specify anything malicious as the parameter value level. If they specify something that doesn’t exist in the internal mapping table, there will be an error as the parameter won’t be recognised.   

Essentially, they’ll be unable to sneak in any operating system commands or malicious parameters.  

Sanitisation 

Users communicate with your application via parameters most often, meaning that it's critical that you carefully sanitise them. The best sanitisation method is by using strict whitelists instead of blacklists. 

Whitelists are a tightly controlled list of what inputs are allowed, anything falling outside of this list being rejected. Whitelists deal with a strict, known pool of what is allowed, allowing you to effectively analyse and truly evaluate what input is acceptable.  

In contrast, blacklists, like their name may imply, are the reverse. This is a list of known dangers that aren’t allowed. However, threat actors are quite inventive with syntax and not all dangers can be known.   

Because of this, the whitelist strategy of knowing what’s verified and acceptable and rejecting everything else is seen as the superior cybersecurity strategy.  

Securiwiser 

Securiwiser greatly complements any organisation’s cybersecurity strategy. 

Securiwiser is a monitoring tool which allows you to check the cybersecurity posture of your company in real-time. It checks if there’s malware on your network, strange port activity, as well for injection attacks coming over from the internet, such as SQL injections, which can be leveraged to execute malicious OS command injections.