From philippe.teuwen@philips.com Fri Jun 22 08:50:02 2001 Date: Thu, 21 Jun 2001 14:20:49 +0200 From: philippe.teuwen@philips.com To: project@honeynet.org Subject: SCAN OF THE MONTH #16: Answers Author: Philippe TEUWEN Subject: SCAN OF THE MONTH Answears # # SCAN OF THE MONTH #16: June, 2001 # # 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. # 2. How did you determine the encryption method? # 3. Decrypt the file, be sure to explain how you decrypted the file. # 4. Once decrypted, explain the purpose/function of the file and # why it was encrypted # 5. What lesson did you learn from this challenge? # 6. How long did this challenge take you? # # Bonus Question: # 7. This encryption method and file are part of a security toolkit. # Can you identify this toolkit? ANSWEARS: ========= 1. Identify the encryption algorithm used to encrypt the file. -------------------------------------------------------------- It's the simple XOR algorithm, a simple substitution cipher where each character is XORed with the corresponding char of the key. Moreover, the encryption is based on a key with a length of one. The key is the char 255, 0xFF. That means the encryption algorithm can be described even more simply as an INVERSION of the plaintext because the operation (x XOR 255) is identical to (~x) where ~ is the complement operator. THe original name of the file will confirm the fact, see later. 2. How did you determine the encryption method? ----------------------------------------------- Visually! I dumped the file with hexdump and saw directly two facts: * All the alphabet was limited between 0x80 and 0xFF, the "high" part of the ASCII. -> The plain text is a script file, typically in the 0x00-0x7F range and the encryption scheme matchs these 2 ranges by a way or another. That means we can see easily when we've the plaintext (easier than for a binary file!) * Some characters are redundant side by side (C9C9C9,...) -> The encryption is the same for each char, so if there is a key, it's a 1-char key. I first though it was just a shift of the alphabet, so I tried to remove 0x80 of the plain text, unsuccessfully. Then I though about a XOR encryption (for this precise case, the first try was just equivalent to a XOR 0x80) I wrote a little program to generate all the possible texts and concatenate them with sth like: for(i=128;i<255;i++) {plaintext = ciphtext XOR i} I tried only half of the keys because I was sure that the MSBit had to be XORed. Then I tried to read some plaintext in my output and found it easily. Rem: if the plaintext was a bin file, we could modify the program to pipe the results to the "file" function and check for sth meaningful. So the key is 255 and as said previously, XOR 128 is a shift operation in our case and XOR 255 is the one's complement operation. 3. Decrypt the file, be sure to explain how you decrypted the file. ------------------------------------------------------------------- You can run this program (with no extra checks!) >>>>>>>>>>> #include main() { int c; FILE* in; FILE* out; in=fopen("somefile","r"); out=fopen("result","w"); while((c=getc(in))!=EOF) putc(~c,out); // for each char, take the complement fclose(in); fclose(out); } <<<<<<<<<<< The plaintext is: >>>>>>>>>>> [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 --------------------------------------------------------------- Well, it's not exactly a script file, it looks more like a configuration file with some sections. Some of them seem to indicate a link between some very basic commands of UNIX with other binaries in a very strange directory: /dev/pts/01/bin It shouldn't exist at all! That means it's the config file of a toolkit, well hidden. When I say "well hidden", it seems to be VERY well hidden... The xxx_filters seem to indicate some keywords interesting to filter, I mean to hide. file_filters: some files to hide? 01 is the strange directory lblibps.so is a unknown library cleaner sounds like a script file, to remove the toolkit ?? dos under UNIX??, should mean "Denial of Service", sounds more hacker. ... ps_filters: some processus to hide? lp... want to hide the printer?? sshd2 well, a secured backdoor? sh1t, shit smells also like a hacker's tool lsof_filters: some files opened by processus to hide? :13000... also some ports to hide? uconf.inv interesting, sounds like CONFIGURATION and INVERSION maybe that's our file!! Now we understand better why the name was changed for the challenge. psniff we've also a sniffer and that's the log?? ... net_filters: some ports to hide One of them should be the backdoor with SSH And then a password that sounds really as the "gamer's elite jargon" l33t h4x0r, h4x0r means hacker but I can't figure out l33t. Why it was encrypted: The most obvious reason is the presence of the password but maybe there is a more subtil reason: it contains keywords to hide and it can be encrypted to avoid to be grabbed by a "grep" command or sth like that. 5. What lesson did you learn from this challenge? ------------------------------------------------- The thing I learned is that such toolkits exist!! and they seem to be very well designed. So this toolkit has the following properties (at least) - hides itself - SSH backdoor - logs local passwords - sniff the LAN for data (passwords?) - starting point for a DOS attack? - and of course root privileges for the attacker About the encryption itself, to be honest, nothing at all! 6. How long did this challenge take you? ---------------------------------------- To decrypt the file: 15 min To interpret: 30 min To browse the web for bonus: 2 h To write this email: 2 h --------- TOTAL: 4 h 45 7. This encryption method and file are part of a security toolkit. Can you identify this toolkit? ------------------------------------------------------------------ I didn't find this exact toolkit but I found some tookits very close: I tried www.alltheweb.com with "file_filters" & "lsof_filters" and the only page was very very interesting: http://www.sans.org/y2k/the_compromise.htm#uconv.inv It's the complete story of an attack and is really in the "honeypot project" spirit! Read it! There are some differences with our "rootkit": It was a Redhat 7, not a Solaris and some parts of the rootkit are different but our "uconf.inv" is there. The rootkit is called Adore and it's located in /lib/security/.config/ A remark: they didn't manage to decrypt the uconf.inv file ;-) Here is the description that is posted on Packetstorm: Adore is a linux LKM based rootkit. Features smart PROMISC flag hiding, persistant file and directory hiding (still hidden after reboot), process-hiding, netstat hiding, rootshell-backdoor, and an uninstall routine. Includes a userspace program to control everything. Changes: Improved promisc hiding, port hiding fixed, and a readme http://www.team-teso.net/ Well, it matches very well with the suggested properties of our rootkit. Another attack is described here: http://www.ciac.org/ciac/bulletins/l-065.shtml the rootkit is now in /dev/pts/01/ and under Solaris. We can learn there that "lpacct" is an IRC proxy listening port 6668. The puzzle is completing itself... We see also "lpset" is the sniffer. The site says the rootkit was installed via this vulnerability: CERT/CC Vulnerability Note VU#648304 Sun Solaris DMI to SNMP mapper daemon snmpXdmid contains buffer overflow http://www.kb.cert.org/vuls/id/648304 Another one: http://archives.neohapsis.com/archives/sf/sun/2001-q2/0088.html Same directory, same OS Interesting "strings ps" where we can found most of the uconf entries Declared as: This is: SunOS Rootkit v2.5 (C) 1997-2001 Tragedy/Dor If you find this file, most likely your host has been hacked by a user of this rootkit. If you want information about this tool, removal instructions or such, please email bert.smith@mbox.bol.bg The author takes NO RESPONSIBILITY for anyone who misuses this tool. This one looks really as our rootkit but I couldn't find it on the Net. Anyway I vote for this one! Phil