CVE-2014-6271 Bash Vulnerability a.k.a Shellshock

CVE-2014-6271 a.k.a Shellshock is command execution vulnerability in Bash shell via. specially crafted environment variable. As per NIST, the exploitation has been demonstrated against vectors involving ForceCommand feature in OpenSSH sshd, the mod_cgi and mod_cgid modules in the Apache HTTP Server, scripts executed by unspecified DHCP clients, and other situations in which setting the environment occurs across a privilege boundary from Bash execution.

Due to the wide spread deployment and use of Bash shell on almost all Linux, OSX and other *nix based systems, this vulnerability is considered to be extremely critical with possible impact matching the Heartbleed issue, if not more.

Who is Affected?

Any application or system that invokes command through the bash shell can be potentially vulnerable. In order to exploit this issue in a target, an attacker needs to:

• Set any environment variable with his controlled data.
• Force the target to invoke any shell command through bash -c <cmd>

The immediate targets that can be exploited remotely are Web Servers with CGI support particularly those CGI scripts that are written in shell scripting. Apart from that, web applications written in various scripting language such as PHP, Perl, Python, Ruby etc. are equally vulnerable if deployed in CGI mode and the application at some point invokes shell command using functions like popen, exec, system etc.

How to Fix?

The bash shell needs to be updated to a patched version. For Debian based systems, it can be done using the following command:

apt-get install --only-upgrade bash

For RedHat or CentOS based system, following command can be used to update bash:

yum update bash

Note: The current fix in Bash is considered to be incomplete. A complete fix is yet to be released at the time of writing. The initial fix bypass is assigned the vulnerability identifier CVE-2014-7169.

Technical Analysis & Test Case

The simplest test case involves executing the following command in an affected bash shell:

If the string Vulnerable is printed, then the shell is affected by this issue.

Remote exploitation of this vulnerability can be demonstrated in a local environment using Apache/CGI based deployment and an affected version of Bash shell.

Sample CGI to demonstrate the vulnerability:

Following ruby script can be used as a test case for exploiting the above CGI for vulnerability detection:

The vulnerability can be confirmed if the HTTP response contains an additional header named X-Shellshock. Our FreeScan For Web Application service is updated with test to detect this vulnerability using a similar test case as described above. However it must be noted that the test is limited that uses common heuristic and should not be considered 100% reliable.

Reference:

• http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-6271
• https://rhn.redhat.com/errata/RHSA-2014-1306.html
• https://securityblog.redhat.com/2014/09/24/bash-specially-crafted-environment-variables-code-injection-attack/

5 Vulnerabilities That Surely Need a Source Code Review

We have been performing Source Code Review (SCR) of multiple Java/JavaEE based Web Applications during the recent past. The results have convinced us and the customers that SCR is a valuable exercise that must be performed for business critical applications in addition to Penetration Testing. In terms of vulnerabilities, SCR has the potential to find some of the vulnerability classes that an Application Penetration Test will usually miss out. In this article we will provide a brief overview of some of the vulnerability classes which we frequently discover during an SCR that are missed out or very difficult to identify during Penetration Testing.

Additionally we hope we will be able to provide answers for the following commonly asked questions:

1. I have already performed an Application Penetration Test. Do I still need to conduct a Source Code Review for the same application?
2. What are the vulnerabilities found during Source Code Review that are often missed by Application Penetration Test?

Read More: Web Application Penetration Testing Service

Approach for Source Code Review

The approach for SCR is fundamentally different from an Application Penetration Test. While an Application Penetration Test is driven by apparently visible use-cases and functionalities, the maximum possible view of the application in terms of its source code and configuration is usually available during an SCR. Apart from auditing important use-cases following standard practices, our approach consists of two broad steps:

Finding Security Weaknesses (Insecure/Risky Code Blocks) (Sinks)

A security weakness is an insecure practice or a dangerous API call or an insecure design. Some examples of weaknesses are:

• Dynamic SQL Query: string query = "SELECT * FROM items WHERE owner = '" + userName + "' AND itemname = '" + ItemName.Text + "'";
• Dangerous or risky API call such as RunTime.exec, Statement.execute
• Insecure Design such as using only MD5 hashing of passwords without any salt.

