In this interview, Alert Logic's senior solutions architect, Richard Cassidy, goes into detail about the recent Bash vulnerability that's affecting many people. He describes who's at risk, where it came from, and its similarities to Heartbleed.
Josiah Renaudin: First, could you tell us a bit about your experience in the industry?
Richard Cassidy: I’ve been working in the security industry for over fifteen years, starting out in mainframe programming through ROSCOE, then moving into network and systems management on windows and Novell. After a short while I moved into network design and security, progressing into virtualization and eventually cloud-based solutions thereafter.
I’ve worked almost exclusively at the vendor level, representing the likes of Netscreen, Fortinet, and Alert Logic in the international markets on all aspects from strategic product development to end-user sales and channel growth strategies. At heart, I am a technologist with a deep interest into how users and organizations can utilize the latest technologies more effectively—both from an operational and security perspective—mitigating risk, understanding business weaknesses, and how technology can help to solve those problems.
Josiah Renaudin: Now, could you explain exactly what this Bash vulnerability is and what it’s doing?
Richard Cassidy: First, it’s important to understand what “bash” actually is at a high level and how it intrinsically drives a great deal of operations within Unix and Linux. Bash quite simply allows programs to interface with the operating system on which they are running. Through the Bash shell, applications and users can interface with the underlying Linux/Unix system, running commands or scripts to perform system level actions.
If you have access to bash, you quite simply have access to the underlying system and can in practice use bash to execute commands; in the case of an attacker, these commands would be targeted to steal data, attempt to install malicious software or cause system crashes.
So to put it in context, let’s look at DHCP, which is the protocol that serves up IP’s for every user that connects to a WIFI access point or wired network. When you make a request for an IP, the server will respond with your IP address and additional values in the response that provide gateway, network mask, etc. On OS-X for instance, DHCP requests will use bash to apply the settings to the network interface. If you were unfortunate enough to connect to a malicious DHCP server, or one that was compromised by an attacker, they could insert additional information into that DHCP response that would be executed by bash and could cause a client system to be compromised.
The challenge with bash is that it was never written to verify if these additional strings (outside of expected) are valid; as such, it means that attackers can inject their own arbitrary commands, expecting bash to run those commands and gain access to the system, or have the system perform actions it shouldn’t.
Josiah Renaudin: How was it discovered?
Richard Cassidy: It was discovered by Stéphane Chazelas, a Unix/Linux and Telecoms specialist, who has contributed massively to the security industry as a whole, given his history of bug discoveries in Linux/Unix over the past while.
Josiah Renaudin: Who does this affect? Which operating systems are at risk?
Richard Cassidy: Unfortunately, if we go back in time through the various releases of bash, it’s not possible to pinpoint exactly when this vulnerability was introduced. Sources have verified that it has most likely remained undiscovered since a version released as far back as 1992.
This is hugely concerning from a security perspective across the industry as a whole, and it means any operating system running Bash version 1.13 or later would be affected. Bash hasn’t just been confined to Linux, Unix, and OS-X implementations —it also found its way into Windows to support UNIX based applications, in addition to being implemented in versions of DOS under Windows.
It therefore affects everyone. Even if you’re not running a client with an affected version of bash, users will most likely be accessing affected web services, or could be unfortunate enough to connect to compromised network devices as a result of the bash vulnerability. There is an entire list of resulting security concerns that could arise from connecting to compromised sites or network devices; the net effect being everyone is at risk in some fashion or another.
Josiah Renaudin: How extensive will the patching process be? What can be done to stamp out this fire before it spreads too far?
Richard Cassidy: Organizations have already started network-wide patching, but this hasn’t just been limited to client systems and servers. It’s also including network level devices, not least because routers, switches, access points, and security gateways may run affected versions of bash. The challenge will arise for those systems that are now out of support, such as old hardware/software that a great deal of organizations still use, unfortunately.
Given the length of time this vulnerability has technically existed, organizations need to take action immediately to enhance (if not done already) auditing of their critical assets for anomalous or unauthorized activity. Furthermore, stringent security policies on permitted services, user access, file integrity monitoring (specifically for web services) and controlled access from external/internal sources, should all be reviewed, to limit any exposure to remnants to a potential success bash exploit. For hosted solutions or those provisioned in the cloud, organizations need to ensure that their providers have undertaken all necessary steps to mitigate the exploit and patch their own systems accordingly.
Josiah Renaudin: Can you explain the similarities between this vulnerability and Heartbleed? Which do you think is more serious?
Richard Cassidy: In respect that these exploits injected arbitrary commands into a request to have the system perform an unauthorized action and that the exploit existed as a result of the program not implementing any checks against these arbitrary commands, one could deduce they are similar. It is difficult to succinctly position which is the more serious exploit. In short, HeartBleed only affected OpenSSL and would have allowed an attacker to gain sensitive data, such as certificate “private keys,” not least users “session cookies” and “passwords.” Given where bash sits within the operating system, it affects a far greater number of systems globally than we saw with HeartBleed. Making a choice on which is the more serious really depends on your perspective from a security and operational point of view. That said, my vote goes to HeartBleed, given what it was able to leak from publicly available systems and that it struck at the core of encryption and security industry wide.
Josiah Renaudin: Can we take lessons away from the Heartbleed incident and use them to more easily resolve the Bash issue?
Richard Cassidy: Absolutely. HeartBleed proved the need for more stringent code-based security protection and more effective auditing of what data is being accessed, by whom, and where it’s going. Organizations post-HeartBleed would have made moves to implement “web application firewalls” at the point of access to web services, so that arbitrary command injections into OpenSSL, or any web-based application, would be seen and could be prevented. We should also have seen more streamlined patching/updating policies on lessons learned from HeartBleed, meaning that the extensive patching required to remediate the affected versions of bash should be far more efficient and effective.
Josiah Renaudin: What can we do to prevent something like this from happening within other operating systems?
Richard Cassidy: Often the first trace of a compromise is anomalous behavior on system access, settings, or data transport. Implementing technologies that provide complete visibility, detailed analysis, and easy to understand reporting is key against threats of this type. HeartBleed (and now bash) should have brought a great deal of light on the need for greater visibility from a security auditing perspective across the entire organization. What we can be assured of is that bash won’t be the last exploit of this kind we’ll see in the industry.
