Bash “Shellshock” bug: Who needs to worry?

As expected, attackers have begun exploiting the GNU Bash “Shellshock” remote code execution bug (CVE-2014-6271) to compromise systems and infect them with malware.

After the disclosure of its existence, Alien Vault has begun running a new module in their honeypots and waiting for attackers aiming to exploit this vulnerability.

“We have had several hits in the last 24 hours. Most of them are systems trying to detect if the system is vulnerable and they simple send a ping command back to the attacker’s machine,” shared researcher Jaime Blasco. “Apart from those hits we have found to attackers that are using the vulnerability to install two different pieces of malware on the victims.”

In the first instance, the payload comes in the form of an ELF binary, which fingerprints the infected systems, opens a backdoor into the system, and can make the system participate in DoS attacks and brute force attacks. Zscaler and Kaspersky Lab have more details about this particular attack, which seems to target Nginx and Apache web servers configured to use mod_cgi.

In the second instance, the payload is a repurposed IRC bot that connects to an IRC server and waits for commands.

In the meantime, Google researcher Travis Ormandy found a second method (CVE-2014-7169) for exploiting the vulnerability, as the patch for fixing CVE-2014-6271 was incomplete and could still allow some characters to be injected into the targeted environment.

This is a bug that web server admins need to worry about most, and especially if their servers run Bash from cgi-bin, noted SANS ISC CTO Johannes Ullrich. He also provided advice on how admins can protect their servers (also here).

“Web servers are not the only application at risk,” warns Trend Micro. “SSH may also be vulnerable to Shellshock. At this time, any Unix/Linux server OS that uses Bash are at risk. By default, most of these use Bash, with some exceptions. For example, FreeBSD’s default shell is tcsh.”

Regular users can sigh in relief, as not many endpoint devices are vulnerable.

“Current data suggests that around 10% of PC users use some form of Linux or Max OS X. These OSes may be vulnerable to Shellshock, although even here exploitation is more difficult,” they noted.

“For end users, the biggest concern may well be exploits via rogue DHCP servers running on potentially affected routers and hotspots. Bash is used by DHCP clients to set system settings; a client connecting to a rogue DHCP server can end up running malicious commands on their system. This can most easily be done via malicious open WiFi networks. We advise users to be extra cautious of which WiFi networks to connect to, but this is already a part of long-standing best practices.”

Android devices and iOS devices (if not jailbroken) are not affected by the bug. “Rooted and modified devices that now run a *nix variant (and, as a result, Bash) may be affected,” they pointed out.

Apple is yet to release a fix for OS X but, according to an Apple spokesperson, the vast majority of OS X users are not at risk. “With OS X, systems are safe by default and not exposed to remote exploits of bash unless users configure advanced UNIX services. We are working to quickly provide a software update for our advanced UNIX users.”

Finally, some Internet of Things devices built on embedded versions of Linux are vulnerable, and the bug can be exploited to rope them into a botnet. Unfortunately, the patching of some of these devices will be problematic, as some of the vendors are very lax when it comes to creating and issuing security updates.

“This bug is going to affect an unknowable number of products and systems, but the conditions to exploit it are fairly uncommon for remote exploitation,” reassured Rapid7’s Jen Ellis, and opined that the risk of widespread attacks in the wild is lesser than with Hearbleed.

Flavio De Cristofaro, VP of Engineering for Professional Products, Core Security, agrees: “From my perspective, Heartbleed was a bit more troubling due to the affected component and the massive usage of SSL. Bash is available on most *nix systems, and having Bash turns the host vulnerable, but not necessarily remotely exploitable. Additional conditions are needed in order to remotely compromise the host. Basically, you need to be able to inject commands into Bash.”

“Users must patch. Some folks are recommending that user check whether or not they are running CGI – but that is absolutely not enough. C++, Python, PHP and every other application that makes Bash calls are affected. Other applications supporting DHCP, SSH (restriucted shell) may be also affected, not only from a remote attack but also from a local privilege escalation perspective. So patch, patch, patch,” he advises.

“Patches are already available for most well-known systems, or they will be available very soon. Some vendors published an early patch that was incomplete, and they had to publish a new fix today. Putting aside *nix distributions, companies will face significant challenges if they need to patch old systems or systems based on embedded devices like cameras, routers and ICS if they are running Bash. Fortunately, that shouldn’t be too common, since Bash is usually too heavy for systems like that.”