This week Stephane Chazelas, an Akamai security researcher, discovered an interesting bug in the Unix Bash (Bourne Again Shell) shell – known as “Shellshock” or “Bash Bug”. This vulnerability affects a wide range of operating systems (Unix, Linux, OS X), routers, and other technologies, making many of the systems we use on a daily basis vulnerable to attacks. A system vulnerability in the GNU Bourne Again Shell (Bash), the command-line shell used in many Linux and Unix operating systems, could leave systems running those operating systems open to attack. The bug utilizes the Bash process variables that are passed by the operating system or an application. If Bash is configured as the default system shell, it can be used to attack devices via web requests, secure shell, telnet sessions, or other programs that use Bash to execute scripts. Patches for this vulnerability are now available for all the major Linux distribution vendors.
THE IMPACT
The reason this vulnerability raises many concerns is the breadth in threat vectors available to attackers. For example, the simple task of loading a website gives attackers the opportunity to exploit the vulnerability if the server handling your website request uses bash commands to access the information you requested. So if you still don’t think we use command line anymore, think again.
In fact, there are some computer programs that use Bash to execute commands on other computers. For example, how does a website know if you are accessing the site via mobile device or computer web browser? Based on the response your device returns ,the server will modify the content delivery to be compatible with the corresponding platform. From a technical perspective, your browser sends an agent to tell the web server that you are using either a mobile device or computer browser. The web server then uses that information to set the agent string as a variable before using Bash to execute code that generates the web page.
Attackers are making use of this vulnerability as we speak. Several researchers are reporting that honeypot infrastructures are being actively attacked by a group exploiting the Bash vulnerability. The vulnerability is allowing the installation of a zero day bash injected ELF malware that is currently being used. A system administrator using the @yinettesys Twitter account published a GitHub post reporting that threat actors exploited the Bash Bug flaw to launch kernel exploits on a computer system. The malicious code then performs a Web GET request from a user agent to begin a brute force dictionary attack to harvest credentials. The malicious code for this attack has been analyzed by virustotal and at this time there is 0/55 detection by antivirus.
PROTECTING YOURSELF
There are several detection methods that can be used to mitigate this risk. Since the Bash Bug affects versions 1.14 through 4.3 of the Bash shell, upgrading to the latest version will mitigate the risk.
From a web application standpoint, the bug can be exploited by code that passes through the Bash interpreter. CGI’s (Common Gateway Interface) and CGI scripts are the most affected, but anything that is passed to the Bash interpreter can be exploited. Command execution can be achieved through HTTP Headers and POST/GET parameters on vulnerable systems. So you could use a web application firewall to monitor the vulnerability in the header. Additionally, a signature will be added to the POST/GET field. This signature will monitor for attempts to bypass the detection signature via multiple whitespace using ( ){ command and ( ) { command and ( ) {.
Use an IDS/IPS to detect for any type of network communication; IDS/IPS will notify you when a connection is established and remote commands are executed.
We will continue to monitor the situation and post any new information we uncover to the Alert Logic blog.
SEE IF YOU ARE VULNERABLE
To see if you are vulnerable to this exploit run the commands below, the response will tell you if you are vulnerable
env x='() { :;}; echo vulnerable’ bash -c “echo this is a test”
If the system is vulnerable, the output will be:
vulnerable this is a test
An unaffected (or patched) system will output:
bash: warning: x: ignoring function definition attempt bash: error importing function definition for `x’ this is a test
CREDITS
https://lists.debian.org/debian-security-announce/2014/msg00220.html
http://blog.erratasec.com/2014/09/bash-shellshock-scan-of-internet.html#.VCRpVitdXKN
http://arstechnica.com/security/2014/09/bug-in-bash-shell-creates-big-security-hole-on-anything-with-nix-in-it/
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-6271
——————————————————
Here are signatures for the IDS for detection that have been provided by Alert Logic.
These rules have been created with resource consumption (No PCRE) of everyday average hardware to have more comprehensive coverage of use.
We have to use “any” here because lots of services open web servers on non-standard http ports such as cups and devices any, because local attacks would be common ground for this (cups, avahi, etc.) and http_header likely only uses a whitelist we will miss unique header values. This can also be bypassed due to the “within” modifer, but we got to try to narrow this down for resource issues.
External net would be the outside Internet IP address. Home Net would be any communication from internal IP space.
alert tcp $EXTERNAL_NET [1024:] -> $HOME_NET any (msg:”AL: HTTP Server
Headers Bash Environment Escape RCE”; flow:to_server,established;
content:”() {“; http_header; fast_pattern; content:”}|3b|”; within:20;
http_header; tag:session,5,packets; classtype:attempted-admin;
sid:1006236; rev:1; )
Uri and method are theoretical for now, but check just in case another server does this; any input poorly parsed to an internal scripting function like Popen could trigger:
alert tcp $EXTERNAL_NET [1024:] -> $HOME_NET any (msg:”AL: HTTP Server
URI Bash Environment Escape RCE”; flow:to_server,established;
uricontent:”() {“; fast_pattern; uricontent:”}|3b|”; within:10;
classtype:attempted-admin; tag:session,5,packets; sid:1006237; rev:1;
)
() { should never be in a method, so we don’t need additional checks here:
alert tcp $EXTERNAL_NET [1024:] -> $HOME_NET any (msg:”AL: HTTP Server
Method Bash Environment Escape RCE”; flow:to_server,established;
content:”() {“; http_method; classtype:attempted-admin;
tag:session,5,packets; sid:1006238; rev:1; )
POST values might get parsed by the end application into environment variables (parsers, interpreters, formats, etc.) making one just to be safe, this might false, though
alert tcp $EXTERNAL_NET [1024:] -> $HOME_NET any (msg:”AL: HTTP Server
POST Bash Environment Escape RCE”; flow:to_server,established;
content:”() {“; http_client_body; fast_pattern; content:”}|3b|”;
within:20; http_client_body; tag:session,5,packets;
classtype:attempted-admin; sid:1006239; rev:1; )
Now the big bad one. An uploaded file could have metadata parsed and stuffed into an env variable (cups is notorious for this.) The optimization for this is going to be hard, but we have to do it so we don’t parse the max file parse byte:
alert tcp $EXTERNAL_NET [1024:] -> $HOME_NET any (msg:”AL: File
Transfer Parsing Bash Environment Escape RCE”;
flow:to_server,established; file_data; content:”() {“; within:100;
fast_pattern; content:”}|3b|”; within:20; tag:session,5,packets;
classtype:attempted-admin; sid:1006240; rev:1; )
Alright, now cookie values for base64 && unserialize/json_decode values that could be used. This could likely false due to these characters used often in these compressed data formats. This attempt is totally random because we don’t know the size and start of random people’s base64 encoded values + so rule might not even work, but we need to try disabled unless we need it due to the unknown and random chance of it working customer specific values where the cookie is known can easily be replaced in this rule:
#alert tcp $EXTERNAL_NET [1024:] -> $HOME_NET any (msg:”AL: HTTP
Cookie value Bash Environment Escape RCE”; flow:to_server,established;
content:”=”; http_cookie; base64_decode:relative; base64_data;
content:”() {“; tag:session,5,packets; classtype:attempted-admin;
sid:1006241; rev:1; )
DHCP sets user hooks
alert udp $HOME_NET [67,68] -> $HOME_NET any (msg:”AL: DHCP Bash
Environment Escape RCE”; flow:from_server,established; content:”() {“;
fast_pattern; content:”}|3b|”; within:20; tag:session,3,packets;
classtype:attempted-admin; sid:1006242; rev:1; )
This article was also posted to the Alert Logic blog
About the Author
Stephen Coty joined Alert Logic in 2012 as the director of threat research and author of the Cloud Security Report, and has a wealth of experience in the security space. In his role at Alert Logic, Stephen is currently in the process of building a premier threat research team that is innovating the industry by taking a more proactive versus reactive approach to security through solid research, reverse engineering of malware, and constant searches for stolen data, all of which can be leveraged as actionable data for remediation. Stephen has over 15 years of experience in systems engineering and security consulting, in industries ranging from healthcare to finance and government. Most recently, he held a senior position at Rackspace Hosting as the Manager of Cyber Security, where he served as the architect of the Security Operations Center and Threat Research Team. He is also a member of ISSA, Infragard and the HTCIA.
