Shellshock: Keep Calm and Mitigate
#shellshock #nodejs #DevOps Yes, it is that bad. But don't panic.
Shellshock, appropriately and of course punnily named, is ravaging the Internet right now. Active exploits continue to grow in number and in complexity.
While there are multiple avenues through which this vulnerability can be exploited, the most active one at the moment appears to be via vulnerable Internet-facing systems running web applications.
These attacks take advantage of the lax constraints on HTTP headers that allow strings of nearly limitless length to be passed not just to the web server, but on to the system via CGI. Once passed, a 22 year old GNU Bash vulnerability allows the code embedded in the HTTP header to be executed.
That code can be just about anything. A quick GIS will net you hundreds of sites documenting actual attempts at exploits including complete shell scripts designed to download and execute other malicious content.
While the exploit mechanism is fairly simple, the results are not. If it's a command you can run in Bash, you can probably trick the system into executing it. "rm -rf" isn't beyond imagining. Neither is "shutdown -h now." It really depends on what the attacker wants to accomplish, and that could be anything. As Barrett Lyon said in his blog yesterday, "expect the Internet to be a little messy for the next few months."
The good news is that for at least web-borne attempts to mitigate attacks there are a variety of options already available. System patches will of course be flying fast and furious, but we (and that includes the bad guys) all know it takes time to obtain, certify and deploy those patches. In the meantime it's imperative to put a stop to the attacks and that means you need something fast. Like, right now.
This is the kind of situation for which programmability is exceedingly well suited. While the attack varies depending on what the attacker is trying to do, the exploit depends on the consistent presence of four characters at the beginning of an HTTP header: () {. Scripting solutions - whether iRules or node.js with LineRate - can detect this pattern in any HTTP header and then be dealt with accordingly (while you may feel like crafting a cocky HTTP response to the request and you certainly can when you've got a programmable data path, it's never a good idea to poke a badger, m'kay? I suggest just rejecting the connection, but that's me).
Web Application Firewalls (WAF) are also going to be a boon in mitigating this attack vector through web applications. The requirement for the string composition to begin consistently means it's a good candidate for a signature. WAFs like BIG-IP ASM that support custom signatures can be used immediately to block these attacks. Bonus: WAFs are already adept at recognizing attempts to evade detection such as encoding and escaping of characters, both of which will likely be used more and more frequently as organizations begin to block exploit attempts.
No matter how you decide to mitigate this one, MITIGATE IT NOW. Yes, caps were necessary, especially given the news this summer that two months after public disclosure there were still 300,000 servers vulnerable to Heartbleed. Heartbleed was bad, but Shellshock is badderest. Heartbleed was rated a CVSS v2 severity score of 5 and an impact of 2.9. Shellshock? A 10 on both counts. And I suspect that's only because the scale doesn't go to 11. Maybe it should.
F5 customers can track the status of F5 with respect to Shellshock as well as access both BIG-IP and LineRate mitigating solutions here.
Keep calm and mitigate.