From bart.vanautgaerden@ubizen.com Sun Jun 24 11:27:08 2001 Date: Sat, 22 Jun 2002 16:28:14 +0200 From: barre To: project@honeynet.org Subject: Scan of the month Lance, Here is my "Scan of the month" writeup. Thanks for all the joy! ps: greetings to K2 (nice rootkit) Bart [ Part 2: "Attached Text" ] Write-up by Bart Vanautgaerden bart.vanautgaerden@ubizen.com 1. Identify the encryption algorithm used to encrypt the file -------------------------------------------------------------- Summary of the rootkit -------------------------------------------------------------- In the following steps, I will show how the file was "encrypted" (or more obfuscated) using an binary inversion of each character. The decryption resulted in a cleartext file, which was a configuration file for a rootkit. This rootkit, named URK or Universal RootKit (written by K2), used this file to hide certain processes and files from the legitimate user. The original filename was uconf.inv, and shows that it is the configuration file for the Universal Rootkit (Uconf) with extension .inv (invert binary). --------------------------------------------------------------- 1.Identify the encryption algorithm used to encrypt the file. --------------------------------------------------------------- All binary values of each character in the file where inverted. For example: The hexadecimal value of "A" is Ox41 The hexadecimal inverted value of 0x41 is 0xbe or "¾". When they are inverted, they look like non-printable values. This Perl program can be used to decrypt the file. ######################################################## decryption program ######################################################## #!/usr/bin/perl if(@ARGV < 2) { print " Program to invert bits in bin file\n Usage $0 \n"; exit; } my($binin,$binout)= @ARGV; # basic file checking open(binout, ">$binout") || die "Can't open outputfile: $!\n"; open(binin, "<$binin") || die "Can't open inputfile: $!\n"; @list = ; print binout ~"@list"; # invert the array and place it in binout close (binout); ###################################################### The main advantage of this rotation algorithm (similar to rot-13 or Caesar on a binary file) is that, if applied to an readable ASCII text, the are no printable characters shown in de encrypted file. This is also a weak point because it is very strange that a encrypted file doesn't show *any* printable characters , and only uses high binary values. An other disadvantage is that the encrypted file is still subject to frequency analysis of each character. --------------------------------------------------------------- 2. How did you determine the encryption method? --------------------------------------------------------------- I concluded a few things before I started the decryption. * The file couldn't be encrypted using a asymmetric algorithm. Certain patterns where found when the content was displayed using hexdump. A asymmetric file would show a lot more random values * Decrypting the file using brute force to find the private key for the symmetric algorithm (using a wordlist, all possible values, etc.) would take a long time. The problem had to be solvable anyway. Beside these conclusions, these investigations where also done. * The strings command output showed absolutely no result, which was odd. It would be very strange that by coincidence, no values where in the printable ASCII range. * A hexdump of this file showed that all values in the file where above a certain hexadecimal value. bash-2.05$ 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 |................| 00000020 f5 9b 8a c2 d0 9b 9a 89 d0 8f 8b 8c d0 cf ce d0 |................| 00000030 9d 96 91 d0 9b 8a f5 93 8c c2 d0 9b 9a 89 d0 8f |................| 00000040 8b 8c d0 cf ce d0 9d 96 91 d0 93 8c f5 99 96 93 |................| 00000050 9a a0 99 96 93 8b 9a 8d 8c c2 cf ce d3 93 9d 93 |................| 00000060 96 9d 8f 8c d1 8c 90 d3 8c 91 d1 93 d3 8f 8d 90 |................| 00000070 92 d3 9c 93 9a 9e 91 9a 8d d3 9b 90 8c d3 8a 9c |................| 00000080 90 91 99 d1 96 91 89 d3 8f 8c 9d 91 9c d3 93 8f |................| 00000090 9e 9c 9c 8b d3 aa ac ba ad f5 f5 a4 8f 8c a2 f5 |................| 000000a0 8f 8c c2 d0 9b 9a 89 d0 8f 8b 8c d0 cf ce d0 9d |................| 000000b0 96 91 d0 8f 8c 8d f5 8f 8c a0 99 96 93 8b 9a 8d |................| 000000c0 8c c2 93 8f 8e d3 93 8f 8c 9c 97 9a 9b d3 8c 97 |................| 000000d0 ce 8b d3 8f 8c 8d d3 8c 8c 97 9b cd d3 93 8f 8c |................| 000000e0 9a 8b d3 93 8f 9e 9c 9c 8b d3 9d 91 9c 93 8f d3 |................| 000000f0 93 8f 8c 86 8c f5 93 8c 90 99 a0 99 96 93 8b 9a |................| 00000100 8d 8c c2 93 8f d3 8a 9c 90 91 99 d1 96 91 89 d3 |................| 00000110 8f 8c 91 96 99 99 d3 8f 8c 8d d3 c5 ce cc cf cf |................| 00000120 cf d3 c5 cd ca cf cf cf d3 c5 c9 c9 c9 c7 d3 c5 |................| 00000130 c9 c9 c9 c8 d3 d0 9b 9a 89 d0 8f 8b 8c d0 cf ce |................| 00000140 d3 8c 91 d1 93 d3 8f 8d 90 92 d3 93 8c 90 99 d3 |................| 00000150 8f 8c 9d 91 9c f5 f5 a4 91 9a 8b 8c 8b 9e 8b a2 |................| 00000160 f5 91 9a 8b 8c 8b 9e 8b c2 d0 9b 9a 89 d0 8f 8b |................| 00000170 8c d0 cf ce d0 9d 96 91 d0 91 9a 8b 8c 8b 9e 8b |................| 00000180 f5 91 9a 8b a0 99 96 93 8b 9a 8d 8c c2 cb c8 cf |................| 00000190 ce c7 d3 c9 c9 c9 c7 f5 f5 a4 93 90 98 96 91 a2 |................| 000001a0 f5 8c 8a a0 93 90 9c c2 d0 9b 9a 89 d0 8f 8b 8c |................| 000001b0 d0 cf ce d0 9d 96 91 d0 8c 8a f5 8f 96 91 98 c2 |................| 000001c0 d0 9b 9a 89 d0 8f 8b 8c d0 cf ce d0 9d 96 91 d0 |................| 000001d0 8f 96 91 98 f5 8f 9e 8c 8c 88 9b c2 d0 9b 9a 89 |................| 000001e0 d0 8f 8b 8c d0 cf ce d0 9d 96 91 d0 8f 9e 8c 8c |................| 000001f0 88 9b f5 8c 97 9a 93 93 c2 d0 9d 96 91 d0 8c 97 |................| 00000200 f5 f5 8c 8a a0 8f 9e 8c 8c c2 93 cc cc 8b 97 cb |................| 00000210 87 cf 8d f5 |....| 00000214 In this table, it is clear that there are no printable values in it. There where certain values appearing a lot of times in this file. It was clear that some letter shifting was done. A college of mine pointed this out, and showed that using an XOR of all characters using the 0xFF value, the cleartext was revealed. This 0xFF value was chosen because it was our first and most obvious choice as being the highest possible value in hexadecimal. --------------------------------------------------------------- 3.Decrypt the file, be sure to explain how you decrypted the file. --------------------------------------------------------------- This program is C was our first attempt to decrypt the file. ############################################### #include main () { char c; while ( (c = (char)getchar() ) != EOF ) { c = c ^ 0xff; printf("%c",c); } } ############################################### This revealed the following cleartext file. [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 file looks like an configuration file of a program, more specific a rootkit. Multiple sections in the file show which files and processes to hide from the legitimized user. The configuration file also shows where to find the old non-compromised system files. When the system was compromised, the new binaries where placed in the PATH of the normal user. When such a program is executed, the compromised binary (like ls), will use the old binary but it is filtering out the files, processes and network-connections based on this configuration file. So what this rootkit needs are these main things: * Where to find the real programs? * What processes, files, network-connections to hide? * How to authenticate the normal-user from the rootkit-user. The configuration file is divided in these 5 sections: -- Section 1 In the section [file], all rootkit operations are listed that concerns files. In the first part, the real files are listed to be executed by the rootkit. For example the real find program can be found in the directory /dev/pts/01/bin/, but most probably the rootkit find is placed in /usr/bin. find = program to find files on the system, could find the rootkit files du = program to list directories and files, with there size. Could reveal the rootkit files. ls = program to list files and directories, same reason as above. file_filters= these are all the file to hide using the programs above. -- Section 2 In the section [ps], all the rootkit operations are listed that concerns processes. ps = the real location of the ps program ps_filters = procceses to hide. These also include programs like ssh (secure connection for our hacker to conncect to his hacked server), lsof_filters = hides files for the lsof operation. This command shows which files are used by which process or command (open files). It is nice for our hacker to hide for example the configuration file used by ls. -- Section 3 In the section [netstat], all rootkit operations are listed that concerns network connections. * netstat= The real location of our netstat program, shows up all networkconnections * net_filters= These port numbers of network connections will be hidden for our user. The attacker can use these ports to connect to our compromised system without revealing his real ip and connection. -- Section 4 In the [login] section, all programs are listed that give the attacker rootkit access to the system, instead of the compromised files. The su_pass is given as a argument with the execution of the program. Pretty clever, because in this way, no extra programs are needed to give the hacker total access. Otherwise you are stuck in a chicken - egg problem. How does the hacker gain access using a normal account with all compromised files? With this rootkit, certain ?jump? programs are used to give access beyond the rootkit. All four programs (ping, su , passwd, sh), could be used by the attacker to gain total access, and thus bypassing the rootkit. In this section, the real location of these programs are listed. -- Section 5 This section shows the password used to gain total access to the system, and bypassing the rootkit files. This password is given as a parameter to all programs in the [login] section. Note that in the original rootkit, the default password was set to h4x0r , so our attacker wasn't so carefully choosing his password. --------------------------------------------------------------- 5.What lesson did you learn from this challenge? --------------------------------------------------------------- Rootkits where a new object to me. This was a chance to view the internal structure of a rootkit and to see how it works in real life. And I also learned a lot of options with the hexdump program :-). --------------------------------------------------------------- 6.How long did this challenge take you? --------------------------------------------------------------- The hardest part was to find the encryption method used. It was indeed a weak encryption method used (or must I say a obfuscated), but if you don't have any clue, you are basically sitting pointless in front of a hexdump :-/. In total, it took me about 20 hours to find all the information that I needed. --------------------------------------------------------------- Bonus Question: This encryption method and file are part of a security toolkit. Can you identify this toolkit? --------------------------------------------------------------- The rootkit used was the Universal RootKit by K2, shortened URK. I found this using a lot of internet search-engines. As keywords, I used rootkit specific names like uconf.inv or su_pass. First I thought that it was Adore, because of an article at Sans: http://www.sans.org/y2k/the_compromise.htm This is however an other rootkit, using the same method to encrypt this file. In the original Adore package however, there is no sign of this encryption method. There is also a similar file in this rootkit (uconf.inv) using the same encryption. This rootkit was however for Solaris. So I continued my search and found this article: http://archives.neohapsis.com/archives/sf/sun/2001-q2/0088.html This was the rootkit that was involved in our investigations. After many downloads of different rootkit, a grep on su_pass revealed our URK rootkit by K2. This was obtained from his website www.ktwo.ca. Apparently, he is also member of the honeynet project. He shows up as a kernel weenie, and I think, he is one by looking at his multi OS rootkit. This is his method to encrypt the file. #include #include int main (int argc, char **argv) { int c; FILE *file1,*file2; /* simple error checking */ if(argc <= 1) { printf("Inverses the bit's in a file to make it unreadable.\n"); printf("inv [file1] [file2]\n"); return -1; } /* read and write a file in binary mode, if error then exit */ if (( file1 = fopen(argv[1],"rb")) == NULL ) { fprintf(stderr, "Cannot open input file: \"%s\".\n", argv[1]); return -2; } file2=fopen(argv[2],"wb"); /* while there is still input */ while((c = getc(file1)) != EOF) { c=~c; fputc(c,file2); } printf("File processed...\n"); /* close */ fclose(file1); fclose(file2); return 0; }