Everything you need to know about Bash Bug "ShellShock"

A new critical security vulnerability in the BASH shell, the command-line shell used in many Unix and Linux operating systems, leaves a large number of systems at security risk. The bug also affects Mac OS X.

CVE Number: CVE-2014-6271

Technical Details: 

Here is technical details of the vulnerability, posted by Florian Weimer in Seclists:

"Bash supports exporting not just shell variables, but also shell functions to other bash instances, via the process environment to (indirect) child processes.  Current bash versions use an environment variable named by the function name, and a function definition starting with “() {” in the variable value to propagate function definitions through the environment.

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.  For example, an environment variable setting of

  VAR=() { ignored; }; /bin/id

will execute /bin/id when the environment is imported into the bash process. (The process is in a slightly undefined state at this point. The PATH variable may not have been set up yet, and bash could crash after executing /bin/id, but the damage has already happened at this point.) "

Proof of Concept:

env e='() { Ignored; }; echo Vulnerable' bash -c "echo Hello"

Running the above command in Linux Terminal prints "vulnerable" and "Hello".So what exactly is happening here.

The 'env' command used to either print a list of environment variables or run another utility in an altered environment without having to modify the currently existing environment.

Here, the utility is 'bash' that executes the 'echo hello' command - and the environment variable 'e' is imported into the 'bash' process.

The bash shell process the function definition "() { Ignored; };"and then executes the "echo vulnerable" command.

* You can use the above POC code to test whether your system is vulnerable or not.

Real world Attack Scenario:

CGI stores the HTTP headers in environment variables. Let's say the example.com is running a CGI application written in Bash script.

We can modify the HTTP headers such that it will exploit the shellshock vulnerability in the target server and executes our code.

POC:

curl -k http://example.com/cgi-bin/test -H "User-Agent: () { :;}; echo Hacked > /tmp/Hacked.txt"

Here, the curl is sending request to the target website with the User-Agent containing the exploit code.  This code will create a file "Hacked.txt" in the "/tmp" directory of the server.

Who should be worried?
An attacker needs to send a malicious environment variable to an application that interacting with the Internet and this application should have either written in Bash or execute bash script within the app. So, Normal Desktop users are likely not affected by this bug.

However, if you are admin of a website and running CGI app written in BASH or using Bash script, You should be worried.

Metasploit Module:

A Metasploit Module has been released that exploits a code injection in specially crafted environment variables in Bash, specifically targeting Apache mod_cgi scripts through the HTTP_USER_AGENT variable.

You can find the module here.

Malware:
Cyber Criminals are already started to exploit this vulnerability for the malicious purpose.  A malware(ELF format) named as 'Linux/Bash0day', found by @yinettesys.

"Cybercriminals exploit bash 0day to get the ELF malware into web servers. ELF scans routers IP and sends exploit busybox to hack routers and doing DDoS." Malware Must Die who analyzed the malware told EHN.

"If exploit busybox hits the target, they will try to gain shell /bin/sh & brute the default login/passwords commonly used by routers"

Strings contained in the Malware sample

At the time of writing, the detection ratio in Virustotal is 0/55.

You can find the malware sample and more details of the malware at KernelMode website.

Wormable:
Robert Graham of Errata Security says the bug is wormable.  He wrote a script that scans the Internet and finds the vulnerable machines. So far, he found nearly 3,000 vulnerable systems on port 80.

"Consequently, even though my light scan found only 3000 results, this thing is clearly wormable, and can easily worm past firewalls and infect lots of systems." Graham wrote in his blog post.

DHCP RCE Proof of Concept:
https://www.trustedsec.com/september-2014/shellshock-dhcp-rce-proof-concept/


ModSecurity Rules:
RedHat has posted several mod_security rules that helps to prevent the attack:

Request Header values:

SecRule REQUEST_HEADERS "^\(\) {" "phase:1,deny,id:1000000,t:urlDecode,status:400,log,msg:'CVE-2014-6271 - Bash Attack'"

SERVER_PROTOCOL values:

SecRule REQUEST_LINE "\(\) {" "phase:1,deny,id:1000001,status:400,log,msg:'CVE-2014-6271 - Bash Attack'"

GET/POST names:

SecRule ARGS_NAMES "^\(\) {" "phase:2,deny,id:1000002,t:urlDecode,t:urlDecodeUni,status:400,log,msg:'CVE-2014-6271 - Bash Attack'"

GET/POST values:

SecRule ARGS "^\(\) {" "phase:2,deny,id:1000003,t:urlDecode,t:urlDecodeUni,status:400,log,msg:'CVE-2014-6271 - Bash Attack'"

File names for uploads:

SecRule  FILES_NAMES "^\(\) {"  "phase:2,deny,id:1000004,t:urlDecode,t:urlDecodeUni,status:400,log,msg:'CVE-2014-6271  - Bash Attack'" 

Patch:
A Patch has been released which ensures that no code is allowed after the end of a Bash function.  If you try to run the exploit code after applying the patch, you will get the following error message:

Unfortunately, the patch is incomplete, it still can be bypassed.  There is a workaround here, but it is not advisable. "CVE-2014-7169" has been assigned for the incomplete fix.

If you think we missed any information, feel free to comment here, we will add it to the article.

---------------------------------

Additional details:
This details isn't for you if you already know how export functions,'env' commands work :

Bash Export function-definition feature: 

Defining a function in Bash script:

       hello(){ echo "Hello World";}

Calling function in Bash script:
   hello

Create a child bash process and call our user-defined function:
bash -c hello

It won't work, because the child bash process doesn't aware that there is user-defined function called "hello". So, what to do?! Let us add the 'hello' function to the environment variable with Export command:

export -f hello

This will export the 'hello' function to the child process.  Let's try to create the child bash process again:

bash -c hello

Now the function is called without a problem.


We can achieve the samething in a single line with 'env' command. Let me first explain what 'env' command does.



'env':


The 'env' command used to either print a list of environment variables or run another utility in an altered environment without having to modify the currently existing environment.

Let's try to print environment variables with bash(creating child process):

bash -c printenv

The above command will print environment variables. Using 'env' command, you can pass a temporary environment variables to the child process:

env e="hello" bash -c printenv

Now, If you check the printed environment variables, you can find the "e='hello" in the result :)

Function passing with env command:

env hello='() { echo Hello World;};' bash -c hello