HOWTO: Everything you need to protect against ShellShock

We’ve got a lot of questions about how to protect your server against the shellshock bash vulnerability. Here are the answers.

Very Important!
Information about a critical vulnerability called Shellshock (or Bash Bug), which allows unauthorised code execution on remote systems, has been disclosed. Your servers and routers could possible be vulnerable. Currently, we are observing distributed scans of various subnets of the internet in search of vulnerable servers and theirs further infection with server malware.

What is it?
The Shellshock vulnerability can be exploited on systems that are running Services or applications that allow unauthorised remote users to assign Bash environment variables. Some of them:

• HTTP Servers that use CGI scripts (mainly Apache via mod_cgi and mod_cgid)
• OpenSSH servers that use the ForceCommand feature
• Certain DHCP clients

Details of vulnerability here: CVE-2014–6271, CVE-2014–7169.

Why is it dangerous?

1. The culprit in this situation, Bash, is installed by default on most Linux systems, which makes it an extremely dangerous vulnerability.
2. But even if you don’t use Linux or Mac OS X on your servers, you can still be affected by ShellShock. The vulnerability affects web-based administration of a slew of network devices (routers, NAS, electronic gadgets with remote control), one of which may be connected to your infrastructure. In this case, even login-password is not required to exploit vulnerability.
3. Attackers are now purposefully scanning subnet IP addresses to find vulnerable web servers.

How do I protect myself?

For systems in general

• Immediately update your version of Bash (see below) or replace Bash with an alternative interpreter. Be careful! First patch which appeared pretty soon after vulnerability disclosure and fixed CVE-2014–6271 still left opportunity for vulnerability exploitation. The new patch for CVE-2014–7169 has been just released! Be sure you applied both of them!
• In case update is not ready for your system, instead of using bash please configure dash or zsh (bash alternative) for all servers and users as a shell, by modifying the file /etc/passwd. Bash executable itself can be temporarily deleted from the system. But be careful, some of the scripts are written in such a way that they call /bin/bash directly and won’t work.
• Pay special attention to the GIT/SVN servers (clients themselves are not vulnerable) — fill out the recommendations for them on the dash settings for git users first.
• Scan all network devices you have on your infrastructure for ShellShock bug.
• Restrict access to sensitive services and devices which can be vulnerable (for example, using a firewall)

For web applications

• As an emergency measure (just for while you’re updating), you can disable application functionality implemented with CGI mechanism
• Filter user input to vulnerable servers by implementing new checks in your scripts.
• Enable proper WAF (see below), which blocks attempts to exploit Shellshock and other vulnerable applications by continuously analysing all the requests coming to your application

FAQ: How to check for Shellshock vulnerability

On each of your systems, you may check for Shellshock vulnerability by running the following command at the bash prompt:

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

If you see the following output, your version of Bash is vulnerable and should be updated:

vulnerable
bash: BASH_FUNC_x(): line 0: syntax error near unexpected token `)'
bash: BASH_FUNC_x(): line 0: `BASH_FUNC_x() () { :;}; echo vulnerable'
bash: error importing function definition for `BASH_FUNC_x'
test

If there is no vulnerable! in output, your version of bash is not vulnerable.

FAQ: How to update Bash?

The easiest way to fix the vulnerability is to use your default package manager to update the version of Bash

Ubuntu / Debian:

sudo apt-get update && sudo apt-get install --only-upgrade bash

CentOS / Red Hat / Fedora:

sudo yum update bash

To fix BashBug in Mac OS X, this OS X bash Update 1.0 is available.

Now check your system for vulnerability again.

FAQ: How to mitigate ShellShock threat with WAF (Web Application Firewall)

Web Application Firewall constantly analyses all the requests come to application. Though ShellShock is extremely destructive, it is rather easy to detect.

Red Hat customer portal gives quite effective CRS rules for opensource WAF mod_security tool. As it said there, the following mod_security rules can be used to reject HTTP requests containing data that may be interpreted by Bash as a function definition if set in its environment. They can be used to block attacks against web services, such as attacks against CGI applications:

Request Header values:

SecRule REQUEST_HEADERS ^(s*)s+{" "phase:1,deny,id:1000000,t:urlDecode,status:400,log,msg:'CVE-2014-6271 - Bash Attack'"

SERVER_PROTOCOL values:

SecRule REQUEST_LINE "^(s*)s+{" "phase:1,deny,id:1000001,status:400,log,msg:'CVE-2014-6271 - Bash Attack'"

GET/POST names:

SecRule ARGS_NAMES "^(s*)s+{" "phase:2,deny,id:1000002,t:urlDecode,t:urlDecodeUni,status:400,log,msg:'CVE-2014-6271 - Bash Attack'"

GET/POST values:

SecRule ARGS "^(s*)s+{" "phase:2,deny,id:1000003,t:urlDecode,t:urlDecodeUni,status:400,log,msg:'CVE-2014-6271 - Bash Attack'"

File names for uploads:

SecRule FILES_NAMES "^(s*)s+{"  "phase:2,deny,id:1000004,t:urlDecode,t:urlDecodeUni,status:400,log,msg:'CVE-2014-6271  - Bash Attack'"

But be aware of possible false positives. Here is a pretty good HOWTO for those who want to start using mod_security.

We’re sure that the most of commercials WAFs (as well as Wallarm) can effectively block ShellShock attacks to protected application.

Be protected!