Somehow there always seems to be another Internet security disaster around the corner. A few months ago everyone was in a panic about Heartbleed.
Now the bug, Shellshock (officially CVE-2014-6271), a far more serious vulnerability, is running uncontrolled over the Internet. It’s never a good time to panic, but if you’re discouraged I don’t blame you; I know I am.
In retrospect, the grave concern over Heartbleed seems misplaced. As information disclosure bugs go it was a really bad one, but it was only an information disclosure bug and a difficult one to exploit. The sky’s the limit on attacks with Shellshock and it’s so easy to exploit that it’s already being widely-exploited according to research firm Fireeye, which says they have already observed several forms of attack:
• Malware droppers
• Reverse shells and backdoors
• Data exfiltration
• DDoS
Of course it’s not just Fireeye; everyone is reporting widespread sightings of exploits. SeeKaspersky, Trend Micro, HP Security Research and many others.
Speaking of HP, their TippingPoint unit states that their network IPS has been updated to recognize known attacks using Shellshock. A vigorously updated IPS, deployed not just at the perimeter but also at critical points within the network, may be the only effective systemic protection you have against Shellshock for now. HP is not the only IPS around of course. And remember that an IPS is more of a protection against known exploits than against the vulnerability generally.
This particular bug has been in the Bash shell for over two decades. The implications of this are really bad. First, it means that an extremely important and popular program either went unscrutinized or poorly-scrutinized. Surely there are many other such problems out there. Don’t be surprised if several of them have been used carefully and surreptitiously for targeted attacks for years. In fact, don’t be surprised if Shellshock has been used in the past.
All sorts of horrible scenarios are possible with Shellshock. It’s not just limited to web server attacks. Fireeye shows how different Internet services, even DHCP and SSH, can be exploited to perform the attack, as long as Bash is the shell, and it usually is. They demonstrate automated click fraud, stealing the host password file, several DDOS attacks using the server and several ways to establish a shell on the server without any malware running on it.
Another nasty aspect of this bug is that so many *NIX servers are out of sight/out of mind. There is (usually) no automatic update process that runs periodically. This was true of Heartbleed as well, but OpenSSL has nowhere near the ubiquity of Bash, and even where OpenSSL is present it doesn’t necessarily work with critical information..
The open source software community also inspires little confidence with the way the initial updates proved inadequate. The release of the initial Shellshock bug was withheld until a patch was available, but it wasn’t long before further research showed that additional related vulnerabilities exist and that they needed patches as well. (Current Bash versions address all known vulnerabilities — and, tautologically, none of the unknown ones).
Of course, reactive patching like this is a loser’s game. As Heartbleed and many earlier vulnerability crises have shown, a proactive auditing policy and procedure is required if you want to be prepared for cases like these. Proper implementation of such a policy would give you a current and precise inventory of software on your network. You really want to have this, because attackers who have penetrated your network probably have one too. You need to react at least as quickly as they do.
This is hard work and the sort of best practice with which everyone agrees, but for which few have time. And even it is largely just a better way to be reactive, although it does have the added advantage of helping to find unauthorized software on the network. The less you know about what software you are running and where, the longer it will take for you to deal with crises like Shellshock. And more will come. And if your slow reaction leads to damages to customers or third parties they can justifiably say that you didn’t do everything you could to protect your systems.
source: Larry Seltzer/zdnet
Discover more from TechBooky
Subscribe to get the latest posts sent to your email.