Introduction
In the last post we saw how the recent bash vulnerability can be remotely exploited in a variety of ways.
How do we defend against this? Below we discuss steps that will help your organization identify vulnerable components and initiate mitigation activities.
Steps to identify, test and mitigate vulnerable systems
Make an inventory of all UNIX-like systems
When we say UNIX-like, we mean systems like FreeBSD, OpenBSD, Solaris, HP-UX, AIX, Linux and Mac OS X. All of these systems will have bash installed. Use your NMS system, your SIEM product, and your spreadsheets to identify these systems.
Prioritize Mitigation
As the attack is network-born as well as localized, prioritize Internet-exposed assets more than internal ones. Further, prioritize systems that have available patches from the vendors over those that need compilation of a patched source code. It is trivial to patch Linux systems like Red Hat, Ubuntu, Debian and Suse that are acting as Internet-exposed servers.
Detecting Vulnerable Versions of Bash and CGI scripts using Bash
Check your bash version
You can use the attack vector we showed in the last post if you are doing this manually:
Other automated options are:
- Our team member Sanoop Thomas has written an Nmap script to crawl websites that may be hosting CGI scripts and attempt exploitation, you can get the script here. Put it in /usr/share/nmap/scripts/. Usage instructions are as below
- Tenable Nessus has added “Shellshock” detection plugin*. To obtain the newest plugins, please run a plugin update from the Nessus User Interface before launching a scan. You should be able to see a new policy Wizard that looks like below after plugin update.
- Follow the steps in the following nessus forum post: https://discussions.nessus.org/thread/7914
- Netsparker Web Application Scanner has also detection module for the vulnerability. https://www.netsparker.com/blog/web-security/cve-2014-6271-shellshock-bash-vulnerability-scan/
- If you are savvy enough to penetration test Web applications you can use following BurpSuit plugin to test your CGI-scripts that are using Bash
- You could also use plain BurpSuite if you are only testing a few systems. You can see a workflow for this here: http://oleaass.com/shellshock-proof-of-concept-reverse-shell/
- Metasploit Project has added support for exploits that use the Bash bug through various vectors such as SSH, DHCP, Apache CGI Scripts, and local exploitation. See here.
- Another notable security researcher Rob Fuller has been curating a number of exploit vectors and advisory information on this page, which could also be used by technically savvy administrators
A point to note, before you run any of these various tools and tactics, be sure you have permission to do so from your management team. Not always the scanning tools will give you full coverage or even detect the issue, so testing manually is best.
Finding vulnerable CGI scripts
Included below is a simple “find” script that will check if your system has CGI scripts enabled that use bash as the interpreter.
You can use the following script to find if your website hosts any CGI scripts in locations unknown to you.
While I am writing this article I discovered a Perl-based CGI script I did not expect one of the operating system packages to have installed on my system. The Perl CGI script uses the system() call to execute the command line program. Fortunately, I had not enabled CGI feature in my apache configuration!
Network Inspection Detection with Snort
If you have intrusion detection systems and intrusion prevention systems on your perimeter you could look for the string ‘() {’ in your HTTP network protocol stream.
Here are rules made by Snort VRT
- Snort: http://blog.snort.org/2014/09/snort-community-ruleset-out-of-band.html
- Rules 31975-31978, 31985 cover this vulnerability from several different attack vectors
Similar rules are under circulation for users of Bro IDS and other commercial IPS solutions.
Detection with Mod_Security**
Red Hat advisory page has following detection rules for mod_security (a web application firewall for the Apache web server)
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:
SERVER_PROTOCOL values:
GET/POST names:
GET/POST values:
File names for uploads:
It is possible, however unlikely, that these rules may result in false positives. These false positives, along with actual attempts, could result in log files of significant size.
Network-level Mitigation using IPTables Linux Firewall
Red Hat has also provided possible mitigation using IPTables which can be used if your have a network firewall based on Linux.
It is possible to use IPTables string matching to attempt to drop packets that could be part of an attack, using:
Note that this is a weak workaround, as an attacker could easily send one or two characters per packet, which would avoid matching this signature check. It may, in conjunction with logging, provide an overview of automated attempts at exploiting this vulnerability.
Patching and Testing
On RedHat/Fedora/CentOS run:
On Debian/Ubuntu based systems:
Checkpoint has released bash patches for their firewall and IPS appliances: https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk102673
If you can not patch your systems using vendor provided Bash releases, option is to compile and install a patched version of bash from GNU. Please see below instructions for the same.
The patches for GNU Bash are available here:
http://ftp.gnu.org/pub/gnu/bash/bash-4.3-patches/
Refer to the following manual for how to compile bash from source
https://www.gnu.org/software/bash/manual/html_node/Installing-Bash.html#Installing-Bash
The basic series of steps are as below (verify the actual patch file that it applies to your release of bash):
Once your have successfully compiled and installed the new bash in /usr/local/bin. You can try the vector given above and it should fail to print the word “Vulnerable”. If the test completes, you can remove the “–prefix=/usr/local”, recompile and “make install” in /usr, overwriting the old install.
Please note your will need development tools such as gpg, autoconf, make and gcc installed on the system before attempting this!
For Mac OS X, if you use Macports software distributions, your can run:
Apple has release an update for OS X Maveriks also which would be easy to apply:
http://support.apple.com/kb/dl1769
Suse Linux has also released patches for their products; please see the FAQ here for more information.
Updated CVE Information for the Bash bugs
The original vulnerability was given the CVE identifier CVE-2014-6271. The first patch release from GNU Bash team was the one noted above “bash43-025” which is now superceeded by the latest patch level of “bash43-30” on the GNU FTP site which has been announced about 12 hours ago.
After the initial issue was made public, security researchers warned that the fix was incomplete (Tavis Ormandy) and may lead to other vulnerabilities, CVE-2014-7169 was assigned to issues arising out of the initial patch release. Further, CVE-2014-6277 and CVE-2014-6278 were also assigned to vulnerabilities that arose out of both CVE-2014-6271 and CVE-2014-7169 after manipulation of input to bash using a fuzzer (see blog post by Michal Zalweski). Further, Red Hat Product Security researcher Florian Weimer found additional problems and they were assigned CVE-2014-7186 (Denial of Service due to redirection implementation in parse.y in GNU Bash through 4.3/bash43-026) and CVE-2014-7187 (Off-by-one error in the read_token_word function in parse.y in GNU Bash through 4.3/bash43-026).
Thus, to summarize use latest updates provided by your provider or if you must patch your source codes use bash43-30 released recently!
* http://www.tenable.com/blog/tenable-issues-shellshock-detection-plugins-updated
** https://access.redhat.com/articles/1212303
