From marco.foglia@psi.ch Fri Jun 22 08:48:47 2001 Date: Tue, 19 Jun 2001 00:39:35 +0200 From: Marco Foglia To: project@honeynet.org Subject: Submission: Scan of the Month - June Scan of the Month - June - Decrypt and analyze an encrypted file found on a compromised system. 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". Your missions is as follows: ###################################################################### 1.Identify the encryption algorithm used to encrypt the file. The file was encrypted by bitwise inverting all characters and can be decrypted by doing it again. Decryption of the first 7 bytes of "somefile": (encrypted char) => ~(encrypted char) = decrypted char 0xa4 = 10100100 => 01011011 = 0x5b = [ 0x99 = 10011001 => 01100110 = 0x66 = f 0x96 = 10010110 => 01101001 = 0x69 = i 0x93 = 10010011 => 01101100 = 0x6c = l 0x9a = 10011010 => 01100101 = 0x65 = e 0xa2 = 10100010 => 01011101 = 0x5d = ] 0xf5 = 11110101 => 00001010 = 0x0a = linefeed ###################################################################### 2.How did you determine the encryption method? - I calculated the probability of every character of "somefile". | char | nr | probability || char | nr | probability | | code | | || code | | | |----------------------------------------------------| | ad | 1 | 0.19 || | | | | 87 | 1 | 0.19 || c9 | 9 | 1.69 | | ca | 1 | 0.19 || 9e | 9 | 1.69 | | ac | 1 | 0.19 || 90 | 10 | 1.88 | | 86 | 1 | 0.19 || 89 | 11 | 2.07 | | 8e | 1 | 0.19 || 8d | 11 | 2.07 | | aa | 1 | 0.19 || 9c | 12 | 2.26 | | ba | 1 | 0.19 || ce | 13 | 2.44 | | cb | 2 | 0.38 || 9d | 14 | 2.63 | | cd | 2 | 0.38 || 99 | 14 | 2.63 | | 92 | 2 | 0.38 || c2 | 14 | 2.63 | | 88 | 2 | 0.38 || cf | 18 | 3.38 | | c8 | 2 | 0.38 || 9b | 18 | 3.38 | | c7 | 3 | 0.56 || f5 | 22 | 4.14 | | 98 | 3 | 0.56 || 9a | 24 | 4.51 | | cc | 3 | 0.56 || 96 | 24 | 4.51 | | c5 | 4 | 0.75 || 93 | 28 | 5.26 | | a4 | 4 | 0.75 || 8b | 28 | 5.26 | | a2 | 4 | 0.75 || 91 | 29 | 5.45 | | d1 | 5 | 0.94 || d3 | 30 | 5.64 | | 97 | 6 | 1.13 || 8f | 34 | 6.39 | | a0 | 6 | 1.13 || d0 | 45 | 8.46 | | 8a | 7 | 1.32 || 8c | 52 | 9.77 | ----------------------------------------------------- A uniform character distribution is an indication of a "real" encryption algorithm. This is not the case. So we could have some kind of direct mapping between the encrypted and the original charset, something like the rot13 algorithm. - I tried the character mapping: decrypted = (encrypted + offset) % 256, 0<=offset<=255 => nothing useful found - I tried the character mapping: decrypted = (offset - encrypted) % 256, 0<=offset<=255 With offset = 255 the decrypted output of "somefile" makes sense. This is the solution! So the rule to convert "somefile" to clear text is decrypted = 255 - encrypted This is nothing else than just bitwise inverting the encrypted character: decrypted = ~encrypted ###################################################################### 3.Decrypt the file, be sure to explain how you decrypted the file. A very simple perl script can do the decryption job: --- BEGIN decrypt.pl --- #!/usr/bin/perl open(FH, "somefile"); while ($char = getc(FH)) { printf("%s", ~$char); } close(FH); --- END decrypt.pl --- The decrypted file: --- BEGIN somefile.decrypted --- [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 --- END somefile.decrypted --- ###################################################################### 4.Once decrypted, explain the purpose/function of the file and why it was encrypted "somefile" is the configuration file of several trojaned system binaries. The original binaries were replaced by a wrapper program after moving them to the directory /dev/pts/01/bin. Some configuration entries (find,du,ls,ps,netstat,su_loc,ping,passwd) tell the wrapper where to look for the original binary. The other configuration entries of "somefile" define the backdoor password and what should be hidden: file_filters filenames to filter from find/du/ls output ps_filters process names to filter from ps output lsof_filters stuff to filter from lsof output net_filters ports to filter from netstat output shell shell to use for su/ping/passwd backdoor su_pass backdoor password of su/ping/passwd The file was encrypted to pass as a normal binary file and not as a configuration file of a rootkit and to make it more difficult to analyze. ###################################################################### 5.What lesson did you learn from this challenge? Try the simple stuff first! At first I was thinking of a more sophisticated encryption method. ###################################################################### 6.How long did this challenge take you? It took me approx. 1 hour to find the encryption method and 2 hours to write this report and to do some web research. ###################################################################### 7. This encryption method and file are part of a security toolkit. Can you identify this toolkit? This encryption method is used by the Universal Root Kit, version >= 0.9.2 [1]. Despite the fact that the name of the configuration file of the URK rootkit is "urk.conf" i think the original filename of "somefile" on the compromised solaris system is "uconv.inf" as you can read in [2]. ###################################################################### References: Universal Root Kit: [1] http://www.ktwo.ca/c/urk-dist-0.9.8.tar.gz [2] http://groups.google.com/groups?q=SunOS+Rootkit+v2.5 Reports in connection with uconv.inf: [3] http://archives.neohapsis.com/archives/sf/sun/2001-q2/0088.html [4] http://www.tek-tips.com/gpviewthread.cfm/lev2/3/lev3/20/pid/60/qid/75974