BASH Shellshock vulnerability – Update5

Update5: We have added a new profile in Qualys VM that uses the advanced crawling capabilities of Qualys WAS to detect Shellshock in CGI programs. WIth this profile you get better coverage than with the current QID 13038. There is a good explanation of how to setup the profile at our blog post: Custom Option Profile To Detect Bash Shellshock

Check it out. I am looking forward to your feedback.

Update4: Our web application scanner (WAS) has been updated with a Shellshock detection. Look for QID 150134 in your WAS scans. Differently from our VM detections, WAS has an advanced crawler with JavaScript capabilities which allows you to cover the entire website and probe for CGI scripts susceptible to Shellshock on a much wider range.

Update3: The last couple of days have been filled with new information on Shellshock. Today for example we had news on a first botnet that is using Shellshock, illustrating the speed  We are working on adding checks into other relevant areas, such as our Web Application Scanner. Stand by for more news on that. In the meantime we have collected a number of community posts on how to use QualysGuard to detect and report on Shellshock. Here is a quick run-down for your reference:

• How to Report Shellshock in Qualys
  • Comprehensive Detection via Shellshock Option Profile in Qualys VM
  • Qualys Authenticated Detection
  • Qualys Remote (Unauthenticated) Detection
• Using Qualys WAS Scan to Detect ShellShock Vulnerability
• How to Get Alerts for Vulnerable Systems
• How to Block Shellshock Attacks

Update2: More news around the Shellshock vulnerability. Our Web Application Firewall (WAF) has the signatures needed to detect and block Shellshock attacks against websites. The detection is very reliable and is activated by default in the "normal" and "aggressive" settings on the WAF configuration page. For more technical details on the WAF filtering and its timeline take a look at Johan’s post.

We are also publishing our third detection for ShellShock. The new QID 13038 is focused on the web attack vector through CGI and works without authentication. Ses’s blog post explains the logic behind the check.

Make sure to take a look a both posts as they can help you with a Shellshock mitigation and for a quick remote check on your websites. Closing attack vectors can be a good way to mitigate some of the attacks, but to track Shellshock you need to use authenticated scanning checking for QID 122693.

Update: Tavis Ormandy pointed out in a tweet that the fix for CVE-2014-6271 is incomplete and does not catch all possible exploit vectors. CVE-2014-7169 has been opened to track this extended issue. We expected a new patch to come out today that addresses this newly found vector. Our CISO Jonathan TRull pointed me to a Github entry that documents an exploit attempt that downloads malware using this vulnerability – see Ok, shits real. Its in the wild… src:162.253.66.76

Qualys scanners are considered not exploitable via the BASH vulnerability. Although Qualys scanners have a version of Bash vulnerable to CVE-2014-6271 installed, the scanner exposes no listening interfaces and services to the network, closing the common attack vectors discussed in the release of CVE-2014-6271. Further Bash is not used in any of the communication mechanisms that the scanner uses: scan dispatching, software updates and monitoring.  We will update Bash on the scanner in the next system update cycle.

Original: Today vulnerability CVE-2014-6271 (also known as shellshock) in Bash was published. It allows the attacker to specify arbitrary commands to execute by formatting an environment variable in a specific way. Bash (the Bourne Again SHell) is the default command interpreter for Linux and many other Unix versions and is consequently widespread use. But by itself the vulnerability is not that terrible, after all it is a local vulnerability and BASH is a command interpreter, its only reason to exist is to execute commands, so not such a big deal…

Unfortunately this is not quite true as we need to look at how Bash is used. True in its normal form as command interpreter the attack vectors are quite small. However Bash is very often involved in a networked setup to execute commands and that opens up an interesting attack vector. Imagine a webserver that allows you to ping an IP address (my router at home has that function for example), it will most likely just call the "ping" executable with the argument that you supplied, probably checking whether the argument is formatted correctly as an IP address. With CVE-2014-6271, if you can control the value of an environmental variable given to the shell, you can make the shell run arbitrary commands. Controlling an environmental variable is not that difficult, as a large number of environmental variables are under control of the attacker, such as the settings for the Referer or the UserAgent. Consequently scenarios where a CGI-BIN setup is used to execute commands on the server can be attacked quite easily.

RedHat has an extended list of situations that involve Bash in a remote context and you can see it has the potential be a widespread problem, similar to Heartbleed in April. Some of the security researchers involved at the time, namely @ErrataRob have already started their Internet wide scans looking for vulnerable servers:

• Apache server using mod_cgi or mod_cgid are affected if CGI scripts are either written in bash, or spawn subshells. Such subshells are implicitly used by system/popen in C, by os.system/os.popen in Python, system/exec in PHP (when run in CGI mode), and open/system in Perl if a shell is used (which depends on the command string)
• ForceCommand is used in sshd configs to provide limited command execution capabilities for remote users. This flaw can be used to bypass that and provide arbitrary command execution. Some Git and Subversion deployments use such restricted shells. Regular use of OpenSSH is not affected because users already have shell access.
• DHCP clients invoke shell scripts to configure the system, with values taken from a potentially malicious server. This would allow arbitrary commands to be run, typically as root, on the DHCP client machine.
• Various daemons and SUID/privileged programs may execute shell scripts with environment variable values set / influenced by the user, which would allow for arbitrary commands to be run.
• Any other application which is hooked onto a shell or runs a shell script as using bash as the interpreter. Shell scripts which do not export variables are not vulnerable to this issue, even if they process untrusted content and store it in (unexported) shell variables and open subshells.

Look to your vendors for patches to Bash and apply them as quickly as possible. A possible workaround is to use a different shell in some of these scenarios (CGI-BIN for example), which might be a quick and simple fix to implement.

Qualys has a detection for CVE-2014-6271 as QID 122693 – Bash Remote Code Execution vulnerability. Take a look at Prutha’s post for technical insight into the detection. And stay tuned for more details.