Critical GNU Bash Vulnerability

On Wedneday, 24 September 2014, a new and very powerful vulnerability affecting Linux and Unix-based systems was published (CVE-2014-6271).

The vulnerability allows attackers to execute system commands on vulnerable systems and potentially compromise the integrity, availability and confidentially of information.  At the time of this writing, the vulnerability is used for malicious intentions including infecting vulnerable web servers and other affected services with malware but is also used in direct hacker attacks.

How does it work & gets exploited?

The vulnerability lies in the GNU Bash shell shipped with Linux and Unix distributions which mistakenly processes and executes commands within environmental variable definitions.  Thus, bash scripts that export variables from user defined input can be subject to exploitation.  Bash scripts are used by a large amount of applications and services in enterprise systems, either directly or indirectly.
For example, Apache servers using mod_cgi are directly affected if CGI scripts are written in Bash. DHCP Clients invoke shell scripts to configure the system with values taken from potentially malicious servers. Various daemons execute privileged programs (SUID) that may be vulnerable.
The above examples scratch only the surface as multiple exploitation patterns are identified each day.

What it reminds us of?

It reminds us of the SQL Injection pattern which is a generic vulnerability that affects poorly coded applications, but many exploitation patterns are published almost every day for enterprise applications that are affected.  Likewise, “Shellshock” affects many applications running on unpatched systems and it is only a matter of time for these bugs to get uncovered and massly exploited, even using popular tools like Metasploit.

How to check if a system is vulnerable?

It is very simple, run the command:

env x='() { :;}; echo vulnerable' bash -c "test"

If the shell returns “vulnerable” the system is affected.

How Obrela Security Industries protects their Clients from the threat?

In Obrela Security Industries Security Operations Centers the threat was identified at the time of disclosure with parallel operations immediately starting in order to build intelligence content to identify & block the threat and patch all the enterprise systems to fix the root cause.

• All of our systems and services were not affected by the vulnerability, as they do not make use of the affected elements.
• Our Corporate Security Intelligence SIEM platform monitoring all of our Clients, was heavily equipped with Correlation Rules identifying both exploitation attempts and post-exploitation of the system wherever applicable.
• Our Web Applications Firewall protecting our Client Web Sites was immediately equipped with fine-grained rules to block the threat and its incarnations.
• Our Regional Honeynet deployments were equipped with use cases to identify exploitation techniques and collect malware propagated through the attacks.
• Our APT and Malware Analysis Engines were specially utilized to extract behaviors from the malware collected. This behavior intelligence (eg IP Address accessed in-out, files modified, commands executed) are in real-time redirected automatically to the SIEM to benefit the security operations towards our Clients.
• Our Reputation Intelligence Feeds were populated with the behavior generated by our analyses and behavior collected from internet and task force feeds.

What our Clients should do?

The first thing that should be done is to identify the externally facing systems systems, check if they are vulnerable and proceed with patching. Different Linux distributions are offering patches for this vulnerability; and although not all patches have been proven to be completely effective, patching is the first thing to do.

Secondly, the internal systems running mission critical services should checked against the vulnerability and be subject to patching.

Third, and in parallel, the internal systems running business critical services checked against the vulnerability and be subject to patching, while an assessment of all enterprise assets including appliances should be performed in order to identify the rest of the systems that are affected.

Finally, operation critical systems should be checked against the vulnerability and be subject to patching, while the appliances’ vendors (VM based or hardware) should be reached to validate whether they products affected.