Security Experts:

What We Know About Shellshock So Far, and Why the Bash Bug Matters

About the Shellshock Vulnerability

Security researchers around the world have been working around the clock analyzing the recently disclosed flaw in Bash which can be exploited to execute code and hijack vulnerable devices. Attackers are already targeting the bug, which has been nicknamed Shellshock, and security experts warned organizations to prepare for more attacks and messy cleanup.

The investigation is still in the early stages and there are a many unanswered questions about how Shellshock can be abused. Opinions also vary wildly among experts as to its potential impact. What is known—and agreed upon—at this point, is that Shellshock is a very serious vulnerability because it allows remote code execution and gives the attacker full access to the system. Being able to get shell and execute any kind of program on the target system is a major coup for attackers

Bash "is widely used so attackers can use this vulnerability to remotely execute a huge variety of devices and web servers," said Tod Beardsley, engineering manager at Rapid7.

The most obvious initial targets will be large hosting providers, "which are riddled with bash-enabled administrative functions, as well as innumerable PHP-based forums, blogs, stores," suggested Daniel Ingevaldson, CTO of Easy Solutions.

Measuring the Problem

However, just because so many versions of Bash—from version 1.13 to 4.3—are vulnerable doesn't mean any machine with it installed can be exploited. As the researcher who disovered the bug, Stephane Chazelas, a network and telecommunications administrator with Akamai, and other experts have said, the targeted system must have a script or application which attempts to call Bash in order for the attack to succeed. And even so, the flaw is complex enough that it is currently difficult to specify which set of circumstances mean the system is vulnerable to attack, and when it isn't, Red Hat warned in its advisory.

"It's extremely hard to tell whether it's [system with vulnerable Bash] usable by a remote attacker, even though it's relatively easy to tell whether the flaw is present," said Dr. Mike Lloyd, CTO of RedSeal Networks. "Our environments are so complex that even on a single machine, we can know there’s cheese in the center of the maze, but the maze of software and configuration interactions is too complicated for a human analyst to be able to say categorically ‘the cheese is exposed, or is not exposed, to the rat,’" said Lloyd.

This makes it difficult to estimate just how widespread the issue is. Shortly after the vulnerability was disclosed, Robert Graham of Errata Security wrote a script scanning Internet-facing machines as an attempt to measure the extent of the problem. If the scanned machine was vulnerable, it sent a ping request back to Graham's machine. While he quickly wound up with 3,000 Linux machines, he also realized there were a whole lot more machines that were vulnerable that he wasn't picking up with his script.

Dan Kaminsky, currently chief scientist at White Ops, noted on Twitter that Shellshock is difficult to measure and it is a challenge to assess the risk of the bug. "If nothing else, this bash bug is *way* more annoying to scan for than Heartbleed ever was," said Kaminsky.

Attacks in Progress

Graham also suggested a self-replicating worm could find and infect vulnerable servers on the network, and within hours after his initial scanning exercise, researchers observed some worm activity and other attacks. Some attackers repurposed Graham's proof-of-concept script to install malware on to vulnerable machines, giving them a backdoor onto the vulnerable systems. Attackers are aggressively scanning the entire IPv4 address space to quickly find vulnerable machines and build them into botnets, said Ingevaldson.

Some machines have been compromised and are already being used to launch distributed denial-of-service attacks at multiple targets, according to Kaspersky Lab.  BitDefender reported multiple "very easy to implement" attacks against Web servers where an automated tool was used to access CGI scripts and environment variables were passed as part of the User-Agent string. There are reports of at least two different worms attempting to infect vulnerable machines.

AlienVault reported two worms actively exploiting the vulnerability and installing malware on a honeypot server, said Jaime Blasco, labs director at AlienVault. The worms themselves were currently "very stupid" and not going to cause a lot of damage. However, as attackers figure out what applications to look for and refine their plans, the worm vector will become very dangerous, Blasco warned.

David Jacoby, a senior researcher at Kaspersky Lab, said he was aware of a worm using two different methods to spread itself. Essentially, the worm exploited Shellshock to take over a vulnerable server, and then scanned the network the server was on to find "more like machines," Jacoby said. It wasn't clear if this was a third worm in the wild, or one of the two Blasco had observed.

"Enterprises with 'trusted endpoint' security models for laptops and mobile devices are particularly vulnerable to this flaw," said Nat Kausik, CEO of Bitglass Technologies. A machine infected while away from the office can spread and infect other machines when it reconnects to the corporate network, he said.

Bash's ubiquity and the fact the flaw can be targeted by worms are cause for great concern, Rich Mogull, analyst and CEO of Securosis, warned in a blog post. If an organization's Internet-facing server gets infected, the worm would be able to find and infect other machines on the same network. "That places it into Code Red/Nimda territory. A workable bug that can exploit public Web servers is scary," Mogull wrote. "Potential worms are like staring at the smoking volcano while the earthquakes stir your martini—they aren't the sort of thing you can wait for definitive proof on before taking seriously."

