From ari.reen@nokia.com Fri Jun 22 08:49:52 2001
Date: Thu, 21 Jun 2001 09:18:14 +0300
From: ari.reen@nokia.com
To: project@honeynet.org
Cc: ari.reen@nokia.com
Subject: Scan of the Month #16 submission

Tervehdys

My entry for the Scan of the Month - June #16
Disclaimer: I speak only for myself not my employer.

73's de ari


Scan of the Month June 2001 (scan 16)
=====================================
Analysis by Ari Reen 21 Jun 2001

The task was to decrypt and analyze an encrypted file
somefile.tgz MD5 (somefile.tgz) = f7964d9860cbf8135ef64bcf5b96facb
found on compromised Solaris machine

1. 
The encryption method is XOR-stream encryption, with 
one byte key.

2. How to determine the encryption method
Since I have only very basic knowledge of cryptography
and analysis, I decided to check if the file was encrypted
using some of the traditional encryption methods like
the Caesar, some substition or transposition cipher.

I also checked the file size, to see it if the encryption 
method would be DES. The file size 532 bytes is not 
multiply of the DES block size (64bits). It could however be
DES used in some other way.
Another observation I made was that the file had the
high bit set on all bytes. So I dropped the pure
transposition ciphers off my list.

As a next step I started to browse the Internet to
find some toolkits to attack traditional ciphers.
I was looking for something that would allow me
to do frequency analysis, index of coincidence
and Kasiski test. Fortunately for me I first come
across a toolkit called 'xor-analyze'(1). Since
the high bits on all bytes could be a result of
xor-operation I started to experiment with the
xor-tools. 

3. The plain text file is here:
===
[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,s
n.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
===
To find the keylenght and actual key used: 
bash-2.04# ./xor-analyze -v -M 50 -a somefile freq/linux-2.2.14-int-m0.freq 
This command analyzed the somefile using the methods described in
the README file of the xor-analyze package.
Note that I had to patch the xor-analyze to allow non printable
characters in keys and also to write the key-candidates to 
a file. (trivial patches but if somebody is interested, contact me)

The output of xor-analyze suggested a key length of 24 bytes. The 
probable key was almost all 0xff-bytes. Using xor-dec 
with the key produced a plain text file with some 
'spelling errors'. Changing the key to be all 0xff bytes
fixed these errors.

4. Purpose of the file
I believe that the file is a configuration file (uconf.inv) for
a rootkit. It seems to define what information is not shown on 
the compromised system. The analysis of Adore toolkit 
for Linux (3) suggest the same and the uconf.inv (hex dump) is
encrypted using the same method and the syntax seems to
be the same as used in Adore.
The reason why it is encrypted is probably to hide
the rootkit installation directory and the behavior.

5. Lessons learned
- Simple solution seems to work sometimes.
- Personally learned a lot while trying to
  figure out the question 4 and the bonus question;
  I'm glad I'm not in charge of computer security :-)
  (except for my small home network).

6. How long
Hard to say exactly since this analysis was done
in many small sessions between the day job :-), 
totaling maybe less than 10 hours.
Calendar time used was about 2.5 weeks.

Bonus Question

I think this file is part of a rootkit mentioned in 
the CERT advisory CA-2001-05(2), because the 
similarities in the installed files and the contents
of the encrypted file. The time frame of the advisory and
the time when the target system was compromised also match.


References:
(1) http://www.securityfocus.com/tools/1316
(2) http://www.cert.org/advisories/CA-2001-05.html
(3) http://www.sans.org/y2k/the_compromise.htm

EOF.