Applications can be protected from ShellShock and other similar vulnerabilities by following secure application development best practices that are used to prevent Command Injection vulnerabilities. ShellShock is a special type of Command Injection.
What makes ShellShock different from other Command Injection vulnerabilities is that it is caused by using a vulnerable version of bash, a popular command interpreter that comes installed by default with many popular operating systems, rather than being caused by the application concatenating malicious data with system commands.
In spite of these special circumstances, applications that follow the secure application development best practices outlined in Security Innovation’s TEAM Mentor are effectively protected from ShellShock and other similar vulnerabilities before they are discovered. These best practices are:
- Use Positive Input Validation
- Avoid Using External Commands
- Use Parameterized APIs to Execute External Commands
What systems/technologies are affected?
A vulnerable copy of bash has been included by default with many popular UNIX/Linux operating systems for the past several decades. However, the presence of a vulnerable copy of bash is not itself sufficient to perform a successful attack – the attacker has to be able to trigger bash execution and pass malicious data to it as environment variables.
These additional restrictions place severe limitations on the usefulness of this vulnerability to actual malicious actors. This fact has obvious application security implications – if an attacker cannot take advantage of vulnerability in the platform via an application, the system is effectively protected. In this case, applications that don’t invoke bash are simply not vulnerable.
Not invoking bash (or other command interpreters) is one of the best practices described in TEAM Mentor – invoking command interpreters is never really a safe thing to do and there are usually safer ways to implement functionality that is performed by invoking them.
A vulnerable application occurs when the application accepts unvalidated malicious data and assigns it to environment variables (which happens by default with CGI) that are then passed to a vulnerable version of bash.
Examples of vulnerabilities:
- Any UNIX/Linux-based system with a vulnerable copy of bash might be vulnerable via an unexpected attack vector-Bear in mind that the first few patches failed to fix the vulnerability completely
- Public-facing web applications using CGI are the most vulnerable, easiest to exploit and the most actively exploited in the wild
- Legacy web applications are most likely to be vulnerable because they often use a mechanism called CGI for executing scripts that invoke bash. These legacy web applications are also likely to be running on a system that includes a vulnerable copy of bash.
- ASP.NET applications are NOT vulnerable…because they do not use bash
- Java applications will only be vulnerable in the rare cases when untrusted data is passed to bash as environment variables, which means that all three recommended best practices have to be violated to produce vulnerable code.
- PHP applications will only be vulnerable in the cases when PHP is used for CGI and invokes bash (which violates two of the three recommended best practices and CGI itself violates the third), when PHP applications include CGI scripts (like cPanel), or in the rare cases when untrusted data is passed as environment variables to bash by the application itself (this last one is very unlikely in practice and is only mentioned as a technical possibility for other specialists).
Actual attacks that have been detected in the wild range from people opening victims’ CD/DVD drive trays to installing backdoors to causing the target systems to join a botnet. A backdoor allows attackers to compromise the data on the target system or to use the vulnerable system as a pivot to carry out additional attacks against the systems on the same local network as the compromised system. Systems that become zombies in a botnet are commonly used to spread malware, send spam and perform DDoS attacks.
Prevention
ShellShock is a special case of Command Injection. The special aspect of ShellShock is that it is introduced by the platform rather than by the application itself. Nevertheless, the same best practices that are effective against regular Command Injection vulnerabilities are effective at protecting applications against ShellShock and similar potential vulnerabilities in the future.
Keep in mind, these best practices do not prevent the vulnerability from existing in the platform itself. However, an application that is running on a server that has a vulnerable copy of bash will not be exploitable if the application follows this guidance:
- Use Positive Input Validation - Input validation should prevent the exploit code from being accepted by the application. This is bypassed in special cases for this vulnerability, such as when CGI is being used, because CGI will assign untrusted data to variables and not all developers might be aware that this is happening and think to validate this data.
- Avoid Using External Commands - If external commands are not used, bash will not be called and the application will not be vulnerable.
- Use Parameterized APIs to Execute External Commands - If parameterized APIs are used to execute external commands, then the command interpreter (bash) will not be called when external commands are being used and then the application will not be vulnerable.
For specific information on how to prevent command injection, please visit Security Innovation’s TEAM Mentor Command Injection page at:
https://vulnerabilities.teammentor.net/article/94e52aca-06b6-4747-9bc9-f0149208f18c
-----
Want to be notified of any similar articles about Attack Trends? Click here to subscribe!
