Shellshock – How Bad Can It Get?

In the immediate aftermath of the Bash vulnerability known as Shellshock, we have already seen some attacks using it to deliver DDoS malware onto Linux systems. However, given the severity of this vulnerability, it is almost certain that we will see bigger, more severe attacks. What are some of the scenarios we could potentially see?

Servers

Web servers are currently at the highest risk of being exploited. CGI scripting is, at this time, the most reliable and best documented way of exploiting this vulnerability. As our earlier entry noted, we have already seen attacks in the wild that use this method. We expect to see more of these attacks moving forward.

The damage to organizations if web servers are compromised can be significant. A compromised server can also be the entry point for attackers into the organization’s network. The attacker can choose to run any set of commands on the affected servers. Pairing Shellshock with some other form of privilege escalation vulnerability would completely compromise an affected server.

However, web servers are not the only application at risk. 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. The alternatives to Bash are not believed to be vulnerable.

Endpoints

The direct risk to end users of Shellshock may be less. Windows systems are not at risk from Shellshock, so users of those systems will not be directly affected by these issues.

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. Endpoints typically do not have running network services (like HTTP servers) that an attacker can easily access, reducing the risk. Mac applications have never relied on as heavily on shell scripts as do Unix/Linux applications. However, because it represents a remotely accessible channel to Bash, SSH represents a possible infection vector.

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. (Mac OS X uses a custom DHCP client that is not affected by this vulnerability.)

For mobile devices, Android devices do not use the Bash shell, and thus not affected by this threat. Neither do iOS devices. However, because jailbroken iOS devices include a copy of Bash, these devices are at risk. Similarly, rooted and modified devices that now run a *nix variant (and, as a result, Bash) may be affected.

Embedded devices/Internet of Things/Internet of Everything

Many embedded devices that make up the Internet of Everything are built on embedded versions of Linux, raising the risk that they could be compromised. This would allow the information in these devices to be stolen, as well as for the devices themselves to be used in various malicious activities by becoming part of a botnet.

However, not all of these devices use Bash. Many of these devices are built using BusyBox, which does not use Bash. These would  not be affected by this vulnerability either.

Diagnosing and patching IoE devices that are affected by Shellshock will pose exceptionally difficult, however. The standard tests that can be used to check if a system is vulnerable are harder to do on an embedded device. Similarly, the record of many IoE vendors when it comes to security patches is not ideal either. This area could represent a significant problem in the long-term mitigation of Shellshock.

Summary: IT administrators should worry the most, for now

For the time being, IT administrators maintaining servers that are exposed to the Internet should be the most concerned about this attack. As we mentioned in earlier blog posts, patches are now available from most vendors that should close this security hole.

We now provide free tools that allow IT administrators to check not only if their servers are vulnerable to Shellshock, but also if the attacks that are known to have taken advantage of it are already present in their systems.

Attempts to exploit the Shellshock vulnerability on a network can be detected via the following Deep Discovery rule:

  • 1618 – Shellshock HTTP REQUEST

Other Trend Micro products detect this as CVE-2014-6271-SHELLSHOCK_REQUEST.

In addition, Trend Micro Deep Security protects users from this bash vulnerability via the following DPI rule:

  • 1006256 – GNU Bash Remote Code Execution Vulnerability

Post from: Trendlabs Security Intelligence Blog – by Trend Micro

Shellshock – How Bad Can It Get?

Read more: Shellshock – How Bad Can It Get?

Story added 26. September 2014, content source with full text you can find at link above.