The new Shellshock vulnerability that affects the bash shell is one of the kind of vulnerabilities that makes old infosec guys chuckle. The bash vulnerability and its exploitation is not a marvel of complexity. We'll get into the specifics of how it works shortly. But first, let's address who's at risk.
In our business, we watch these sorts of vulnerabilities and follow-up exploit campaigns very carefully because they provide the criminals with a huge supply of a critical resource—hacked machines. These machines allow them to easily scale up attacks, host more malware, launch more phishing campaigns and run more malware C&C. The most obvious initial targets will be large hosting providers, which are riddled with bash-enabled administrative functions, as well as innumerable PHP-based forums, blogs, stores, etc. that will most likely contain some kind of bash-related vulnerability. The APWG has found that the majority of phishing attacks are launched from hacked servers, specifically related to mass-hacking of vulnerable systems.
To make matters worse, this bug resembles the recent Heartbleed in that people are aggressively scanning the entire internet for it with their massively parallel scanning tools. These tools can scan the entire ipv4 IP space really quickly and report back exactly who and what is vulnerable. In other words, the criminals are already capitalizing on this to build these networks of hacked machines (botnets).
The exploitation of this vulnerability relies on bash functionality somehow being accessible from the Internet. The problem with bash is that it’s used for everything. On a Linux-based system, bash is the default shell and anytime a web-enabled process needs to call a shell to process input, run a command (such as ping, or sed, or grep, etc.), it will call bash. This vulnerability allows a remote attacker to inject his command into bash via an environment variable. This command or commands can download a password file, run a remote shell, or really do anything that the attacker wants very very easily.
The Bash vulnerability isn’t one of these insane memory corruption vulnerabilities that requires bypassing DEP, ASLR, perfect alignment across multiple vulnerable versions or advanced memory leaking techniques. It’s a marvel of elegance and simplicity. It reminds me of the 90's when many exploits plagued setuid binaries with environment variable attacks.
This bug is not a remote “code execution” vulnerability—which means that some tricks are required to actually do something interesting. It’s a remote “command execution” vulnerability that may allow remote attackers to simply run commands on the remote system. No crashes, no complexity, easy to test, easy to exploit. On the CVSS scale it’s all 10s across the board. High impact, easy to exploit, no authentication required, low access complexity. Ouch.
Everyone should watch their logs carefully—this exploit is noisily and easily logged - and patch as soon as possible. In addition, given the risk that the patches may not be effective, organizations should consider monitoring to ensure their devices are not being used to host phishing or other attacks.