BASH Shellshock vulnerability – Update5

Wolfgang Kandek

Last updated on: September 6, 2020

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:

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.

Show Comments (22)

Comments

Your email address will not be published. Required fields are marked *

  1. As with Heart Bleed, if authenticated scanning is being done, the applications tab is quite useful for checking if Bash is installed along with its version.  Just another way to help stomp out CVE-2014-6271 fires. 

    The latest I’ve heard is that QID 122693 should show up very soon in all knowledge bases.  Likely with the release of VULNSIGS-2.2.830-x  if all goes smoothly.  (mere hours away)

  2. This could just be my ignorance but I’m somewhat surprised to see that the two existing QIDs for this — 122692 and 122693 — both require authentication to detect the vulnerability…  Isn’t one of the chief dangers of this security hole that it requires no authentication for remote execution, such as over SSH, and thus shouldn’t an unauthenticated scan find this vulnerability as well?

    Thoughts?

    Thanks.

    Bob

  3. A remote detection that does not require authentication has been developed and will be released to scanners tonight.  This will be covered in QID 13038.  This will be contained in Vulnerability Signature Version 2.2.831.

  4. It is my understanding that the non-authenticated QID 13038 will only flag the vulnerability if it is exploitable through the web attack vector through CGI. Any plans to expand this to other attack vectors like DHCP, icmp etc?

  5. My scan report is showing some results for 122693 but not 122698. Can I assume that we must apply the fix for both 122693 and 122698 separately, rather than the remediation for 122698 being cumulative for both QIDs? Thanks

  6. False, wrong, hoax, the bug is not affecting everyone on the web, but just those having specific websites using (insecure) cgi-bin.

    Why are people so crazy about it, I don’t know. For myself, I won’t update bash. I don’t see the necessity. Heartbleed was indeed a bigger big deal.

    1. Audio Scavenger,

      the update urgency for the bug depends very much the use that your are making of your machine that has Bash installed. I agree with you that the most urgent instance is the use of the (very) old technology CGI-BIN. I don’t believe that any modern websites are affected, but we know already that there are webservers on the Internet that are configured (even on the homepage) to handle page requests through CGI-BIN. These machines are probably already part of a botnet by now, since it was so easy to find them (our check 13038 does that for example).

      The same thinking applies for all other attack vectors:

      • DHCP: if your Linux/Unix machine runs on a fixed IP address this is not a problem. If your are using DHCP and you are sure nobody else can run a DHCP server in your network (Cisco DHCP Snooping or similar) and your machine does not leave that network you are covered as well. BTW, rogue DHCP servers are a threat even without Shellshock. PS: Not all Linux/Unix versions are exploitable, so your exposure may vary as well, in particular Mac OS X is not exploitable.
      • QMAIL: machines that receive email using QMAIL are exploitable with an attack that is easily embedded in an e-mail, if they are configured in a certain way (with a .qmail file that forwards messages) – not sure how common that is.

      There are pages dedicated to document the new ways that attackers could use the vulnerability, for example Shell Shock Exploitation Vectors – Tech Updates. Isn’t it easier to update Bash to avoid the whole analysis process?