Correlation between Security Weakness and Dynamic Input

Dynamic construction of an SQL Query without the necessary validation or sanitization is definitely a security weakness, however it may not lead to security vulnerability if the SQL query does not involve any untrusted data. Hence it is required to identify code paths that start with an user input and reaches a possibly weak or risky code block. The absence of this phase will leave huge number of false positive in the results.

This step generally involves enumerating sources and finding a path between source to sink. A source in this case is any user controlled and untrusted input e.g. HTTP request parameters, cookies, uploaded file contents etc.

Five Vulnerabilities Source Code Review should Find

1. Insecure or Weak Cryptographic Implementation

SCR is a valuable exercise to discover weak or below standard cryptography techniques used in applications such as:

• Use of MD5 or SHA1 without salt for password hashing.
• Use of Java Random instead of SecureRandom.
• Use of weak DES encryption.
• Use of weak mode of otherwise strong encryption such as AES with ECB.
• Susceptibility to Padding Oracle Attack.

2. Known Vulnerable Components

For a small-medium scale JavaEE based application, 80% of the code that is executed at runtime comes from libraries. The actual percentage for a given application can be identified by referencing Maven POM file, IVY dependency file or looking into the lib directory. It is a very common possibility for dependent libraries and framework components to have known vulnerabilities especially if the application is developed over considerable time frame. As an example, during 2011, following two vulnerable components were downloaded 22 million times:

• Apache CXF with Authentication Bypass Vulnerability
• Spring Framework with Remote Code Execution Vulnerability

During an SCR, known vulnerable components are easier to detect due to source code access and knowledge of exact version number of various libraries and framework components used, something that is lacking during an Application Penetration Testing.

3. Sensitive Information Disclosure

An SCR should discover if an application in binary (jar/war) or source code form may disclose sensitive information that may compromise the security of the production environment. Some of the commonly seen cases are:

• Logs: Application logs sensitive information such as credentials or access keys in log files.
• Configuration Files: Application discloses sensitive information such as shared secret or passwords in plain text configuration files.
• Hardcoded Passwords and Keys: Many applications depend on encryption keys that are hardcoded within the source code. If an attacker manages to obtain even a binary copy of the application, it is possible to extract the key and hence compromise the security of the sensitive data.
• Email address of Developers in Comments: A minor issue, but hardcoded email addresses and names of developers can provide valuable information to attackers to launch social engineering or spear phishing attacks.

4. Insecure Functionalities

An enterprise application usually goes through various transformations and releases. The application might have legacy functionality with security implications. An SCR should be able to find such legacy functionality and identify its security implications. Some of the examples of legacy functionalities with known security issues are given below:

• RMI calls over insecure channel.
• Kerberos implementation that are vulnerable to replay attack.
• Legacy authentication & authorization technique with known weaknesses. 
• J2EE bad practices such as direct management of database/resource connection that may lead to a Denial of Service.
• Race condition bugs.

5. Security Misconfiguration

SCR should be able to find common security misconfiguration in application and its deployed environment related to database configuration, frameworks, application containers etc. Some of the commonly discovered issues include:

• Application containers and database servers are running with highest (unnecessary) privilege.
• Default accounts with password enabled and unchanged.
• Insecure local file storage.

Additional Notes

An in-depth Source Code Review exercise is a valuable activity that has significant additional benefits apart from those mentioned above.

It is possible to conduct an in-depth review of implementation of security controls such as Cross-site Request Forgery (CSRF) prevention, Cross-site Scripting (XSS) prevention, SQL Injection prevention etc. It is not uncommon to find codes that lack or misuse such controls in a vulnerable manner resulting in bypass of protection.

There are multiple APIs that are considered to be risky or insecure as per various secure coding guidelines. It is possible to discover usage of such API in a given application easily and quickly during an SCR process.

SCR has the added benefit of being non-disruptive i.e. this activity does not require access to production environment and will not cause any service disruption.

Source Code Review (SCR) is a valuable technique to discover vulnerabilities in your Enterprise Application. It discovers certain class of vulnerabilities, which are difficult to find by conventional Application Penetration Testing.  However, it must be noted that Application Penetration Testing and Source Code Review are complementary in many ways and both independently contribute in enhancing overall security of application and infrastructure.