In Sept. 2014, a vulnerability known as Shellshock (also known as Bashdoor) was discovered and disclosed. And that’s potentially big news for organizations who operate, maintain or otherwise use Linux-based security equipment — which can now be considered vulnerable to hackers.
“There are a bunch of vendors potentially vulnerable, and therefore worth checking,” warns Rodney Thayer, a consultant who specializes in software engineering and risk management for identity management hardware and software. “Any equipment known to be Linux-based should be inquired about.”
A majority of standalone security devices employ embedded Linux; thus, Shellshock poses a real potential for device vulnerability, if access can be gained to the security device, either directly or indirectly. The bug can have an effect on “Internet of Things” devices as well.
Individual manufacturers have been sporadically releasing notes to their users clearing their products of the vulnerability. On Sept. 26, Axis, for example, issued the following directive: “No Axis products are affected, as BASH (Bourne Again Shell) is not included in the firmware.”
Within an hour of the announcement of the Bash vulnerability, there were reports of machines being compromised by the bug. Sept. 25, various news outlets reported that botnets based on computers compromised by Shellshock were being used by attackers for distributed denial-of-service (DDoS) attacks and vulnerability scanning.
Obviously, security integrators should be doing something to protect their clients from being Shellshocked themselves; but first, let’s take a look at what Shellshock is, how hackers are using the vulnerability to access end-devices, and ultimately how to protect against it.
How it Works
Shellshock, which can potentially affect UNIX (including some versions of Linux) and Mac OS systems, has actually existed in the Bash shell since 1989. Still, its discovery on Sept. 24, 2014, is what brought the vulnerability to the attention of the world, as it could allow a cyber attacker to execute commands and ultimately gain access to a vulnerable system.
A UNIX “shell program” interprets user commands directly entered or read from a shell script or program file. In the latter case, the shell searches for commands contained in the script to derive an executable file. Shellshock allows malicious code execution to potentially provide privileged access for an unauthorized user or system process to take over an operating system, access confidential information, or even transmit data (exfiltrate) to remote locations. It is commonly accessed through Command Prompt on PC or the Terminal application on a Mac.
Bash is the GNU Project’s Bourne Again Shell, used extensively for the features it provides — including customizable editing, job control, integer arithmetic, expanded I/O capability and more. The GNU operating system is a completely free software system, upward-compatible with Unix, that incorporated Linux in the early 1990s to evolve a complete operating system. Bash has since been ported to nearly every version of Unix, and has been described as one of the most installed utilities on any Linux system.
Shellshock provides the ability to trick the Bash shell by masking commands as environmental variables, dynamic objects that help programs know directory destinations for file installations, temporary file or value storage destinations, user profile settings and more. Shell scripts and batch files use environment variables to communicate data and preferences to child processes. The command is then unknowingly executed, allowing an attacker the same level of access as the system launching the shell, potentially allowing full control of the servers and systems. An official alert from the National Institute of Standards and Technology warned that the vulnerability was “a 10 out of 10,” in terms of its severity, impact and ability to be exploited, but low in terms of its complexity, meaning that it could be easily used by hackers.
“We’ll never be able to catalog all the software out there that is vulnerable to the Bash bug,” Robert Graham of Errata Security (www.erratasec.com) was quoted in a posting on CNET. “While the known systems (like your Web server) are patched, unknown systems remain unpatched. We see that with the Heartbleed bug: six months later, hundreds of thousands of systems remain vulnerable.”
Graham warned that the Bash bug was also particularly dangerous for connected Internet of Things devices because their software is built using Bash scripts, which are “less likely to be patched...and more likely to expose the vulnerability to the outside world”.
Similarly, Graham said the bug has existed for a “long time” meaning a great number of older devices will be vulnerable. “The number of systems needing to be patched, but which won’t be, is much larger than Heartbleed,” he said. “On the scale of 1 to 10, this is an 11,” he added, estimating that half a million websites were vulnerable.
Patches
Attackers have been quick to exploit Shellshock by building the “wopbot” botnet — a botnet that is active and scanning the internet for vulnerable systems to infect, including the United States Department of Defense.
“Modern embedded systems often have so much storage space that they could use a richly featured shell like bash. Since embedded systems are rarely updated, or may not even have an update process, this could be a real problem, says security researcher David A. Wheeler (www.dwheeler.com). “How many embedded systems have bash? I have no idea, but I think we’re going to find out.”
Wheeler has published a free book, “Secure Programming for Linux and Unix HOWTO,” which provides a set of design and implementation guidelines for writing secure programs for Linux and Unix systems (see www.dwheeler.com/secure-programs).
“Systems should be designed and implemented so that they have least privilege,” Wheeler explains. “In short, break components down and only give them the access they need (through file privileges, SQL grants, sandboxes and so on). Also, your systems need to be prepared to have timely updates.”
The biggest concern about Shellshock is that systems that did not quickly apply the patch or other countermeasures, such as traffic filtering. In fact, Wheeler says that full patches for bash were available quickly — but that does not matter if system developers and administrators do not deploy it. “People need to be either prepared to update their systems quickly, or have it done automatically for them,” Wheeler says. “This lack of preparedness puts us all at risk. Organizations should be required to either provide timely updates, or provide users with the means necessary so that they can update their systems (e.g., the ability to update the software), at least for a reasonable length of time (say, a decade).”
Impact on Security Integrators
Integrators and users should attempt to see if products in the systems they sell or have installed might be at risk — but do not simply leave it up to the individual manufacturers to keep you informed of software vulnerabilities. “The U.S. Department of Homeland Security National Vulnerability Database (https://nvd.nist.gov/) is an excellent resource for software developers and product manufacturers to check products and versions on a periodic basis,” says Darnell Washington, President and CEO of SecureXperts. “Also, there is a corporate tool available at www.belarc.com that performs asset inventory, version management and patch management. It is an excellent resource.”
It also means that integrators should be working closely with their clients’ IT departments. Asset Management Inventories are common for hardware, software and security products, but now deeper levels of discovery must be performed by IT. Those involved in systems administration and configuration management need to be especially aware of the composition of products that comprise their total Information and Physical Security Environment. Yes, that means your clients have culpability in information assurance, but working closely with them to patch these vulnerabilities can’t hurt.
In short, don’t take it for granted that everything is going to be OK. Everyone needs to assume cyber responsibility.
Ray Coulombe is Founder and Managing Director of SecuritySpecifiers.com and RepsForSecurity.com. Reach him at [email protected], through LinkedIn at www.linkedin.com/in/raycoulombe or followed on Twitter @RayCoulombe.