While much of the attention thus far has been on the HTTP vector, such as modifying the environment variable through Apache's mod_cgi or mod_cgid, or on potential worm activity, there are other attack vectors, such as DHCP. A proof-of-concept from TrustedSec determined that a machine connecting to a rogue DHCP server could be compromised via its DHCP client. Anything that uses DHCP—any Linux or Mac OS X machine using the built-in DHCP client, for example—connecting to that rogue server would be compromised, Kaspersky's Jacoby said. What's frightening about this attack vector is that nearly every piece of networking gear nowadays comes with a DHCP client, and many of these devices can't easily be patched, he said. This has serious implications for the Internet of Things such as networked devices in the home, many of which run Bash, Jacoby said. While some researchers have suggested that embedded devices run BusyBox or other interpreters, Jacoby was able to verify several popular home devices had Bash installed.

There were reports on Twitter claiming that Apple had a custom implementation in its DHCP client and would not be vulnerable. SecurityWeek is waiting for TrustedSec to clarify whether its proof-of-concept works on Mac OS X.

Mac OS X systems are affected by the flaw, but Apple has clarified that users should not be concerned unless they have configured advanced UNIX services. According to the company, a patch is being developed for advanced UNIX users. Mac security firm Intego has published a blog post that outlines two possible attack scenarios.

Administrators should be watching their logs carefully, as exploits targeting the vulnerability would be "noisy and easily logged," Ingevaldson said. This is in contrast to Heartbleed, which experts warned was stealthy and it would be impossible to tell if attackers had targeted the flaw.

ThreatStream released an open source honeypot tool called ShockPot which organizations can install and run on their networks. ShockPot will capture the attacks hitting the network, and provide administrators with indicators which can then be used to write firewall or Snort rules to deflect those attack attempts, said Greg Martin, CTO of ThreatStream.

Affects of Shellshock VulnerabilityInsecure Code Practices

Shellshock is "one of the kids of vulnerabilities that makes old infosec guys chuckle," said Ingevaldson, noting the bug itself and how it can be exploited "is not a marvel of complexity." It isn't "one of these insane memory corruption vulnerabilities that requires bypassing DEP, ASLR, perfect alignment across multiple vulnerable versions or advanced memory leaking techniques," he said.

This vulnerability in Bash reinforces why it is important to always write code with security in mind, said Tom Gorup, security operations center manager at Rook Security. The vulnerability has to do with how environment variables are set. When scripts make these types of calls, the requests should be "heavily filtered and escaped appropriately" to prevent code from being executed out of what the application is supposed to do, he said. Developers for years did not worry about protecting the calls made to Bash, which is why the discovery of this bug is so serious. If the Web administrators were running web servers as users with limited permission sets and developers were properly controlling user input, Shellshock wouldn't be such a big issue.

"Unfortunately, we know that secure development and administration practices are not widely adopted," Gorup said.

Comparisons to Heartbleed

The seriousness of the flaw, and the difficulty in measuring the impact, has many experts claiming the issue is similar to Heartbleed, the OpenSSL vulnerability which was discovered back in April. Others are still hedging their bets.

Shellshock is a far more serious issue than Heartbleed, because it gives attackers complete control of the system, rather than just exposing potentially sensitive data such as user credentials."Heartbleed was big—but Heartbleed just allowed a hacker to spy on computers—not take control of them," said Kyle Kennedy, CTO, STEALTHbits Technologies.

But seriousness doesn't necessarily translate to high-impact. Major providers such as Google, Yahoo, or Microsoft may not be susceptible to Shellshock to the magnitude they were to Heartbleed, for example. "This bug will not be as big as Heartbleed in terms of number of vulnerable systems that can be exploited," said Alberto Soliño, a technical program manager at Core Security. Of course, researchers haven't figured out yet all the ways Shellshock can be exploited. In situations where it can be exploited, consequences would be much worse.

From an attacker's perspective, however, Heartbleed was easy, as the vulnerability was triggered in the same way most of the time. With Shellshock, attackers will need to craft different exploits for each target scenario to successfully trigger the bug, "making it harder to craft a generic way to exploit this vulnerability," Soliño said.

Rapid7's Beardsley noted this was exactly the reason why it was difficult to write a Metasploit module demonstrating the vulnerability. "This is the sort of exploit that will be lurking around in all various and sundry sorts of software, both local and remote," Beardsley said.

Not being able to determine the impact makes it harder for organizations to assess risk and prioritize closing the vulnerability, suggested Red Seal's Lloyd. If security teams could just say, "this issue must be fixed," then trying to figure out severity and impact wouldn't be necessary. However, in the real world, it's hard to convince the business side of the organization to deal with a vulnerability that may or may not be exploitable. "They won’t stop to apply security fixes to machines that effectively print money without an iron-clad requirement," Lloyd said.


Related: Session Added On Protecting ICS/SCADA Systems from the Shellshock Vulnerability at the 2014 ICS Cyber Security Conference

view counter
Fahmida Y. Rashid is a Senior Contributing Writer for SecurityWeek. She has experience writing and reviewing security, core Internet infrastructure, open source, networking, and storage. Before setting out her journalism shingle, she spent nine years as a help-desk technician, software and Web application developer, network administrator, and technology consultant.