My buddy Aamir Lakhani posted about the recent Shellshock / Bash bug based on his research. Its a fantastic post and original is located HERE.
Security researcher, Stephane Schazelas found a major vulnerability that allows attackers to execute and run code in bash shell.
A shell is found on most UNIX, Linux, and Mac operating systems. Users interact it with it through the terminal program. It is the place to input and run commands for the operating system, as well as accept basic programming for the system. In other words, it is the command line. It is used for management, administrative, and productivity purposes.
Bash is the shell, or command language interpreter, for the GNU operating system. The name is an acronym for the ‘Bourne-Again SHell’, a pun on Stephen Bourne, the author of the direct ancestor of the current Unix shell sh, which appeared in the Seventh Edition Bell Labs Research version of Unix.
You can see from the Netcraft stat, Bash is one of the most widely installed tools on non-Windows systems. Remember over half the Internet’s web servers are running Apache, and the majority of Apache systems are running some sort of Unix or Linux operating system. Almost all of them have Bash.
A shell’s purpose in these systems is to execute commands. The vulnerability allows attackers to execute commands without the user’s consent. Attackers could possibly take advantage of this flaw on public web servers, DNS, NTP (time), and DHCP servers, by sending them commands that the servers would process on the backend by using bash.
How bad is this? Possibly DEFCON 1, Nuclear war is imminent. I don’t want to hype up the threat since the media is already doing a good job. In all seriousness it might be a little early to tell how serious this is. However, the potential of the seriousness could be really, really, bad.
What does this mean?
It means attackers could run code on your system without any authorization or authentication needed. Attackers may be able to execute this code on public web servers, DNS servers, systems with open management tools such as SSH or DHCP.
When attackers are able to run this code, they could possibly use that code to take over your systems to gain access to data, or harm other systems within or outside your organization, or use it as a launching point for more sophisticated attacks.
Web applications that use CGI-Scripts are processed thru bash, and do not require any authentication.
According to the NIST vulnerability database, which rates the flaw 10 out of 10 in terms of severity:
“GNU Bash through 4.3 processes trailing strings after function definitions in the values of environment variables, which allows remote attackers to execute arbitrary code via a crafted environment, as demonstrated by vectors involving the ForceCommand feature in OpenSSH sshd, the mod_cgi and mod_cgid modules in the Apache HTTP Server, scripts executed by unspecified DHCP clients, and other situations in which setting the environment occurs across a privilege boundary from Bash execution.
Authentication: Not required to exploit
Impact Type: Allows unauthorized disclosure of information; Allows unauthorized modification; Allows disruption of service”
According to Florian Weimer, on the OSS-Sec Mailing Post List:
- A typical HTTP request looks like this:
- GET /path?query-param-name=query-param-value HTTP/1.1
- Host: www.example.com
- Custom: custom-header-value
The CGI specification maps all parts to environment variables. With Apache httpd, the magic string “() {” can appear in these places:
- Host (“www.example.com”, as REMOTE_HOST)
- Header value (“custom-header-value”, as HTTP_CUSTOM in this example)
- Server protocol (“HTTP/1.1”, as SERVER_PROTOCOL)
The user name embedded in an Authorization header could be a vector as well, but the corresponding REMOTE_USER variable is only set if the user name corresponds to a known account according to the authentication configuration, and a configuration which accepts the magic string appears somewhat unlikely.
In addition, with other CGI implementations, the request method (“GET”), path (“/path”) and query string (“query-param-name=query-param-value”) may be vectors, and it is conceivable for “query-param-value” as well, and perhaps even “query-param-name”.
A 22-Year-Old Bug
The bug in the code appears to be 22 years old. That means, the vulnerability has been around a very long time. It would be foolish to think that attackers did not know about such a vulnerability and have not taken advantage of it.
In a blog post yesterday, Robert Graham of Errata Security noted that someone is already using a massive Internet scan to locate vulnerable servers for attack. In a brief scan, he found over 3,000 servers that were vulnerable “just on port 80″—the Internet Protocol port used for normal Web Hypertext Transfer Protocol (HTTP) requests.
Mitigation Techniques
According to the SANS Institute’s, Internet Storm Center You can test to see if you are vulnerable to the attack by logging on your system and trying the following commands in your shell:
- env x='() { :;}; echo vulnerable’ bash -c “echo this is a test”
- If the system is vulnerable, the output will be:
- vulnerable
- this is a test
- An unaffected (or patched) system will output:
- bash: warning: x: ignoring function definition attempt
- bash: error importing function definition for `x’
- this is a test
Mitigation Techniques
Akamai on their blog have explained the problem in detail and also using Web Application Firewall techniques may mitigate point out the problem.
There are a number of security scanners that are already available to scan for the vulnerability. We discussed the manual way to do it. The open source web application scanner w3af has built in plugins that will allow to scan your systems on scale. The process is described in detail here.
Obviously patching systems is key. However, at the time of writing the patches are not complete (this will probably be fixed in a few hours).
You could also use a different shell on your system. Although that may be a very difficult, if not impossible option for some people.
Sources:
