Shellshock Awakens Bourne-Again Zombies

The Shellshock bug in the "Bourne Again SHell" (Bash) command interpreter used in many versions of Linux has become the attack vector responsible for successful penetrations of a wide variety of systems in the space of a month. They range from web servers down to embedded systems such as voice-over-IP telephony controllers, some of which were used create a botnet involving 360 machines that was used in a phishing campaign detected by Lancope, a company specializing in flow analysis for security and network performance monitoring.

Discovered in September by developer Stéphane Chazelas, the bug in the command interpreter makes it possible for hackers to force the execution of code of their choosing by adding it to the definitions of environment variables—temporary values used by shells to hold data such as the location of files needed by a shell script, and to send data from one program to another.

Chazelas said his discovery of the bug came partly through a long-standing interest in Unix shells. In July, he found a vulnerability in the library for GNU that could allow exploits to be launched through environment variables, but which had "a very narrow attack surface compared to Shellshock." Realizing that a similar attack might be possible on Bash, he found a much larger security hole there. "I realised that there were more vectors by which that vulnerability could be exploited," he said.

Although hackers would need to have command-line access to use the exploit on Bash directly, it quickly emerged that a significant number of Internet-facing systems could pass the exploit through to the interpreter without demanding the attacker have any login credentials. One common attack vector is through the Command Gateway Internet (CGI) scripts supported by web servers, some of which invoke Bash to process data on their behalf.

"The real problem with Bash is the fact that it was designed to be very flexible at a time when security was a much lower concern than it is today. This is therefore a very difficult situation to resolve," said Simon Reed, global head of labs for IT security firm Sophos. "This is not purely a Bash defect. Effectively, the underlying issue is similar to SQL injection; that is, where an input is carried over and used as part of an input into a flexible tool. Input sanitization is the correct fix, but this means revisiting a large number of systems."

Internet users quickly tried to work out how many hosts were vulnerable. Brandon Tansey, security researcher at Lancope StealthWatch Labs, wrote in the company’s report on the botnet activity: "Since the bug was published, we’ve seen all kinds of scanning activity on the Internet. Some of these scans were benign scans by researchers, but others were distributing malware." Some of those scans allowed hackers to gain access to a wide variety of systems, including a Mitel 5000 phone system, according to Tansey. "One of the major concerns we had about Shellshock was that it would appear in places that people didn’t think to look or patch, and it seems that VoIP gear may be one of those places."

Reed said the attacks should decline in number once the majority of web servers are patched, adding: "But it won’t impact the targeted attacks on niche special-purpose server platforms that are harder to patch and investigate. Many devices or appliances on the market are powered by the Linux operating system, from CCTV cameras to set-top boxes." Reed noted that many will be protected behind firewalls, and so should be inaccessible to remote hackers.

The aftermath of Shellshock has pointed to several potential problems in the security of many systems that are attached to the Internet today. A large proportion of embedded systems based on software such as Linux have not been patched in recent years. Lancope found a quarter of the infected systems it analyzed were running kernels that had not been patched since 2010; their developers and maintainers have no easy way to determine the impact of vulnerabilities that may exist.

Norm Glaude, chief operating officer and vice president of Research and Development at Protecode, a provider of open source license management solutions, said: "I don’t know of any tools out there that can determine, from analysis, how strings built in one language can then be interpreted by another piece of software, like Bash, and determine that an exploit is possible. In any case, the first thing that you should do is to find out whether or not you are using vulnerable software in your bill of materials." Scanning tools, including those sold by Protecode, are available to examine dependencies in source code and determine whether specific applications make use of vulnerable modules.

The question remains whether other, similar vulnerabilities exist, but which have not been investigated because they are in packages not previously thought to be potential targets of hacks, which were developed without the same attention now given to scripts and modules that handle network communications directly. Chazelas said a security researcher would probably have found Shellshock, but "a shell developer could be excused to think his software is unlikely to be network-exploitable."

Chris Edwards is a Surrey, U.K.-based writer who reports on electronics, IT, and synthetic biology.