Facebook Google Plus Twitter LinkedIn YouTube RSS Menu Search Resource - BlogResource - WebinarResource - ReportResource - Eventicons_066 icons_067icons_068icons_069icons_070

Detecting Shellshock with LCE Process Accounting

A critical vulnerability in bash (Bourne Again SHell) versions through 4.3, the default shell for many Linux and other Unix distributions (including Mac OS X), presents a critical security concern for network-attached devices that use bash, especially those with an attack vector that can be exploited remotely (e.g., web servers, SSH servers, and likely much more). The key focus is that the attacker has to have a remote interface that will call bash to exploit the vulnerability. The bigger concern is that in the Unix world, that includes a lot of services. While Windows-based systems do not include bash by default, they may have an add-on bash (Cygwin, win-bash) program that can possibly be exploited. Remember, the vulnerability is in the underlying shell, so it may be on any operating system that can run the shell.

Tenable strongly recommends that you use multiple methods to verify the existence of vulnerabilities

CVE-2014-6271, which is commonly being referred to as “Shellshock”, allows a variety of remote attacks, mainly through Linux web servers that run CGI scripts. However, popular services such as Secure Shell (SSH) and even internal network protocols that run on Unix-based systems, such as DHCP servers, may be vulnerable. Shellshock also allows a variety of privilege escalation attacks where a non-administrator Unix user could cause commands to be run as root.

On any implementation of bash, the following test will check to see if your implementation is vulnerable to CVE-2014-6271:

Input:

bash$ env x='() { :;}; echo vulnerable' bash -c 'echo hello'

Output if vulnerable:

vulnerable
hello

Output if not vulnerable:

bash: warning: x: ignoring function definition attempt
bash: error importing function definition for 'x'
hello

Tenable’s SecurityCenter CV Log Correlation Engine sensor can be used to identify the exploitation of the bash vulnerability using process accounting. The following steps provide an example demonstrating how this can be accomplished:

  • Enable process accounting on a host with an LCE Client
  • Install an Apache server with a vulnerable CGI script
  • Exploit the vulnerability
  • Detect the exploit with LCE

To demonstrate this, the LCE Client was installed and started on an Apache server with process accounting enabled. Next, a vulnerable CGI script was installed on the Apache server called bad.cgi and the host was exploited using the User-Agent header as follows:

curl -k -H 'User-Agent: () { :;}; /bin/ping -c1 192.168.111.168' http://192.168.111.131/cgi-bin/bad.cgi

In another window, tcpdump was run to monitor for the ping request, showing that the exploit was a success:

Lap25811:~ rich$ tcpdump -lni en1 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on en1, link-type EN10MB (Ethernet), capture size 65535 bytes
10:38:05.918149 IP 192.168.111.131 > 192.168.111.168: ICMP echo request, id 64774, seq 1, length 64

So let’s see what was reported by LCE:

There are two events of interest listed here to consider: the “Linux-Segfault_Detected” and “Linux-User_Issued_Command_With_ParentID”.

In this example, the httpd daemon is running as the “apache” user. Under normal conditions, you should not see this user executing system commands.

If multiple different commands are attempted, you would likely also see the New_Command or Unique_Unix_Executable events. Please note that the initial set of patches provided by the author of bash was found to be trivially bypassed. Utilizing defense-in-depth to protect against attacks is a must. CVE-2014-6271 carries a CVSSv2 score of 10, and there are reports that it is already being exploited in the wild. This is not a hypothetical vulnerability or attack vector.

As with all security solutions, Tenable strongly recommends that you use multiple methods to verify the existence of vulnerabilities. While Nessus can remotely verify the presence of this vulnerability if a service calls the vulnerable version of bash, it relies on such a service for detection. Using LCE, you have another tool that can find vulnerable versions of bash through different methods.