From mjl@emsi.priv.at Sun Jun 24 11:27:14 2001
Date: Fri, 22 Jun 2001 18:42:01 +0200
From: Martin J. Laubach <mjl@emsi.priv.at>
To: project@honeynet.org
Subject: Scan of the month
------------------------------------------------------------------------
| Startup
------------------------------------------------------------------------
Fetch and verify the file
% ftp http://project.honeynet.org/scans/scan16/somefile.tgz
% md5 somefile.tgz
MD5 (somefile.tgz) = f7964d9860cbf8135ef64bcf5b96facb
Matches the checksum on the web page, all is well.
Extract the file
% tar -xzvf somefile.tgz
somefile
------------------------------------------------------------------------
| Analysis
------------------------------------------------------------------------
% ls -l somefile
-rw-r----- 1 mjl users 532 Jun 4 12:15 somefile
Okay, we have a relatively small file. It's probably not an executable,
since they usually are a couple of magnitudes larger (not only on Solaris).
So let's peek at the file
% hexdump -C somefile
00000000 a4 99 96 93 9a a2 f5 99 96 91 9b c2 d0 9b 9a 89 |................|
00000010 d0 8f 8b 8c d0 cf ce d0 9d 96 91 d0 99 96 91 9b |................|
...
Not normal text, that much is sure. So it's encrypted some way or another.
On the other hand, it has lots of similar bytes in the range 0x80-0xa0, so
this smells like a caesar cypher. Also, since we know that (a) the purpose
of the cypher is to hide it's content from random passer-bys and not to make
it ultra-secure, and (b) we know the general lazyness of a typical programmer,
it is probably something of the sort char + offset or char xor offset, with
constant offset.
So let's whip up a small C program,
% cat >x.c <<EOF
#include <stdio.h>
int main(int argc, char **argv)
{
int off;
int i;
int ch;
off = atoi(argv[1]);
while((ch = getchar()) != EOF)
{
ch ^= off;
putchar(ch & 0xff);
}
}
EOF
% cc -o x x.c
and let's try whether we find something useful (after all, there's only
255 possibilities):
% cat >loop <<EOF
for i in `jot 255 0 255` ;
do
echo "-- $i --"
./x $i < somefile | hexdump -C | head -4
done
EOF
% /bin/sh loop
-- 0 --
00000000 a4 99 96 93 9a a2 f5 99 96 91 9b c2 d0 9b 9a 89 |................|
00000010 d0 8f 8b 8c d0 cf ce d0 9d 96 91 d0 99 96 91 9b |................|
[..snipped the uninteresting garbage..]
-- 255 --
00000000 5b 66 69 6c 65 5d 0a 66 69 6e 64 3d 2f 64 65 76 |[file].find=/dev|
00000010 2f 70 74 73 2f 30 31 2f 62 69 6e 2f 66 69 6e 64 |/pts/01/bin/find|
00000020 0a 64 75 3d 2f 64 65 76 2f 70 74 73 2f 30 31 2f |.du=/dev/pts/01/|
00000030 62 69 6e 2f 64 75 0a 6c 73 3d 2f 64 65 76 2f 70 |bin/du.ls=/dev/p|
Ah, bingo. So it's just xored with 255.
% ./x 255 < somefile > thisfile
% cat thisfile
[file]
find=/dev/pts/01/bin/find
du=/dev/pts/01/bin/du
ls=/dev/pts/01/bin/ls
file_filters=01,lblibps.so,sn.l,prom,cleaner,dos,uconf.inv,psbnc,lpacct,USER
[ps]
ps=/dev/pts/01/bin/psr
ps_filters=lpq,lpsched,sh1t,psr,sshd2,lpset,lpacct,bnclp,lpsys
lsof_filters=lp,uconf.inv,psniff,psr,:13000,:25000,:6668,:6667,/dev/pts/01,sn.l,prom,lsof,psbnc
[netstat]
netstat=/dev/pts/01/bin/netstat
net_filters=47018,6668
[login]
su_loc=/dev/pts/01/bin/su
ping=/dev/pts/01/bin/ping
passwd=/dev/pts/01/bin/passwd
shell=/bin/sh
su_pass=l33th4x0r
It quite obviously is a configuration file of some sorts. Since it contains
a password and lots of other tell-tale stuff, it's quite obvious it was encrypted
not to reveal those to some random observer.
Going to google and searching for "ps_filters" gave only a handful of hits,
and one of them (http://archives.neohapsis.com/archives/sf/sun/2001-q2/0088.html)
shows a similar config file. It also mentions a README file for a root kit,
so it's quite obvious that the machine was compromised, and a lot of system
binaries have been replaced (at least those mentioned in the config file
above). A full re-install of the machine is in order.
Time spent so far (including writing this wrap-up): 1:30. Decrypting the
file was done in about 15 minutes, but I was lucky I guess.