Skip to content ↓ | Skip to navigation ↓

Everyone keeps talking about how bad ShellShock is, and it may be worse than Heartbleed depending on whom you ask. Everyone keeps pointing out that the bug is contained within BASH, but that it’s a remote code execution vulnerability. We all know that BASH is a local CLI / scripting language within the *nix environment, so why are people calling this a remote?

The answer that is given is that multiple remote services are affected: Web Servers, SIP Servers and DHCP Clients just to name a few. This is possible because the data these services receive can be stored in BASH shell variables. Since the ShellShock payload is a function declaration and variables and functions are stored in the same fashion in BASH, these variables become functions.

This would be fine, except that a bug within BASH allows commands that are appended to the function declaration to execute when an environment is loaded. The services listed above all have situations where they can load a BASH environment, causing the vulnerability to be exploited.

The key thing to remember is that while the vulnerability is defined by the version of BASH installed, the attack vectors are not. So, while your system may be exploitable locally, that doesn’t mean it’s exploitable remotely. A great example of this is Apache with mod_cgi installed.

This setup alone does not provide an attack vector—as soon as you install a BASH CGI, the vulnerability is exposed. At this point, the vulnerability is only exposed via the specific CGIs that invoke BASH. If you have a Perl CGI, you aren’t exploitable. If you have a PHP page as your index, you aren’t exploitable. You’re only exploitable via requests for the BASH CGIs. This means that you can close the attack vector (remove the exploitable CGIs), even if your update cycle prevents you from updating BASH.

So, if you’re looking to identify vulnerable systems, the most accurate approach is clearly to test a system locally. If you don’t have local access, then testing remotely will yield positive results but you need to keep in mind the criteria for success:

  1. A vulnerable version of BASH installed.
  2. An installed BASH CGI
  3. The ability to send a request for the installed BASH CGI, which requires:
    1. Knowledge of the install path
    2. Access to the path

That introduces a number of points of failure for discovery of a vulnerable system, especially in an automated fashion. The first two points are universal, regardless of how you test the system, and in order to be vulnerable via HTTP, those two requirements must be met. The question, then, is can we reduce the likelihood of failure when testing a system?

The answer is yes. There are two ways that we can reduce the likelihood of failure. The first is to test a list of known BASH CGIs. This works well in cases where off-the-shelf apps are stored in expected paths. It doesn’t work as well with custom scripts or non-standard CGI paths.

The second approach is to spider the website and test every discovered page. This approach is very accurate but will miss scripts that aren’t linked within the website. The one upside to the missed CGIs is that security through obscurity is in play here and there’s a chance that an attackers tool won’t find them either. That’s a risk you shouldn’t have to take, so having a complete test plan is a better approach.

In the end, no method is 100% accurate when you’re talking about remote detection, unless you happen to know the URL of a BASH CGI and you include it in your tests. This works fine for one website, but what about one hundred websites or even one thousand?

You need to look at automation and you need to realize that no automation will be completely accurate. My recommendation will always be to spider a website and test all discovered pages… anything less is simply audit compliance.

Tripwire IP360 customers can run WebApp360 scans to accomplish this task. WebApp360 will spider your website and test all discovered pages to see if there are any potential attack vectors to exploit the Shellshock vulnerability. In addition, it will report all discovered pages, allowing you to mitigate the vulnerability temporarily while you wait for a viable patch window.