Researchers on Thursday discovered proof-of-concept code that could take advantage of unpatched computer systems, and found evidence of attacks exploiting the BASH Shellshock bug in the wild.
Shellshock, which came to light on Wednesday, could become a major threat to Linux/Unix and Apple operating systems if published patches to BASH are not applied before an attacker cashes in. However, there’s some concern that the current patches may not be complete.
The United States Computer Emergency Readiness Team, or US-CERT, on Thursday issued a warning about the vulnerability.
BASH, the GNU Project’s Bourne-Again SHell, is named after computer scientist Stephen Bourne, who wrote the original Shell code.
“BASH is easier to exploit than Heartbleed in the sense that it doesn’t require technical knowledge as deep. It is probably installed in more places and on more systems than OpenSSH. So in that sense, the available attack surface is larger,” BASH maintainer Chet Ramey told TechNewsWorld.
Another factor that makes the Shellshock Bug more threatening than Heartbleed, which was discovered in April, is the number of services that create environment variables from remote user input. Eventually they invoke a shell, so there are more points of vulnerability, Ramey explained.
The Shellshock bug is not so difficult to patch. However, the process involves relying on a multi-party effort.
Ramey published patches for various BASH versions, back to BASH 3.0, within 20 to 30 minutes of the public disclosure. The vendors were able to push patched versions of BASH into their pipelines very quickly as well, he said.
In most cases, patching a system is simply a matter of running the vendor’s patch process. It is also fairly simple to build BASH yourself from source code, if you have an existing development environment, according to Ramey.
“The problem comes in with old systems that are no longer supported or with Linux systems that are in environments where it is inconvenient to patch, such as embedded systems,” he said.
Work in Progress
The patch for the bug is already in the pipeline, Ramey emphasized — but he has no control over how quickly it’s integrated.
“I produce the patches to the source code,” he said. “The Linux/Unix vendors take them and produce new BASH binaries, and users or system administrators apply them using their usual patch mechanism.”
The time needed to complete the patching process is vendor-dependent. If you are building BASH yourself from source code, you can configure, build and install a patched version within 15 minutes or so, said Ramey.
Environmental variables, which are normal functions for many applications, are what attackers are using to run code against affected systems, according to Ronnie Tokazowski, senior researcher at PhishMe.
“When the first patch came out, the exploit was modified to allow code execution again. Currently, the program is still unpatched,” Tokazowski told TechNewsWorld.
The first patch is incomplete, he said. One user was able to bypass the patch in a short time.
BASH is both the face of Linux and one of the key actors behind the scenes, handling execution of vast amounts of initialization, invocation and other glue code in modern applications. System administrators use it for numerous chores on both Linux and OS X platforms regularly, noted Bill Weinberg, senior director at Black Duck Consulting.
“Fixing Shellshock will be difficult, because the exploit builds upon a key extension to BASH command line functionality, specifically for remote invocation of commands, scripts and other applications,” he told TechNewsWorld. “Shutting down the exploitable functionality will hobble some of the most useful BASH capabilities and thereby limit or cripple many deployed applications and system-level uses.”
When the exploit is addressed, the fix will have to take into account differences in underlying remote invocation APIs across platforms. Both Linux and BSD Unix-derived OS X are *nix OSes, but sometimes exhibit subtle differences in underlying functionality, Weinberg explained.
It is the simplicity of the BASH exploit that makes it so dangerous compared to Heartbleed, said Tokazowski.
For Heartbleed, attackers were able to obtain chunks of memory from a system and dump passwords and private SSL keys. The impact of doing that was profound, as attackers could have used those passwords to get into an enterprise.
For the BASH exploit, on the other hand, all an attacker has to do is pass a parameter to execute code, which is very easy to exploit. With very little effort, an attacker could set up DDoS attacks, create a botnet with affected devices, or crash all of those devices.
“The biggest takeaway is that with Heartbleed, you could get passwords but then needed to do other things to get on a system,” Tokazowski said. “With Shellshock, you just need to craft a response and have the infrastructure, and you’re on the system. Then you can dump all the passwords.”
This security issue led me to inspect my new employer’s own web services.
It turns out that we have an old SSI WEB application – that’s right, server side includes! – and it is easy to compromise it with just a tiny bit of knowledge.
Fortunately for us it is behind a paywall which inadvertently provides a little more security. But others should definitely watch out for this kind of old software as once someone gets in there it will be like falling on a spinning saw blade with 4 inch sawtooths: UGLY.