Scan 16 Results

The Challenge:
In March, 2001 a Solaris system was compromised. A collection of tools, utilities and files were uploaded onto the system by the blackhat. One of the files was encrypted. For this challenge, we have changed the name of the encrypted file to "somefile". You can download this file as somefile.zip, MD5 Checksum=eb7ed869ffcfe72d4b48caf57e648910, or somefile.tgz, MD5 Checksum=f7964d9860cbf8135ef64bcf5b96facb.

The first step is to download the file and confirm the MD5 Checksum, this validates the integrity of the file. Then the analysis can begin. wget(1) is a Unix utility that retrieves files from the World Wide Web.

$wget http://project.honeynet.org/scans/scan16/somefile.tgz
$md5 somfile.tgz
f7964d9860cbf8135ef64bcf5b96facb somefile.tgz
$tar -zxvf somefile.tgz
1. Identify the encryption algorithim used to encrypt the file.
2. How did you determine the encryption method?

We will go ahead and answer questions one and two together. We begin by analyzing somefile with the file(1) command, which determines that this file is a binary data file. So it cannot be analyzed using standard text based utilities, such as vi(1) or Notepad.exe. Instead, we have to use some viewer that takes the binary data and converts it to hexadecimal information. In this case, we select the handy utility xxd(1). This utility makes a hexadecimal dump of binary data, or does the reverse (its an extremely powerful utility). You can also use the hexdump(1) utility. In this case, we run xxd against our binary somefile for file analysis.

$file somefile
somefile: data
$xxd somefile
0000000: a499 9693 9aa2 f599 9691 9bc2 d09b 9a89 ................
0000010: d08f 8b8c d0cf ced0 9d96 91d0 9996 919b ................
0000020: f59b 8ac2 d09b 9a89 d08f 8b8c d0cf ced0 ................
0000030: 9d96 91d0 9b8a f593 8cc2 d09b 9a89 d08f ................
0000040: 8b8c d0cf ced0 9d96 91d0 938c f599 9693 ................
0000050: 9aa0 9996 938b 9a8d 8cc2 cfce d393 9d93 ................
0000060: 969d 8f8c d18c 90d3 8c91 d193 d38f 8d90 ................
0000070: 92d3 9c93 9a9e 919a 8dd3 9b90 8cd3 8a9c ................
0000080: 9091 99d1 9691 89d3 8f8c 9d91 9cd3 938f ................
0000090: 9e9c 9c8b d3aa acba adf5 f5a4 8f8c a2f5 ................
00000a0: 8f8c c2d0 9b9a 89d0 8f8b 8cd0 cfce d09d ................
00000b0: 9691 d08f 8c8d f58f 8ca0 9996 938b 9a8d ................
00000c0: 8cc2 938f 8ed3 938f 8c9c 979a 9bd3 8c97 ................
00000d0: ce8b d38f 8c8d d38c 8c97 9bcd d393 8f8c ................
00000e0: 9a8b d393 8f9e 9c9c 8bd3 9d91 9c93 8fd3 ................
00000f0: 938f 8c86 8cf5 938c 9099 a099 9693 8b9a ................
0000100: 8d8c c293 8fd3 8a9c 9091 99d1 9691 89d3 ................
0000110: 8f8c 9196 9999 d38f 8c8d d3c5 cecc cfcf ................
0000120: cfd3 c5cd cacf cfcf d3c5 c9c9 c9c7 d3c5 ................
0000130: c9c9 c9c8 d3d0 9b9a 89d0 8f8b 8cd0 cfce ................
0000140: d38c 91d1 93d3 8f8d 9092 d393 8c90 99d3 ................
0000150: 8f8c 9d91 9cf5 f5a4 919a 8b8c 8b9e 8ba2 ................
0000160: f591 9a8b 8c8b 9e8b c2d0 9b9a 89d0 8f8b ................
0000170: 8cd0 cfce d09d 9691 d091 9a8b 8c8b 9e8b ................
0000180: f591 9a8b a099 9693 8b9a 8d8c c2cb c8cf ................
0000190: cec7 d3c9 c9c9 c7f5 f5a4 9390 9896 91a2 ................
00001a0: f58c 8aa0 9390 9cc2 d09b 9a89 d08f 8b8c ................
00001b0: d0cf ced0 9d96 91d0 8c8a f58f 9691 98c2 ................
00001c0: d09b 9a89 d08f 8b8c d0cf ced0 9d96 91d0 ................
00001d0: 8f96 9198 f58f 9e8c 8c88 9bc2 d09b 9a89 ................
00001e0: d08f 8b8c d0cf ced0 9d96 91d0 8f9e 8c8c ................
00001f0: 889b f58c 979a 9393 c2d0 9d96 91d0 8c97 ................
0000200: f5f5 8c8a a08f 9e8c 8cc2 93cc cc8b 97cb ................
0000210: 87cf 8df5 ....
Above is the hexadecimal representation of the binary file. Reviewing the file shows a pattern, there are no ASCII values, everything is above decimal value 127. This is very odd, as almost any binary file should have some ASCII characters. Most likely there has been some type of character substitution or modification, indicating there is a pattern and we can potentially break the code. If this had been a strong encryption scheme, the characters would have been truly random.

When we analyzed this file, we had the advantage of knowing this was an ASCII configuration file for the universial rootkit. That means we knew the approximate format of the config file. The first character was most likely a '[' (0x5B), and the last was most likely a newline '\n'(0x0A). David Dittrich initially thought it was ROT13 or some Ceasar substitution cipher. Working off the two characters above, that proves impossible. Next on the 'easy to do' list is XOR.

3. Decrypt the file, be sure to explain how you decrypted the file.

The C code below contains the solution for decrypting the file. The code contains the line "printf("Mask: %02x\n", '['^0xA4);". This is because the first character in the encoded file is hex 0xA4, which we believed to be the '[' character. Due to the properites of XOR, if we XOR 0xA4 with '[', we will get the mask used, which was 0xFF. Now, the rest of the C code goes through and XORs every encoded character with 0xFF, resulting in the original file. To learn more about XOR, binary and Hexadecimal values we highly recommend this review of Assembler. 

#include <stdio.h>
char mychar,saved;

void main(void){

        printf("Mask: %02x\n", '['^0xa4);

        while(((int)mychar=fgetc(stdin))!=EOF){
                saved=mychar;
                mychar^=0xff;
                printf("%c",mychar);
        }
}
Once we developed the code to decrypt, we run it against the file. This is the output we get.
$./undo < somefile
Mask: ff

[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

4. Once decrypted, explain the purpose/function of the file and why it was encrypted.

This is a configuration file for a rootkit. This file determines what process, services, and files will be hidden from the system administrator. The computer is now configured to lie to the administrator. The purpose of encrypting the file is to make it more difficult for the rootkit to be detected, analyzed, and recovered from.

Bonus Question:
This encryption method and file are part of a security toolkit. Can you identify this toolkit?

This configuration file belongs to the Universal Rootkit, designed by K2. Side note. David Dittrich, rain forest puppy, and Marty Roesch worked on this together while at CanSecWest. Once they had completed the decode and full analysis of the rootkit, K2 coincidently showed up at the conference (and was immediately pummeled :)


The Honeynet Project