So this vulnerability occurs with the Bash shell that's present in Linux systems, Unix systems, and Mac OS X. Bash is the default shell used for Linux and Mac OS X. It's a command language interpreter for those systems.Anytime you've used the command line interface or a terminal, you've probably been using Bash. It's been around for about 20 years, so years, 25 years, and the vulnerable version in this case goes back that far. It's vulnerable up to version 4.3, and it's just been disclosed as of this week, as of yesterday or so.
The issue arises, the vulnerability arises because Bash is not checking for trailing strings in function definitions for environment variables to ensure it's not parsing those strings as Bash commands. It should be parsing them as regular text or rejecting them if it's erroneous. An example of this kind of exploit is here where you have a function definition for this environment variable, but then we have this trailing text echo ShellShocked. This gets executed as an echo command in Bash, and it shouldn't be happening that way. Other commands, ping, ifconfig, different administrative functions you can carry out with Bash could also be executed using this vulnerability. The different attack vectors that are known so far can happen over protocols like H.T.T.P., S.S.H., and D.H.C.P. The issue can happen with authentication or without authentication, and the fact that it can happen without authentication, especially with Internet-facing systems, is of the most concern right now.
So let's look at this H.T.T.P. attack vector, one that can occur without authentication depending on how your web application is configured. H.T.T.P. with C.G.I. pages is really the main issue. If an attacker sends a malicious H.T.T.P. request to a web server with a C.G.I. page and that request contains a payload such as this, it can be parsed and interpreted by Bash on the underlying system and executed accordingly. Without authentication, this can create a huge problem. Innocuous things like echo are not really big deal. We're talking about stuff like reconfiguring the server, spreading malware, attacking other systems using a vulnerable one. It can be very impactful. Other attack vectors, such as over S.S.H., generally require authentication, so it's not as big of a problem, but still, you know, this shouldn't be happening. Bash is processing things in sort of an unrestricted way with these trailing strings as after function definitions. Also, D.H.C.P. is another potential attack vector that needs to be focused on.
There's currently a debate right now as to whether or not ShellShock is as bad as Heartbleed, and that's still being sorted out. We really don't know for sure if it's better or worse. In some cases, it looks like it's worse. In other cases, it looks like it's not as bad. Better is really the wrong word to use that I just mentioned before. But basically we don't have evidence to rule out the possibility that it's not as bad as Heartbleed yet. Once we get that evidence, we can start talking about that, but for now, it's up in the air, and really what we need to focus on is how do we address the issue. How do we remediate the issue?
The first thing that pops into everyone's head is patching, and really that is what you should be focusing on starting out. Different Linux distros have different patches. Red Hat has released patches. Debian has released patches. A caveat to know for the Red Hat patch is that the first patch they've released doesn't completely remediate the issue. Please keep an eye out for future patches from Red Hat because it didn't completely remediate the issue. There's another C.V.E. I.D. that's been assigned to the vulnerability that's left over.
Aside from patching your systems, there are other shells, other than Bash that can be used. These shells have been tested but, you know, only limited testing so far. It's only been a day or so, but it's worth trying because they haven't been shown to be vulnerable yet, and it's somewhat unlikely that they're going to be vulnerable in the same way, if at all.
Finally, there's some partial mitigation techniques you can use. For example, with an H.T.T.P. server, you can try using ModSecurity, which will reject H.T.T.P. requests that have Bash-like commands in them, malformed requests, it will drop them. There are some detective means and detective measures you can use if you have an H.T.T.P. server that's logging things verbosely. You can check past logs or current logs to see if there were requests that were coming in that had malicious payloads with Bash commands.
Otherwise, for Rapid7 products, we've been looking into it. Things like Nexpose, Metasploit, we haven't found them to be vulnerable according to these or in line with these attack vectors we've gone over. They're clean. They're still good to use. We're still working on it and ruling out all other possible attack vectors, so you can check for updates from us at rapid7.com/bashbug, and you can also use our different products to try to detect this vulnerability. Nexpose and Metasploit modules will be updated sometime today as of this recording, sometime later in the afternoon. UserInsight can detect odd or unusual user activity that could be a sign of this exploit occurring on your systems and on your network.
Otherwise, that's it for today. We'll see you next week.
