Based on what I'm seeing as I write this, the Shellshock Bash vulnerability could be the huge security concern that Heartbleed wasn’t. Several of my servers located in different geographic areas and on different providers have already been experiencing exploit attempts. The big deal? This vulnerability is way too easy to exploit.
The basics are that a 22-year-old bug in Bash has been discovered that causes the shell to execute code delivered after an anonymous function call is made. Combine it with the fact this can occur while the shell is evaluating environment variables and it gets hairy.
A very brief example: If you can structure an HTTP header in such a way as to include a variable as simple as a user agent string that contains the proper syntax, then pass that request to a Web server that either calls Bash as a CGI script, or — this is the very important bit — in PHP, Java, Python, or other language that issues a system() or popen() call and passes those variables to Bash, you can compromise the system. It is vitally important to note that this only affects code running as a CGI; it doesn't affect PHP code running with mod_php, for example. It is recommended that you fully test code in any language that calls Bash through system calls.
Again, in order to exploit this vulnerability we need the following:
- A Web server that is running code that eventually calls Bash and passes environment variables along.
- Someone finding and requesting that page or script while injecting a malicious header.
That’s not a very long list.
What can an attacker do with this vulnerability? They can issue commands as the user running the Web server process. This doesn’t mean they have root access, but they can issue a set of commands — not detailed here — that could cause an interactive shell to be created through the use of commonly available *nix tools likely present on the Web server. They can also cause files to be uploaded to other servers or anything you might be able to do as a nonprivileged user with shell access to that server. It’s not an immediate rooting, but it’s a very uncomfortable situation.
If there are servers running Bash scripts as CGIs, that could only be considered a horrible security practice anyway, but those are immediately vulnerable. Code that does not make system() or popen() calls is not likely to be vulnerable, nor are those that only make those calls during authenticated operations, or do not expose scripts with those calls to anonymous access. Furthermore, as stated, these calls must pass along environment variables for the bug to surface.
This still leaves a huge potential for exploit, and we’re already seeing evidence in the wild. The fact is, a one-line curl command can be used to exploit this vulnerability -- no sniffing or coding required. In addition, this vulnerability can be used to exploit *nix DHCP clients by passing malicious strings that are included into environment variables by Bash processing on the client side, and SUID vulnerabilities for applications that may be able to assume greater root access via this method. Those are all generally local exploits, however -- not remote.
The exploit attempts I see on my servers are using the user agent string, which of course puts the exploit attempt right there in the logs. These appear to be CPanel exploits, and if so, a whole massive amount of VPS and hosted servers are going to have a bad time in short order. A large number of those systems run CPanel to provide a GUI front end to Linux server management. I would guess that most of these exploits will be aimed at botnets, and the ones seen in my access logs appear to be only attempting to ping a specific IP address, presumably to collect a list of vulnerable systems while the attackers are busy coding the actual exploit. Time will tell on that score.
Then there are all the fixed/embedded systems, such as firewall appliances and routers, and all manner of other systems that may or may not be running Bash, and may or may not make Bash calls via their Web UI. I would assume that a number of devices out there call out to the shell to run various small diagnostic commands, but hopefully those are behind some form of authentication, or they're running ash, or sh and not Bash.
I have a feeling we'll find out about a whole host of systems calling Bash in one way or another, and they'll need to be patched or taken offline. Once discovered, it’s a situation of when, not if, they are compromised.
As for now, all we can do is patch. Red Hat, Ubuntu, and other Linux distributions, along with the various BSDs have begun rolling out patches that go at least part way to eliminating the vulnerability, although it appears that the initial wave of patches made public by the Bash maintainers may not go far enough. We'll likely see another round of patches come through in the next few days.