From bendi@redestb.es Fri Jun 22 08:50:26 2001 Date: Fri, 22 Jun 2001 15:01:22 +0200 From: Albert Bendicho To: project@honeynet.org Subject: Scan of the Month #16 Here's my contribution Albert Bendicho [ Part 2: "Attached Text" ] ANALYSIS FOR SCAN OF THE MONTH 15 By Albert Bendicho, May 2001 mail: bendi#at#redestb.es   1.Identify the encryption algorithm used to encrypt the file. 2.How did you determine the encryption method? 3.Decrypt the file, be sure to explain how you decrypted the file. Download the file, check its integrity and uncompress it [bendicho@localhost hn16]$ ../tct-1.06/bin/md5 somefile.tgz f7964d9860cbf8135ef64bcf5b96facb somefile.tgz [bendicho@localhost hn16]$ tar -xvzf somefile.tgz somefile   I take a look at the file with ghex and all I can't recognize anything on it (strings, common patterns). But I realize that it has quite a lot of characters repeated. So I check to see the entropy of the file. To do it I use "ent", an application that gives the entropy of a file with different methods. [bendicho@localhost hn16]$ ../ent/ent somefile Entropy = 4.788181 bits per byte. Optimum compression would reduce the size of this 532 byte file by 40 percent. Chi square distribution for 532 samples is 5787.16, and randomly would exceed this value 0.01 percent of the times. Arithmetic mean value of data bytes is 167.8759 (127.5 = random). Monte Carlo value for Pi is 2.772727273 (error 11.74 percent). Serial correlation coefficient is 0.135718 (totally uncorrelated = 0.0). I see that the "Entropy" value is 4.788181 bits of information per byte. Comparing with some binary files (for example; /bin/ls=6.35, /bin/cat=6.25), compressed files (somefile.tgz=7.39, somefile.zip=6.84, ssh-1.2.30.tar.gz>7.99) and some text files (../tct-1.06/MANIFEST=4.68, ../tct-1.06/README.FIRST=4.65) I can see that the entropy of the file is similar to the one used in text. That means that the encryption system used is quite weak. The next thing I do is trying to find the distribution of the characters that appear on the file, since from the visual inspection of the file (through ghex) I've seen quite a loot of repetition. To that purpose I write a simple perl script;   #!/usr/bin/perl -w for ($i=1;$i<=256;$i++) { $taula[$i]=0 }; while (defined($ch = getc(STDIN))) { $taula[ord($ch)+1]++; }; for ($i=1;$i<=256;$i++) { print $taula[$i]."\t"; if (($i % 8) eq 0) {print "\n"} }; print "\n";   and run it on the file.   [bendicho@localhost hn16]$ ./countcars.pl < somefile 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 2 11 7 28 52 11 1 34 10 29 2 28 0 0 24 6 3 14 24 18 12 14 9 0 6 0 4 0 4 0 0 0 0 0 1 0 1 1 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 14 0 0 4 0 3 2 9 1 2 3 2 13 18 45 5 0 30 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 22 0 0 0 0 0 0 0 0 0 0 I can see that the distribution doesn't look much random. I try it on other text files. For example   [bendicho@localhost hn16]$ ./countcars.pl < /etc/passwd 0 0 0 0 0 0 0 0 0 0 24 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 9 0 0 0 0 0 0 0 0 0 0 0 0 1 0 71 19 16 12 8 10 8 1 4 1 7 144 0 0 0 0 0 0 2 2 2 0 0 2 0 0 0 0 0 0 0 1 0 4 0 2 2 1 2 0 0 2 0 0 0 0 0 0 0 0 38 33 14 21 41 8 8 22 29 0 0 28 20 40 44 22 1 36 42 22 17 11 6 25 5 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 What catches my eye is that one output seems to be the mirror of the other, specially is interesting that ASCII value 0x0a (Line Feed) seems to appear too on the "mirrored" output of "somefile", just that instead of being on position 10 from the beginning is on position 10 from the end. Immediately I think that the encryption can be as simple as a substitution of each char for they "mirrored" equivalent. That's value 0 becomes represented for the value 255 and vice-versa. I write another perl script to try the theory;   #!/usr/bin/perl -w while (defined($ch = getc(STDIN))) { print chr(255-ord($ch)); }; And try it;   [bendicho@localhost hn16]$ ./inverse.pl < somefile [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 VOILA! We got our file! 4.Once decrypted, explain the purpose/function of the file and why it was encrypted It seems to be a configuration file for a rootkit. In it stores all that's needed to be hidden from the system. On the [file] section we see the 3 processes that it hacks (find, du and ls), a location where the original files or perhaps the trojaned ones reside, and finally the filenames it has to hide to these 3 processes. On the [ps] section it does the same, substituting ps and configuring which processes/open files have to be hidden to ps and lsof. I wonder why there's no entry like "lsof=/dev/pts/01/bin/lsof" or similar. On the [netstat] section the netstat process is trojaned and any connection to ports 47018 and 6668 are hidden. On the [login] section we see references to changes on su, ping, passwd and sh. One that's special is su, since instead of a line like "su=/dev/pts/01/bin/su" there's a line starting with "su_loc". Finally we find a parameter su_pass with an unencrypted password. The reason for the encryption is to make the life of anyone trying to find out what's going on on the system harder. If it's shown in clear text it will be easy to track all the substituted processes, changes of configuration and the like. On the other hand if someone doesn't see it it can fail on trying to patch all the holes. Last, but not least, it contains a password. 5.What lesson did you learn from this challenge? Things don't have to be as they seem. At the beginning I thought I was going to face a serious encryption problem and that was going to take me a long time, but it has been really fast. As the "logo" for TCT (http://www.fish.com/tct/FAQ.html#pipe) says "Ceci n'es pas une pipe". 6.How long did this challenge take you? Around 30 minutes from download to unencryption including time to develop the two perl hacks (hey! It's not my strong point and I'm learning) Trying to find to what rootkit this file could belong... Hours!!! I'm learning about security, and trying to find answers to this question has taken me to several interesting sites where I've learned more. Bonus Question: This encryption method and file are part of a security toolkit. Can you identify this toolkit? So far, for my search around the web I'd say that it's part of "X-Org SunOS Rootkit v2.5" http://www.up.univ-mrs.fr/wcri/d_serv/d_reseau/d_cert/certmsgSTAT017 but so far I haven't been able to find the rootkit itself to confirm. In fact the file was probably named "uconf.inv", since it's part of this rootkit and appears on the "file_filters" and "lsof_filters" sections of the file. Looking for "uconf.inv" reveals more links related to files like the one we have decrypted and "X-Org SunOS Rootkit". Looking for other SunOS Rootkits I've found "rootkitSunOS.tgz" that includes a file named "code.h" that has the following contents;   int code(a) char *a; { while(*a !='\0') { *a = ~(*a); a++; } return(1); }   That's performs exactly the same "encryption" we're facing. So perhaps the "bright idea" of the encryption for the "X-Org" rootkit configuration file is inherited from this other rootkit. Albert Bendicho