Detecting ShellShock Using PacketSled

Knock Knock. Bash Bash.  The scope and scale of the bash attack is fairly well known even though its only been public for 24 hours, but in case you’ve missed out on it somehow, here’s a quick recap of the CVE summary that will provide some context:

GNU Bash through 4.3 processes trailing strings after function definitions in the values of environment variables, which allows remote attackers to execute arbitrary code via a crafted environment, as demonstrated by vectors involving the ForceCommand feature in OpenSSH sshd, the mod_cgi and mod_cgid modules in the Apache HTTP Server, scripts executed by unspecified DHCP clients, and other situations in which setting the environment occurs across a privilege boundary from Bash execution.

Most of the early exploit activity has leveraged CGI to exploit shell commands. Exploit POCs for other protocols will follow for sure, and we’ll be posting about detections for those in real-time. For the time being, we can make one broad assertion, which is that the payload of the attack will exist in a relatively obvious place, as it did with the HTTP proof that’s out. In order to properly detect and investigate sessions that leverage this vulnerability in your environment, the first step is to isolate the various attributes and their values (HTTP headers in this example). The good news –  If you already have PacketSled, you have all of this data preloaded, not only for HTTP, but for telnet, DHCP, and 2000 other protocols. As Troy Hunt mentioned in his post today, there will likely be additional iterations of the vulnerability. Automatic detection of ShellShock atttempts on a running system: PacketSled behavioral detections were updated for all customers today with a level 10 alert that will fire for ShellShock exploit attempts. The severity of this attack will likely go down over time, as systems become immune or at least improve their resistance to the problem. If you see this detection on your dashboard, then the good news is that you already have the detection built in, and any incidents that have been identified are made available for investigation simply by clicking them. If you do not see this security incident, and want to manually identify any sessions that may be exhibiting shellshock behavior, you can also use the natural language search engine in investigator to look through all of your network traffic, with one easy query. For instance:

today http user_agent like /\(\)\s{\s.*;/

  This same query can be run against any attribute in an http flow. Other common places to look include:

• The User-Agent HTTP header (user_agent)
• Cookie (cookie)
• Host (server)
• Referrer (referrer)

  Finding your highest risk hosts: Now that we’ve identified attempts to exploit this vulnerability, the next logical step is to determine how many hosts we have that are actively executing code out of /cgi-bin. Simply use the investigator to search through all the web transactions that happened in your production environment:

today 10.1.1.0/24 http user_agent like /\(\)\s{\s.*;/ uri like /cgi-bin 

This search will identify hosts with active applications that run out of cgi-bin, who are currently targets of the attack. Total elapsed time: 30 seconds.