Bash vulnerability views
‘Bash’ or ‘Shellshock’, a major new security vulnerability that could have greater impacts than Heartbleed, has been uncovered. In this article Continuity Central summarises the views of a number of information security professionals concerning this vulnerability.
Toyin Adelakun, VP of Products at Sestus:
A command interpreter allows users to interact with the operating system, for the purposes of issuing low-level instructions and manipulating data.
Direct access to data and instructions potentially offers a means for attackers (malevolent users) to circumvent the protections built into a legitimate app in respect of the app’s data.
Therefore, the fact that many apps use Bash to invoke other apps or operating-system commands makes this vulnerability particularly potent.
Bash is a powerful shell, and its support for ‘here documents’, for example, means that this vulnerability could, if exploited, allow attackers to run arbitrary code on the compromised computer.
Bash has been popular for most of its 25-year existence, and its persistence and ubiquity add up to a pervasiveness that raises both the likelihood and the impact of risks associated with this vulnerability.
The risks are of attackers executing arbitrary code on Unix systems, or illicitly modifying, adding or deleting data on such systems. To mitigate those risks, the urgent advice is to immediately patch or update the Bash software. That applies both to servers as well as clients (i.e. individuals’ systems) such as Apple MacBooks and Mac Pro desktop computers. Because they affect both client and server computers, and because they could lead to data leakage directly from computers, these risks do indeed potentially surpass those of the Heartbleed bug.
‘Bash’ or ‘Bourne again shell’ was written in part-homage to Steve Bourne, a British computer scientist and Unix pioneer. There are other shells on Unix platforms — such as the C shell (csh), the original Bourne shell (sh) and the Korn shell (ksh). At this time, there is no definitive indication that other shells have this vulnerability.
Mark James, security expert at ESET:
At the early stages of this vulnerability it’s not quite certain how much of an impact it will have on systems. What we can expect though is the community going through their servers and checking to see if they are affected, the test is very simple and done from a command line.
The problem we have is that this bug has been around for a very long time, we also are not really sure how many systems it actually affects. We do know however it is more than the Heartbleed bug as unlike specific versions of OpenSSL that were affected with Heartbleed, this particular issue affects a much wider platform of almost all Linux, Unix and MAC Oss, and pretty much any OS that uses the GNU Bourne Again Shell (Bash).
The concern is that Apache, which is used in more than 50 percent of web servers will use Bash to execute scripts for dynamic content and thus could be compromised to launch code on your server. An unpatched system could leave your server wide open and vulnerable to attack.
What should you do now? Firstly run a command line test, then patch your systems. Check for any updates then check again, run the script and ensure you get the warnings. If you still don’t, then you should update Bash to the latest version manually. Also please keep an eye on network traffic, take this opportunity to tighten control on any non-essential services and turn them off.
To see if you are affected, the test is very simple and done from a command line:
A patched or unaffected system will output:
Trevor Dearing, EMEA marketing director Gigamon:
Discoveries like this show just how sophisticated security threats are becoming – and organizations must adapt their security architectures accordingly. We are seeing breach after breach dominating the media, and this shows no sign of slowing as more big brands learn the hard way that the current defence model is broken, outdated and in need of a change.
It is no longer enough to deploy the latest, next generation security tools and let this lead to complacency. Instead, the way in which these security solutions are deployed onto a network is becoming as important as the tools themselves. As networks become more complicated and dispersed than ever before, traditional security tools are struggling to capture all of the activity in a timely fashion – if at all – and this leads to blind spots, which are a critical loss when securing against advanced threats such as Shellshock. After all, how can you defend against that which you cannot see?
In order to address these issues, organizations need to take a step back from front line security defences and examine their underlying network infrastructure. Pervasive visibility tools must first be in place to aggregate and filter all traffic – in-band, out of band, packet level, flow based, etc. – no matter where it originates on the network. This is the only way to ensure that security tools are getting the complete picture of all network activity, and can therefore do a more effective job of protecting the network and the critical data that it holds when threats such as this arise. Shellshock is not the first major security scare to hit the headlines, nor will it be the last, so organizations must take the right measures now to avoid becoming the next high-profile victim. After all, when it comes to detecting security threats, it’s become a case of everywhere, not where.
Steve McGregory, director of application and threat intelligence, Ixia:
Initial estimates that 500 million machines are at risk from Shellshock represent just a small percentage of systems that are actually vulnerable to this latest threat. Shellshock is one of the most basic remotely exploited bugs and can be achieved by anyone with an understanding of computer programming.
The crux of the Shellshock is that it is exploited through some of the oldest internet technologies around. The Bourne Again Shell (Bash) has been around for 25 years. The oldest web server technology, still utilised by many devices today, CGI scripts, utilise the Bash shell when processing a web page. Old web servers, and especially less powerful systems like home Internet routers, expose this CGI scripting.
As a result, exploiters of Shellshock only need to scan for web servers that utilise CGI scripting. Then they can take total ownership of that system, no authentication needed, to do whatever they want. This could mean stealing certificates, attacking other hosts or going further into the corporate network.
The Bash vulnerability once again highlights that new vulnerabilities will be discovered. When this happens in services that are widely deployed and allow remote code execution - such is the case with the Bash Unix shell - organizations must have processes in place to quickly test an update and roll it out to the vulnerable devices or software rapidly.
Just like with Heartbleed, the race is on to install signatures to detect and block such attempts to exploit Shellshock. Also like Heartbleed, many systems will continue to go unpatched and exposed to the malicious uses of the internet hackers. As protection signatures become available, organisations must be able to quickly test new signature updates for prevention systems.
Jason Hart, VP Cloud Solutions, SafeNet:
The Bash vulnerability arises from the fact that you can create environment variables with specially-crafted values before calling the Bash shell. These variables can contain code, which gets executed as soon as the shell is invoked. The name of these crafted variables does not matter, only their contents.
Given the interconnectedness of everything, it’s nearly impossible to ensure all devices and systems are without security flaws and to defend what is now a very porous perimeter. That is why we have entered the zero trust era of security, which means that it is more important than ever for companies to place security directly on the data itself, with encryption and multi-factor authentication.
Troy Gill, senior security analyst, AppRiver:
Shellshock poses every bit as great a threat as Heartbleed. System administrators are now in a race against the clock to determine if their Linux based systems are in fact vulnerable and to get them patched before the expected surge in effort of those actively exploiting this vulnerability. The vulnerability exists within Bash - which is an extremely common command shell in Linux and Unix systems, and allows for remote code execution.
One major element that I believe could cause some issues is the fact that a lot of these users are part of the community that likes to believe that their systems don’t get malware because of the operating systems that they use. While it’s true they are less targeted, they are in no way invulnerable to attack. This could be a case in point if cybercriminals decide to make a move to quickly begin exploiting this vulnerability.
Today, businesses need to be doing a full review to identify any systems that are vulnerable to 'Shellshock’ and patch them. Time being a major factor in avoiding any looming attacks.
Initial indications are that ShellShock (the Bash flaw) has existed in the code for a longer period than Heartbleed, and is in a more general-use area of the code. Correspondingly, this vulnerability will likely be more widespread and in code that is no longer being maintained, such as legacy routers and NAS devices. Clearly this has wider security implications than Heartbleed, and suggests need for additional incremental layers of security as well as patches.
Tim Erlin, director of security and risk, Tripwire:
This vulnerability in Bash delivers a kind of double-whammy to the IT security folks responsible for patching systems. The overlap of systems vulnerable to Heartbleed will be very high, and so the systems that are already difficult to patch for Heartbleed will also be difficult to patch for this new vulnerability. It won’t be long before we have a call to action for addressing this because of an actively used exploit.
Ian Pratt, co-founder, Bromium:
The ‘Shellshock’ Bash vulnerability is a big deal. It's going to impact large numbers of Internet-facing Linux/Unix/OS X systems as Bash has been around for many years and is frequently used as the 'glue' to connect software components used in building applications. Vulnerable network-facing applications can easily be remotely exploited to allow an attacker to gain access to the system, executing with the same privilege the application has. From there, an attacker would attempt to find a privilege escalation vulnerability to enable them to achieve total compromise.
Bash is part of the infrastructure, something so pervasive that many sysadmins wouldn't necessarily even know that the security of their applications depend on it. Any applications known to be using CGI scripts that call system or popen are at particularly risk: many php, perl and python scripts will fall into this category. Some python modules call os.system without the application doing so explicitly. Simply disabling Bash is typically not an option, though it may help to change applications' default shell to some other Bourne shell compatible shell such as 'sh' or 'dash' (though beware: 'sh' is actually the same binary as Bash on some systems). However, if an application invokes Bash explicitly it will still be vulnerable.
Even client systems that don't explicitly run network facing services may be vulnerable too, by way of software such as the DHCP client that may pass data received from a DHCP server through Bash. This means that malicious WiFi hotspots could potentially compromise vulnerable systems.
All Linux/Unix/OS X sysadmins should be scrambling to update Bash on all their systems, prioritizing those exposed to untrusted networks.
Bash is a very complex and feature-rich piece of software that is intended for interactive use by power users. It does way more than is typically required for the additional role for which it is often employed in gluing components together in applications. Thus it presents an unnecessarily broad attack surface: this likely won't be the last vulnerability found in Bash. Application developers should try to avoid invoking shells unless absolutely necessary, or used minimalist shells where required.
Dr David Chismon, senior researcher, MWR InfoSecurity:
Gavin Millard, EMEA technical director, Tenable:
The potential for attackers utilising ShellShock is huge with millions of UNIX and Linux servers vulnerable. The major concern of ShellShock is the staggering amount of systems that have Bash installed – almost every UNIX platform and many of the ‘Internet of Things’ devices we now have in our homes and businesses.
Unfortunately, due to the ease of exploit, ShellShock is a prime candidate for a worm. We could be looking at another SQL Slammer like worm but instead of 100,000 servers being affected, it could be more like 100,000,000, which would be catastrophic.
Every organization should be scanning for this vulnerability today and patching everything they can. On a scale of 1-10, 10 being critical, this bug is an 11 and should be treated as such.
On the surface, the general public would appear not to be at risk due to windows being the platform of choice but attackers could easily upload malware to trusted destinations on the web to infect the unaware visitors.
Tom Cross, director of security research, Lancope:
It will take a long time for all of the implications of the Shellshock vulnerability to come to light. The most obvious vulnerable systems will be patched over the next few days, but there will be corner cases, particularly where Linux is used in appliances and embedded devices, where the vulnerability will linger on for a long time. This is similar to what we've experienced with Heartbleed, where months later we're still hearing about things like VPN concentrators getting compromised in the wild, and researchers are still discovering things that can be done with it.
Shellshock is particularly concerning in the context of Industrial Control Systems and SCADA, where there may be many vulnerable devices that are difficult to upgrade. Earlier this year, a sophisticated waterhole attack targeted users of a variety of industrial control systems and industrial cameras. Those attackers now have an entirely new attack vector to explore.
Richard Cassidy, senior solutions architect, Alert Logic:
We have to take stock of when Bash was first developed, and that security issues are still widely related to the fact that developers aren’t (and in most cases can’t) able to test their code against all conditions, variables and security related scenarios. The specific vulnerability found does require a specific set of conditions to be met. We need to look at this in context; yes it's a vulnerability and organizations should absolutely take steps to apply those patches currently being released; but to be exploited with this vulnernability we’d be looking in most instances at a very targeted attack, as opposed to an opportunistic ‘script-kiddie’ one.
The main challenge here is that Bash is the foundational shell for the most popular UNIX operation systems deployed today, not least within OS X; As such it has existed for quite some time indeed, making this vulnerability far wider reaching (and affecting more systems globally) than the Open-SSL HeartBleed.
Given the extent of the operating system versions it affects, organizations are going to have a great deal of work to do, to get patched, and should commence sooner rather than later. RedHat and Fedora have already led the charge on remediation, however we really need to see an update from Apple on their plans to get OS X patched.
The overall lesson that has to be learned here, given our experiences with HeartBleed (and many others before) is that even the most trusted protocols and Operating Systems still have code level vulnerabilities that will continue to be discovered. Good security practices and systems will ensure that users within organizations should have limited exposure to vulnerabilities of this type; however external facing public servers running the affected versions of Bash will be more at risk, such as websites, e-commerce platforms and management systems. If organizations haven’t already, now is the time to put in place extra auditing measures against their critical assets, implementing strict rules on existing security systems to mitigate the risk.
Tyler Reguly, director of security research, Tripwire:
This is a damn serious vulnerability and there are already multiple attack vectors. Presumably, there are a lot of other attack vectors that haven't even been considered yet.
This is a case where patching quickly is particularly important, especially if you're running Internet facing services that may be impacted. Luckily, patches are available and admins and end users should look to apply those patches as quickly as possible.”
Add a comment: email firstname.lastname@example.org
•Date: 26th September 2014 • World •Type: Article • Topic: ISM
To submit news stories to Continuity Central, e-mail the editor.
Want an RSS newsfeed for your website? Click here