Last week the information security world was rocked yet again by a major vulnerability in a little known piece of software that could have severe ramifications on the security of large swathes of the internet.
The so-called ‘Shellshock’ bug shares more than a few similarities with the infamous Heartbleed flaw, which rattled the net back in April this year. Some experts say it could be even worse, while others caution that the exploit paths are too complex to make sweeping judgements about it quite yet.
So how scared should we be?
Back to Bash-ics
The Shellshock vulnerability itself, CVE-2014-6271, was discovered by an Akamai researcher, Stephane Chazelas. It will allow an attacker who tries to pass commands to an extensively used shell called Bash (the Bourne Again Shell) to execute arbitrary code. The US national Vulnerability Database has given it the highest severity rating - 10/10 – claiming that it does not require authentication to exploit and allows unauthorized disclosure of information, unauthorized modification, and disruption of service.
For those still bemused, the reason this particular vulnerability could be so dangerous is because of the ubiquity of Bash. A huge number of web-connected devices, web servers and web services run on Linux versions running it. In particular, hugely popular Apache web servers running CGI scripts are at risk, as are even “email clients and web clients that pass files to external programs for display such as a video file or a sound file,” according to Jim Reavis of the Cloud Security Alliance. What’s more, the bug has been around for 25 years so there could be large numbers of unknown and unpatched systems which could yet disrupt corporate security strategies.
Time to Get Patching
Many will be asking exactly why it has taken a quarter of a century to unearth such a potentially damaging vulnerability. The “sad” truth, according to Damballa senior security consultant Simon Edwards, is that “nobody had 'lifted that particular stone' before.”
“Remember that this is not exploitable on its own,” he told Infosecurity.
“Bash needs to be sent data from another process for it to work. So where researchers may have looked at bash before, they may not have looked at it in combination with the other processes before."
The advice of the CSA’s Reavis is as follows:
To test if your system is vulnerable just try this on bash:
env x='() { :;}; echo vulnerable’ bash -c “echo this is a test”
If you’re vulnerable it’ll print:
Vulnerable
this is a test
If you’ve updated Bash you’ll only see
this is a test
SSH inventor Tatu Ylönen argued that the best way to fix any problems is to upgrade Bash.
“An immediate workaround is to use the AcceptEnv command option in /etc/sshd_config to reject any environment variables from the client (typically just delete the AcceptEnv line from the default configuration file),” he added.
The US national Vulnerability Database has given it the highest severity rating - 10/10
“The biggest risk is with older websites that run CGI-scripts using Bash. I don't think most modern or major sites are affected, but there could still be millions of sites in the world that are. I would strongly recommend anyone running a website to upgrade Bash to the latest version, just in case.”
Worse than Heartbleed?
The question remains, though, is Shellshock worse than the infamous Heartbleed vulnerability? Well, the smart money seems to be on ‘yes’ and ‘no.’ On the one hand it looks pretty bad.
“The Bash flaw, if successfully exploited, can cause remote code execution or denial of service. This Remote Code Execution, that relates to how environment variables are processed, allows trailing code in function definitions to be executed, independent of the variable name,” explained Bitdefender e-threat specialist Bogdan Botezatu.
“Where there is a script on the system that relies on environment variables, the flaw allows unauthorized disclosure of information, unauthorized modifications and, perhaps most importantly, the disruption of service.”
However, on the other hand, it can more accurately be described as a “mini Heartbleed” because exploitation is only possible in certain scenarios on Linux and UNIX systems.
“To start with, remote hackers can only target servers running CGI scripts and pass environment variables whereas, in Heartbleed’s case, they interacted more easily with the server. Network-based exploitation is also possible, but it is limited to specific scenarios,” he added.
Rapid7 has posted one of the most comprehensive discussions of the potential threats emanating from Shellshock.
It said that with the Bash flaw “some factors are worse [than Heartbleed] but the overall picture is less dire.” This is because any attack must revolve around Bash itself, and not a particular application, making the paths to exploitation “complex and varied”. Thus, each affected application might be exploitable through a slightly different vector, “or have different requirements to reach the vulnerable code.”
Attackers usually hate this scenario as their business plan mandates that they get maximum return on their investment in developing an attack campaign by targeting large swathes of users in a single blow.
Kevin Westin, security analyst at Tripwire, argued that Heartbleed was the first example of undiscovered software bugs having a huge impact on internet security.
Some factors are worse [than Heartbleed] but the overall picture is less dire
“The security industry knew that this was only one example and that there would be more to follow, Bashbug is such an example and one that is even more significant given the wide usage of the software in question,” he told Infosecurity.
“Organizations need to be aware that there will be more significant vulnerabilities like this and their security strategy should reflect this, with multiple layers and contingency plans for how to handle vulnerabilities such as this when they are exposed.”
Fixes and Fightbacks
The good news is that some of the major Linux distributions such as Debian, Fedora, Ubuntu, CentOS and Red Hat have already patched the Shellshock vulnerability. Elsewhere, Akamai said its internal “control systems have been or are being urgently patched or otherwise mitigated in prioritized order of criticality.” Reflecting the complexity of the related threat landscape, it admitted that a patch it posted “did not completely address the vulnerability.”
Unfortunately it’s only a matter of time before the cybercriminal underground starts firing attack campaigns exploiting the vulnerability. Already, security researcher Yinette claims to have discovered a DDoS botnet exploiting shellshock. Meanwhile, researcher Robert Graham found at least 3,000 vulnerable systems on port 80 alone, “just on the root "/" URL, without Host field” – although that was an incomplete scan.
“Someone is using masscan to deliver malware,” he said in an update on Thursday. “They'll likely have compromised most of the system I've found by tomorrow morning. If they’re using different URLs and fix the Host field, they'll get tons more.”
Ronnie Tozakowski, senior researcher at PhishMe, warned that the security implications of Shellshock could be massive.
“With the number of internet facing devices vulnerable to this, it would be very easy for an attacker to turn this into a worm, and bore itself past external gateways into homes,” he told Infosecurity.
“When was the last time you patched your TV? And with the current scan of the entire internet going on, an attacker could easily turn this into a fork bomb, hogging CPU resources, and crashing systems around the globe. But how can you help fix this?”
Kevin Epstein, vice president of information, security and governance at Proofpoint, argued that organizations should adopt a ‘patch first’ policy.
“While clearly internet-exposed servers running applications that could allow attackers to make use of the vulnerability – such as Apache, run by around 50% of internet servers – are the first priority to patch, there's little sense in leaving any unpatched in the long run,” he told Infosecurity.
“It's impossible to predict which apps and which machines may be exposed to attackers going forward, so better safe than sorry.”
Damballa’s Edwards agreed.
"Patching always has to be the way forward for a vulnerability like this: to know that you have closed the barn door,” he told Infosecurity by email.
“Ordinarily other IDS-like technologies could be crafted to look for a pattern, but given that this may come from within the server itself (i.e. the CGI script on a web server) any network intrusion detection maybe irrelevant."
PhishMe’s Tozakowski added that IT leaders should reinforce to their sysadmins the severity of the bug.
“Even though many product and system vendors have yet to release a patch, an organization can still do the foot work needed to understand which systems will require a maintenance window,” he added.
“Have IT staff inventory and rank systems that may be vulnerable to accepting BASH parameters from untrusted sources and prioritize the patch schedule based on which of those systems have the greatest exposure.”
It’s still early days, of course, and we’re likely to know a lot more about the potential impact of Shellshock in the days and weeks to come. The only thing we can say with any certainty is that, just like Heartbleed, this incident will quickly go down in history as an era-defining moment in the information security industry.
For more information on Shellshock, register for our free webinar on Shellshock:
https://www.infosecurity-magazine.com/webinars/shellshock-webinar/