Avoiding Shellshock: Assess Your Security Risk & Reduce Your Exposure

Tags:

Written by Melissa Stevens
Director of Digital Marketing & Demand

The security community is abuzz with the news of the latest vulnerability to sweep the internet. Early yesterday morning, details about the Bash security bug, also called Shellshock, started to emerge, putting companies on high alert about the threat experts are calling “Bigger than Heartbleed.”

To help provide some context about this story, I sat down with Bitsight Operations Engineer, Isaac Boehman, and Director of Operations, Kevin Amorin, to talk about Shellshock.

What exactly is Bash/Shellshock and why should companies be so concerned?

Shellshock is the name for a long-existing vulnerability in a tool called Bash that is installed on most non-windows systems (Linux, Unix, OS X). The reason there is so much concern about this bug is because it’s very easy to exploit and allows for arbitrary command execution. Many older web apps use a technology called CGI which when combined with Shellshock has created an extremely low effort exploit path for attackers.

As James Lyne points out in his article in Forbes, “... you use more Linux systems than you probably realise. In fact more web servers on the Internet run on this platform than anything else. You may not run a Linux system directly but your business likely does somewhere, or you use several with the myriad of services you interact with every day.”

There is now a race for companies to patch their vulnerable servers, and as we’ve seen with Heartbleed, we know there are a number of people who won’t do it and others who won’t get it done before they are targeted by an attacker.

What types of devices and machines are most vulnerable?

Web servers face the biggest risk from Shellshock. The target is huge and requires little technical skill to take over, so this has created an extremely dangerous situation. This exploit is easier to execute than Heartbleed, so the potential for damage is significantly greater.

At present, personal devices like smart phones and computers (which are not being used as servers) are not at great risk, but that doesn’t mean that there isn’t research underway to target these devices.

In addition to web servers, other attack risks can exist in these environments:

  • SSH - if the SSH user is limited to certain commands, this vulnerability can be exploited to run any command, not just the one the user is restricted to
  • dhclient - automatically retrieves network configuration via DHCP, uses environment variables and bash to configure a network interface. the client would need to connect to a malicious DHCP server to be exploited
  • CUPS - printer service, environment variables used to store values when cups filters (e.g. printer drivers, port monitors) get executed

What can companies to do to assess their security risk from Shellshock?

There are a number of ways that companies can check for vulnerabilities, but a simple way to test your systems is by running the following command on any server you want to check:

$ env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

If the server is vulnerable, you’ll see the output:

vulnerable
this is a test

Otherwise, you should see:

bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x'
this is a test

Are there measures that companies can take to protect themselves?

If you find that your systems are vulnerable, the quickest way to reduce your risk is to install the latest version of Bash from your vendor’s (i.e. Canonical for Ubuntu, Red Hat for Red Hat Enterprise Linux) software repositories with your distribution's package management tools (i.e. apt-get or yum).

Note: The current patches will help mitigate the brunt of the risk, however, they are known to be incomplete. CVE-2014-7169 exists to track this issue.

If you’re concerned that you may have already been exploited, you may want to engage in some forensics analysis or consult with professional incident response companies.

What should companies communicate to critical third parties in order to protect sensitive shared data?

Companies who share sensitive data with third party suppliers and vendors will want to make sure these parties are aware of these risks. Ensure that third parties are taking appropriate actions to identify vulnerabilities and remediate possible exploits and ask critical partners for evidence of updates.

Are there any sources you recommend for people looking for more information on Shellshock?

We’ve found that the below resources have offered some great information and analysis on this story.