BASH Shellshock vulnerability – Update5
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.
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
- 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:22.214.171.124
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.
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)
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?
For guidance on leveraging existing QualysGuard scan data to identify hosts affected by this vulnerability, please see Shellshock – QualysGuard Reporting How-To
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.
Do you know what time tonight these will be released to the scanners? Before 10pm Eastern standard time?
I see it was pushed but do you know if it was before 10pm EST?
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?
Please note that QualysGuard PCI Scans also include the new detections. Please check the 'Vulnerability Signatures' version in your PCI Scan Results 'Report Summary' section for confirmation.
You may check your servers against this vulnerability here. BASH SHELLSHOCK VULNERABILITY CHECKER
Any ETA with WAS remote scans check?
An official post on this topic will be coming in the next day or two.
Signature file was updated to 2.2.831-5 to 2.2.831-6, What was fixed, do we need to re-scan again with the new Signature file update?
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
Are these QIDs are updated with solaris OS ? Or there are any other QID for solaris ? Currently the solaris hosts are not being detected by Qualys though Oracle has already released patches.
Oracle Security Alert CVE-2014-7169
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.
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:
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?
What about new CVE’s which have been disclosed CVE-2014-6277 and CVE-2014-6278?