Mitigating the Remote Code Execution in Bash

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

 

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

bash version

You can use the attack vector we showed in the last post if you are doing this manually:

attack vector

Other automated options are:

  1. 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 belowautomated options
  2. 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.Detecting Vulnerable Versions of Bash and CGI scripts using Bash
  3. Follow the steps in the following nessus forum post: https://discussions.nessus.org/thread/7914
  4. 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/
  5. 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
    1. https://pro.portswigger.net/bappstore/ShowBappDetails.aspx?uuid=3123d5b5f25c4128894d97ea1acc4976
  6. 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/
  7. 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.
  8. 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.

Linux

You can use the following script to find if your website hosts any CGI scripts in locations unknown to you.

Linux2

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

  1. Snort: http://blog.snort.org/2014/09/snort-community-ruleset-out-of-band.html
  2. 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:SecRule Request Headers

SERVER_PROTOCOL values:

SecRule Request Line

GET/POST names:

SecRule Args Names

GET/POST values:

SecRule Args

File names for uploads:

SecRule File Names

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:

iptables

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:

Linux Prompt

On Debian/Ubuntu based systems:

Linux Prompt2

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):

Basic Series

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:

Macports software distributions

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

 

Author


Leave a Reply

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

For security, use of Google's reCAPTCHA service is required which is subject to the Google Privacy Policy and Terms of Use.

I agree to these terms.