Unix: The aftershock of shellshock

Most versions of Linux and Unix, even Mac OS X, have been found to be affected by a very serious flaw in the Bourne Again Shell, generally known as bash. Remote code execution could have become a serious problem for so many of us — and a convenient “hole” for the hacker community — had the problem been exploited all these years. And, frankly, who is to say that it hasn’t? The indications from the field seem to be that hackers are only getting active now and that some fixes may not be effective as initially believed.

While the vendors have been quick to address the problem once it was brought to our

attention, the fact that it existed for more than two decades is seriously unsettling.

The gist of the problem seems to be that malicious code can be tacked onto an environment variable and, from there, have many serious consequences.

Symantec has listed the following exploits (see http://www.symantec.com/en/uk/outbreak/?id=shellshock):

1. Simple “vulnerability checks” that used custom User-Agents

2. Bots using the shellshock vulnerability

3. Vulnerability checks using multiple headers

4. Using Multiple headers to install perl reverse shell ( example: shell connects to 46.246.34.82 port 1992)

5. Using User-Agent to report system parameters back

6. User-Agent used to install perl box

Most Unix providers have already addressed the problem with patches. These include RedHat, Debian, Ubuntu, CentOS, Novell/SUSE, and Apple. Maybe others as well.

One simple test for vulnerability is shown below. I put this command into a script to make it easier to ship around a network. If this script comes back and reports that you’re vulnerable, you should go after your OS vendor to fix your systems ASAP. Most likely, you will simply have to grab the newest patch for bash. It should be a quick fix.

#!/bin/bash

env x='() { :;}; echo Server is vulnerable' bash -c "echo"

The emergence of shellshock calls into question how effectively the tools we depend on are tested. How much can we really test when we don’t know what we’re looking for? Even those of us set up with sophisticated vulnerability scanners can’t detect what the scanners don’t anticipate finding.

Of course, while the fact that this bug went unnoticed for more than twenty years is unsettling, it doesn’t mean the core of any Unix implementation is ripe with bugs. It just means that the testing isn’t as thorough as we’d like to believe. And maybe this discovery, as much as it has shaken us up, will also usher in an era of even more rigorous testing in the design and development phases of the products we all use — maybe even those that have been around for decades.

flickr / Pascal

https://creativecommons.org/licenses/by/2.0/