From guido@madison-gurkha.com Fri Jun 22 08:44:09 2001 Date: Fri, 8 Jun 2001 14:04:16 +0200 From: Guido van Rooij To: project@honeynet.org Subject: Scan of the month This challenge was done by: Guido van Rooij Arjan de Vet 1. The encryption algorithm (is this deflation of the word encryption?) is "xor with 0xff". 2. The contents of the file were all bytes with the high order bit set. So we cleared the high bit and looked at the content. The output was rather regular (e.g. the string "^O^K^LPONP^]^V^Q" appeared multiple times). That was a clue that something simple was used. A printout of the frequencies of all the bytes in the file gave: 0x86: 1 0x87: 1 0x88: 2 0x89: 11 0x8a: 7 0x8b: 28 0x8c: 52 0x8d: 11 0x8e: 1 0x8f: 34 0x90: 10 0x91: 29 0x92: 2 0x93: 28 0x96: 24 0x97: 6 0x98: 3 0x99: 14 0x9a: 24 0x9b: 18 0x9c: 12 0x9d: 14 0x9e: 9 0xa0: 6 0xa2: 4 0xa4: 4 0xaa: 1 0xac: 1 0xad: 1 0xba: 1 0xc2: 14 0xc5: 4 0xc7: 3 0xc8: 2 0xc9: 9 0xca: 1 0xcb: 2 0xcc: 3 0xcd: 2 0xce: 13 0xcf: 18 0xd0: 45 0xd1: 5 0xd3: 30 0xf5: 22 So not very equally distributed. That lead to the observation that it might well be that a simple substitution cipher was used. The first thing that came to our mind was that xoring with some byte was used (some byte > 0x7f because the high order bit should be cleared to get to normal ascii byte ranges) One thing lead to another and we derived it was xored with 0xff. 3. In this case encrypt uses the same method as decrypt. The contents are: [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. It is the configuration of a rootkit. Each section is meant for the program(s) that are somehow related to the sections name. The program sections which inormation is to be withheld from the person running that program. E.g. netstat will hide inormation regarding ports 47018 and 6668. Furthermore, a magic password is specified that will, without doubt, give root access via login and via su. The reason it was encrypted is to make it harder for the administrator to detect the rootkit. I am sure that the file itself was also hidden when ls or something like that was used. However, if the administrator somehow managed to find the configuration file after all, he still would not immediately detect what was going on. 5. The lesson learnt was one that I already knew: Use decent crypto ;-) 6. The answering took longer than the decryption ;-). Total was 1 hour. Bonus Question: The rootkit used was: SunOS Rootkit v2.5 (C) 1997-2001 Tragedy/Dor We derived this by looking for the string su_pass on Google. The following link appeared in the result: http://archives.neohapsis.com/archives/sf/sun/2001-q2/0088.html Reading this page indeed points toward a rootkit using the above decrypted file as its configuration. Note that on the following Sans page, the author got wrong where iconf.inv was coming from: http://www.sans.org/y2k/the_compromise.htm