Feedback Friday: ‘Shellshock’ Vulnerability – Industry Reactions
Posted on September 28, 2014 by Kara Dunlap in Security
The existence of a highly critical vulnerability affecting the GNU Bourne Again Shell (Bash) has been brought to light this week. The security flaw is considered by some members of the industry as being worse than the notorious Heartbleed bug.
GNU Bash is a command-line shell used in many Linux, Unix and Mac OS X operating systems. The vulnerability (CVE-2014-6271) has been dubbed “Bash Bug” or “Shellshock” and it affects not only Web servers, but also Internet-of-Things (IoT) devices such as DVRs, printers, automotive entertainment systems, routers and even manufacturing systems.
By exploiting the security hole, an attacker can execute arbitrary commands and take over targeted machine. Symantec believes that the most likely route of attack is through Web servers that use CGI (Common Gateway Interface). There have already been reports of limited, targeted attacks exploiting the vulnerability.
A patch has been made available, but it’s incomplete. Until a permanent fix is rolled out, several organizations have launched Shellshock detection tools. Errata Security has started scanning the Web to find out how many systems are affected, and Symantec has published a video to demonstrate how the flaw can be exploited.
The security community warns that the vulnerability can have serious effects, and points out that it could take a long time until all systems are patched.
And the Feedback Begins…
Ian Pratt, Co-founder and EVP at 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 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 use minimalist shells where required.”
Mark Parker, Senior Product Manager at iSheriff:
“This bash vulnerability is going to prove to be a much bigger headache than Heartbleed was. In addition to the general Mac OS X, Linux and Unix systems that need to be patched, there are also thousands upon thousands of Internet connected Linux and Unix based embedded devices, such as DVRs, home automation systems, automotive entertainment systems, mobile phones, home routers, manufacturing systems and printers.
Most of these devices will be susceptible because most Linux based devices run bash, it is such an integral part of the Linux OS. I anticipate that we will be continue to see the fallout from this vulnerability for a long time to come.”
Carl Wright, General Manager of TrapX Security:
“We feel that industry will take this very seriously and come out with patches for this vulnerability ASAP. It could take us years to understand how many systems were compromised and how many were used to escalate privileges into systems without this vulnerability. The transitive trust nature of directory architectures and authentications systems could mean we are living with this far beyond patching the current systems if this exploit has been taken advantage of even at a small 1% level.”
Coby Sella, CEO of Discretix:
“This is the second time over the last six months when a key infrastructure component used by billions of connected things across a variety of industries has been compromised. We see this problem only getting worse as more and more unsecured or not adequately secured things are rolled out without any comprehensive security solution that reaches all the way down to the chipset. Real solutions to this problem must cover every layer from the chipset to the cloud enabling companies to remotely insert secrets into the chipset layer via secured connections within their private or cloud infrastructure.”
Nat Kausik, CEO, Bitglass:
“Enterprises with ‘trusted endpoint’ security models for laptops and mobile devices are particularly vulnerable to this flaw. Malware can exploit this vulnerability on unix-based laptops such as Mac and Chromebook when the user is away from the office, and then spread inside the corporate network once the user returns to the office.”
Steve Durbin, Managing Director of the Information Security Forum:
“The Bash vulnerability simply stresses the point that there is no such thing as 100% security and that we all need to take a very circumspect and practical approach to how we make use of the devices that we use to share data both within and outside the home and our businesses. I have my doubts on whether or not this will lead to a wave of cyber-attacks, but that is not to say that the vulnerability shouldn’t be taken seriously. It is incumbent upon all of us as users to guard our data and take all reasonable precautions to ensure that we are protecting our information as best as we are realistically able.”
Steve Lowing, Director of Product Management, Promisec:
“Generally, the Bash vulnerability could be really bad for systems, such as smart devices including IP cameras, appliances, embedded web servers on routers, etc… which are not updated frequently. The exposure for most endpoints is rapidly being addressed in the form of patches to all flavors of UNIX including Redhat and OS X. Fortunately for Microsoft, they avoid much of this pain since most Windows systems do not have Bash installed on them.
For vulnerable systems, depending on how they are leveraging the Bash shell the results could be grave. For example, a webserver that uses CGI for example would likely be configured to use Bash as the shell for executing commands and compromising this system via this vulnerability is fairly straightforward. The consequences could be to delete all web content which could mean Service level agreements (SLA)s are not met because of complete outage or deface the site which tarnishes your brand or even to be a point of infiltration for a targeted attack which could mean IP and/or sensitive customer information loss.
The IoT is the likely under the biggest risk since many of these devices and appliances are not under subject to frequent software updates like a desktop or laptop or server would be. This could result in many places for an attacker to break into and lay wait for sensitive information to come their way.”
Jason Lewis, Chief Collection and Intelligence Officer, Lookingglass Cyber Solutions:
“The original vulnerability was patched by CVE-2014-6271. Unfortunately this patch did not completely fix the problem. This means even patched systems are vulnerable.
Several proof of concepts have been released. The exploit has the ability to turn into a worm, so someone could unleash an exploit to potentially infect a huge number of hosts.”
Ron Gula, Chief Executive Officer and Chief Technical Officer, Tenable Network Security:
“Auditing systems for ShellShock will not be like scanning for Heartbleed. Heartbleed scans could be completed by anyone with network access with high accuracy. With ShellShock, the highest form of accuracy to test for this is to perform a patch audit. IT auditing shops that don’t have mature relationships with their IT administrators may not be able to audit for this.
Detecting the exploit of this is tricky. There are network IDS rules to detect the attack on unencrypted (non-SSL) web servers, but IDS rules to look for this attack over SSL or SSH won’t work. Instead, solutions which can monitor the commands run by servers and desktops can be used to identify commands which are new, anomalistic and suspect.”
Mike Spanbauer, Managing Director of Research, NSS Labs:
“Bash is an interpretive shell that makes a series of commands easy to implement on a Unix derivative. Linux is quite prevalent today throughout the Web, both as commerce platform and as commercial website platform. It happens to be the default script shell for Unix, Linux, well… you get the picture.
The core issue is that while initially the vulnerability highlights the ease with which an attacker might take over a Web server running CGI scripting, and ultimately, ‘get shell’ which offers the attacker the means to reconfigure the access environment, get to sensitive data or compromise the victim machine in many ways.
As we get to the bottom of this issue, it will certainly be revealed just how bad this particular discovery is – but there is a chance it’s bigger than Heartbleed, and that resulted in thousands of admin hours globally applying patches and fixes earlier this year.”
Contrast Security CTO and co-founder Jeff Williams:
“This is a pretty bad bug. The problem happens because bash supports a little used syntax for ‘exported functions’ – basically a way to define a function and make it available in a child shell. There’s a bug that continues to execute commands that are defined after the exported function.
So if you send an HTTP request with a referrer header that looks like this: Referer:() { :; }; ping -c 1 11.22.33.44. The exported function is defined by this crazy syntax () { :; }; And the bash interpreter will just keep executing commands after that function. In this case, it will attempt to send a ping request home, thus revealing that the server is susceptible to the attack.
Fortunately there are some mitigating factors. First, this only applies to systems that do the following things in order: 1) Accept some data from an untrusted source, like an HTTP request header, 2) Assign that data to an environment variable, 3) Execute a bash shell (either directly or through a system call).
If they send in the right data, the attacker will have achieved the holy grail of application security: ‘Remote Command Execution.’ An RCE basically means they have completely taken over the host.
Passing around data this way is a pretty bad idea, but it was the pattern back in the CGI days. Unfortunately, there are still a lot of servers that work that way. Even worse, custom applications may have been programmed this way, and they won’t be easy to scan for. So we’re going to see instances of this problem for a long long time.”
Tal Klein, Vice President of Strategy at Adallom:
“What I don’t like to see is people comparing Shellshock to Heartbleed. Shellshock is exponentially more dangerous because it allows remote code execution, meaning a successful attack could lead to the zombification of hosts. We’ve already seen one self-replicating Shellshock worm in the wild, and we’ve already seen one patch circumvention technique that requires patched Bash to be augmented in order to be ‘truly patched’. What I’m saying is that generally I hate people who wave the red flag about vulnerabilities, but this is a 10 out of 10 on the awful scale and poses a real threat to core infrastructure. Take it seriously.”
Michael Sutton, Vice President of Security Research at Zscaler:
“Robert Graham has called the ‘Shellshock’ vulnerability affecting bash ‘bigger than Heartbleed.’ That’s a position we could defend or refute, it all depends upon how you define bigger. Will more systems be affected? Definitely. While both bash and OpenSSL, which was impacted by Heartbleed, are extremely common, bash can be found on virtually all *nix system, while the same can’t be said for OpenSSL as many systems simply would require SSL communication. That said, we must also consider exploitability and here is where I don’t feel that the risk posed by Shellshock will eclipse Heartbleed.
Exploiting Heartbleed was (is) trivially easy. The same simple malformed ‘heartbeat’ request would trigger data leakage on virtually any vulnerable system. This isn’t true for Shellshock as exploitation is dependent upon influencing bash environment variables. Doing so remotely will depend upon the exposed applications that interact with bash. Therefore, this won’t quite be a ‘one size fits all’ attack. Rather, the attacker will first need to probe servers to determine not only those that are vulnerable, but also how they can inject code into bash environment variables.
The difference here is that we have to take application logic into account with Shellshock and that was not required with Heartbleed. That said, we’re in very much in the same boat having potentially millions of vulnerable machines, many of which will simply never be patched. Shellshock, like Heartbleed, will live on indefinitely.”
Mamoon Yunus, CEO of Forum Systems:
“The Bash vulnerability has the potential to be much worse than Heartbleed. Leaking sensitive data is obviously bad but the Bash vulnerability could lead to losing control of your entire system.
The Bash vulnerability is a prime example of why it’s critical to take a lockdown approach to open, free-for-all shell access, a practice that is all too common for on-premise and cloud-based servers. Mobile applications have caused an explosion in the number of services being built and deployed. Such services are hosted on vanilla Linux OS variants with little consideration given to security and are typically close to the corporate edge. Furthermore, a large number of vendors use open Linux OSes, install their proprietary functionality, and package commercial network devices that live close to the network edge at Tier 0. They do so with full shell access instead of building a locked-down CLI for configuration.
The Bash vulnerability is a wake-up call for corporations that continue to deploy business functionality at the edge without protecting their services and API with hardened devices that do not provide a shell-prompt for unfettered access to OS internals for anyone to exploit.”
Jody Brazil, CEO of FireMon:
“This is the kind of vulnerability that can be exploited by an external attacker with malicious intent. So, how do those from the Internet, partner networks or other outside connection gain access to this type of exposure?
An attack vector analysis that considers network access through firewalls and addresses translation can help identify which systems are truly exposed. Then, determine if it’s possible to mitigate the risk by blocking access, even temporarily. In those cases where this is not an option, prioritizing patching is essential. In other cases where, for example, where there is remote access to a vulnerable system that is not business-critical, access can be denied using existing firewalls.
This helps security organizations focus their immediate patching efforts and maximize staffing resources. It’s critical to identify the greatest risk and then prioritize remediation activities accordingly. Those are key best practices to address Bash or any vulnerability of this nature.”
Mark Stanislav, Security Researcher at Duo Security:
“While Heartbleed eventually became an easy vulnerability to exploit, it was ultimately time consuming, unreliable and rarely resulted in ‘useful’ data output. Shell Shock, however, effectively gives an attacker remote code execution on any impacted host with a much easier means to exploit than Heartbleed and greater potential results for criminals.
Once a web application or similarly afflicted application is found to be vulnerable, an attacker can do anything from download software, to read/write system files, to escalating privilege on the host or across internal networks. More damning, of course, is that the original patch to this issue seems to be flawed and now it’s a race to get a better patch released and deployed before attackers leverage this critical bug.”
Rob Sadowski, Director of Technology Solutions at RSA:
“This is a very challenging vulnerability to manage because the scope of potentially affected systems is very large, and can be exploited in a wide variety of forms across multiple attack surfaces. Further, there is no single obvious signature to help comprehensively detect attempts to exploit the vulnerability, as there are so many apps that access BASH in many different ways.
Because many organizations had to recently manage a vulnerability with similar broad scope in Heartbleed, they may have improved their processes to rapidly identify and remediate affected systems which they can leverage in their efforts here.”
Joe Barrett, Senior Security Consultant, Foreground Security:
“Right now, Shellshock is making people drop everything and scramble to fix patches. Security experts are still expanding the scope of vulnerability, finding more devices and more methods in which this vulnerability can be exploited. But no one has gotten hacked and been able to turn around and point and say ‘It was because of shellshock’ that I’ve seen.
If you have a Linux box, patch it. Now. Do you have a Windows box using Cygwin? Update Cygwin to patch it. And then start trying to categorize all of the ‘other’ devices on the network and determining if they might be vulnerable. Because chances are a lot of them are.
Unfortunately, vendors probably will never release patches to solve this for most appliances, because most [Internet-connected] appliances don’t even provide a way to apply such an update. But for the most part all you can do is try to identify affected boxes and move them behind firewalls and out of the way of anyone’s ability to reach them. Realistically, we’ll probably still be exploiting this bug in penetration tests in 8 years. Not to mention all of the actual bad guys who will be exploiting this.”
Until Next Friday…Have a Great Weekend!
Related Reading: What We Know About Shellshock So Far, and Why the Bash Bug Matters
Tags:
