detecting Solaris tojans with Argus
Peter Van Epp
vanepp at sfu.ca
Thu Jan 6 12:22:00 EST 2000
Below the alert from the SANS folks about the Solaris trojans is a
perl script that will select echo responses (with no corresponding echo
requests) from an Argus log. I grabbed a copy of the gag detection program and
ran it from outside my net then looked at the Argus log to see how it appeared.
At first glance (which may be incorrect!) it appears a normal ping/ping response
pair creates a flow and gets logged as an ECO:
Thu 01/06 08:04:48 142.58.xxx.xx <-> 24.113.yy.y ECO
a scan for the tojans shows as an ECR (i.e. an echo reply with no corresponding
request):
First the gag scan:
Wed 01/05 08:24:29 142.58.xxx.1 <- yyy.yyy.29.251 ECR
Wed 01/05 08:24:29 142.58.xxx.2 <- yyy.yyy.29.251 ECR
Wed 01/05 08:24:29 142.58.xxx.3 <- yyy.yyy.29.251 ECR
... (the rest of the class C)
and then some live data:
Wed 01/05 19:37:58 63.225.200.195 -> 142.58.xxx.xxx ECR
Wed 01/05 20:17:00 212.105.12.13 -> 142.58.xxx.xxx ECR
Thu 01/06 01:06:00 206.184.139.153 -> 142.58.xxx.xxx ECR
While I haven't particularly seen any yet, I expect to start seeing
other people using gag to scan our net for trojaned machines. There are a
variety of machines (a large variety!) scanning a cluster of Suns and SGIs
in one of our departments with ECR packets (I'm in the process of grabbing
a full capture of the packets to see what the data looks like) but they don't
appear to be getting any response nor are there any apparant attacks being
generated from the machines in question but they have been scanning them
every day multiple times per day for months. I see no indication of any attack
originating from the machines however nor any responses going back from the
probes, but there is obviously something going on. The admin for the machines
in question has been contacted and will be checking the machines for problems.
While there is no documentation (other than the source), the perl
script outputs basically 3 tables: only echo responses sorted by destination
machine (which shows all IPs attacking a single machine), then echo responses
sorted by source machine (shows how many machines each attacking IP is
targetting) and then all the icmp echo data sorted by destination machine to
allow finding things like an echo request to the network address (i.e.
142.58.0.0) which causes ECR responses from multiple machines on the net (and
the first time I saw it, looked like an attack from our machines before I found
the corresponding echo request). I tend to run it like this:
ra -r argus.log -c -n icmp | sicken.pl >t
althought the icmp is optional since the script will select out only the icmp
records from the log (as I believe should be the -c -n, I believe the script
compensates for the lack of count output). If not you have the source :-)
I assume the SANS folks would appreciate hearing about any results
you find as well.
Peter Van Epp / Operations and Technical Support
Simon Fraser University, Burnaby, B.C. Canada
>
> SANS Flash Alert for Solaris Users
>
> Help, please - today -- in the Hunt For Solaris Trojans
>
> THE PROBLEM
>
> Several of you have reported that your Sun computers have been
> infected with Trojan horse software (trojans, for short) using such
> tools as trinoo, TFN, TFN2000, or stacheldraht which is German
> for barbed wire.
>
> Here is what we know so far about these attacks from users and
> experts around the world:
>
> These trojans are controlled by master computers using various
> communications channels. The infected machines are used as a
> collective force (reports range upward from 230 acting together) to
> attack other sites and close them down. These attacks have
> succeeded in flooding out both large and small sites.
>
> The trojans are being installed continuously - with attackers
> coming back time and again looking for new computers to
> compromise. Several universities found them installed on multiple
> computers. Attackers appear to have constructed relatively
> complete maps of the computers at the sites they are attacking.
>
> If your Solaris computers are infected and are used in attacks on
> other organizations, you may face economic liability or be viewed
> as a pariah to the community.
>
>
> DETECTION
>
> You and the community would greatly benefit if you could check
> to see whether your computers are infected. Two principal tools
> are available for the test. One was developed by the National
> Infrastructure Protection Center (NIPC) and can be installed on
> each host. The other is being developed by Dave Dittrich and Marcus
> Ranum and can be run remotely to scan your systems. There is no
> charge for either of the tools.
>
> Over the weekend the GIAC (Global Incident Analysis Center) at
> www.sans.org/y2k.htm put out an early notice and several dozen
> organizations tested the NIPC software and provided feedback that
> helped make it work better. Yes, the NIPC software has uncovered
> more infestations.
>
> The NIPC software works well and should be run immediately.
>
> As wonderful as the news is about the NIPC tool, to run it you
> have to install it on every system you want to test. A network
> scanning tool is potentially more efficient since one tool can scan
> an entire network. Just make certain the network you scan is yours
> and that you have permission! One such tool is under
> development, it was written by Dave Dittrich, and Marcus Ranum
> has enhanced it. In other words: extraordinary people are working
> together to create the tools needed to find these Trojans.
>
> If you have a lot of experience with software that is still a bit
> green, you could really make a contribution to the community by
> running and testing the scanning program.
>
> If you are less experienced you might want to delay a day or two.
> But don't delay long, the tool may have a short life span, as the
> attackers will begin to modify the trojan code to evade detection.
>
> Where to find the software:
>
> The host-based tool from NIPC may be found at:
> http://www.fbi.gov/nipc/trinoo.htm
>
> The scanning program from Dittrich/Ranum may be found (after 6
> pm EST on January 4) at:
> http://staff.washington.edu/dittrich/misc/sickenscan.tar
>
> In addition, Dave Dittrich has written an extraordinary analysis of
> the infestation that may be found at:
> http://staff.washington.edu/dittrich/misc/stacheldraht.analysis
>
> If you are a university or any other organization with users who
> may not have tightly locked down their Solaris systems, please use
> both. If you are absolutely sure of your defenses, you might do
> spot checks instead.
>
> CONTAINMENT AND ERADICATION
>
> If you find evidence of infestation, please make a good back-up
> first to preserve evidence. Also if you search for the malicious
> code on your system, you probably will not find it. The attackers
> have been installing "root kits" to hide their work.
>
> There are resources available to help if you have been attacked.
> Please mail us at sansro at sans.org and we'll connect you with the
> best sources available at that time.
>
>
> PREVENTION
>
> The most common paths used to compromise systems to insert the
> Trojans have been weaknesses in RPC (remote procedure call)
> implementation.
>
> The menacing character of this new threat may offer you an
> opportunity to get support to patch the RPC holes and eliminate
> other vulnerabilities.
>
> Note, though Solaris is the current focus of these attackers, they
> will soon turn to NT and Linux and other UNIX variants. Take
> this opportunity to close the holes there as well. That's a great deal
> cheaper and less embarrassing than nuking the system and
> reinstalling all the software after an infestation.
>
> IN CLOSING
>
> If you can spare the time, please take a look right away. The
> Trojans are under constant development and these detection tools
> may be less and less effective as the week progresses.
>
> Email us with the results at sansro at sans.org
>
> Alan and Greg
>
> Greg Shipley
> Solaris Trojan Hunt Coordinator
>
> Alan Paller
> Director of Research
>
> The SANS Institute
>
>
>
>
sicken.pl:
---- cut here ----
#!/usr/local/bin/perl
open(STDIN,$ARGV[0]) || die "Can't open $ARGV[0]: $!\n"
if $ARGV[0];
$line = 0;
$start_time = "";
$end_time = "";
while (<STDIN>) {
$line ++;
if (($line % 10000) == 0) {
print STDERR "Processing $line\n";
}
chop;
$src_bytes = " ";
$dest_bytes = " ";
$source_net ="";
$dest_net ="";
$src_port = " ";
$dst_port = " ";
($date, $flag, $rest) = unpack("A18 A5 A200",$_);
if ($start_time eq "") {
$start_time = $date;
}
($type, $rest) = split(' ',$rest,2);
if ($type eq "man") {
$mid_flag = ' ';
($source_ip, $dest_ip, $src_pkt, $dest_pkt, $src_bytes,
$dest_bytes, $end_flag) = split(' ',$rest,7);
} elsif ($type eq "icmp") {
($source_ip, $mid_flag, $dest_ip, $src_pkt, $dest_pkt,
$end_flag) = split(' ',$rest,6);
if ($end_flag =~ /port/) {
($t, $p, $dst_port, $rest) = split(' ',$end_flag);
}
} else {
($source_ip, $mid_flag, $dest_ip, $src_pkt, $dest_pkt,
$src_bytes, $dest_bytes, $end_flag) = split(' ',$rest,8);
($a,$b,$c,$d,$src_port)= split(/\./,$source_ip);
$source_ip = "$a.$b.$c.$d";
$source_net = "$a.$b.$c";
($a,$b,$c,$d,$dst_port)= split(/\./,$dest_ip);
$dest_ip = "$a.$b.$c.$d";
$dest_net = "$a.$b.$c";
}
if ($type eq "icmp") {
if ($end_flag eq "ECO" || $end_flag eq "ECR") {
$all_data{"$dest_ip"} .= "$date $source_ip $mid_flag $dest_ip $end_flag\n";
}
if ($end_flag eq "ECR") {
$ecr_src_data{"$source_ip"} .= "$date $source_ip $mid_flag $dest_ip $end_flag\n";
$ecr_dest_data{"$dest_ip"} .= "$date $source_ip $mid_flag $dest_ip $end_flag\n";
}
}
}
$end_time = $date;
print "Only echo response data sorted by destination machine\n\n";
foreach $source (sort (keys %ecr_dest_data)) {
print "$ecr_dest_data{$source}\n";
}
print "\nOnly echo response data sorted by source machine\n\n";
foreach $source (sort (keys %ecr_src_data)) {
print "$ecr_src_data{$source}\n";
}
print "\nAll echo data\n\n";
foreach $source (sort (keys %all_data)) {
print "$all_data{$source}\n";
}
More information about the argus
mailing list