Scan of the Month - June 2001 ============================ 04 June 2001 By Alexander Reelsen, Introduction ============================ After reading about the scan of the month on the incidents list, I decided to give it a try this month, though I did not think I would be able to solve this myth. Anyway, I took a look at the file, downloaded the tar.gz and compared the md5sum to see if it matched. So I started digging around. Checking out the file ============================ Neither the information strings brings up, nor the information file delivers is any helpful as it is merely binary data: alex@joker:~/hacking_n_exploits/honeynet# file somefile somefile: Non-ISO extended-ASCII text, with very long lines, with no line terminators After catting the file it came to my mind, that a recently discovered incident had a similar file in length and a similar file when catting it as well as not bringing up any strings data. So I started digging around with perl in order to XOR it. This little one liner was able to do the job and revealed the following: alex@joker:~/hacking_n_exploits/honeynet# cat somefile | perl -ne '@a=split(//, > $_) ; foreach $f (@a) { print(chr((ord($f)^255))) }' [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 u_pass=l33th4x0r alex@joker:~/hacking_n_exploits/honeynet# Now the encryption algorithm is clear. It's a simple XOR using 255. I determined it more or less by accident, as I already knew it from hacks, I've had to analyze before. Analyzing the function of the file ============================ First we can say, this file is written in the style of the .ini files, like used by PHP (php.ini). The section (the part written in the brackets) always represents an application, which is commonly replaced by rootkits, like ps to hide processes, netstat to hide tcp/udp connections, login to sniff passwords and to have a "super" password, which gives instant UID 0 access and the file section is used in this case to hide files and to show the path to the real binary. This file is commonly used by the Adore rootkit, which is available for Linux (merely RedHat using several vulnerabilites like lpr) and Solaris (using vulnerabilites like the snmpXdmid hole). Every variable in the file, which contains "filters" is used to filter out these files, processes or network connections. Most of the other variables contain the paths to the real binaries as Adore uses those as backend and filters the files given in this configuration file. "su_pass" seems to be the password for the superuser instand UID 0 account I mentioned, which works for the hidden SSH daemon in most cases. Taking a closer look at the variables, it seems, that the hacker wants to hide an IRC session and his bouncer. The only reason to wonder is, why he apply this rule to the netstat filter only for port 6668 and not 6667. Furthermore the Adore rootkit/worm (what should resolve the bonus question for the security toolkit this file is used in) starts up a sniffer which cloaks itself as line printer stuff. Why was it encrypted? ============================ If you are not aware of the encryption routine, you are unable to get any useful information out of this file. Everytime a trojaned binary is called, it xor's this configfile to check what it has to do. This is a very tricky way to organise things, as this method does not burn CPU cycles and still offers a valuable luxury of hiding things in quite a dynamic way, what can be changed in runtime from one second to another. What did we learn? ============================ Well, hacking is not cleartext anymore. Things become more and more advanced and complex. People actually should get things right and update their software along with using security tools like LIDS and RSBAC (and whatever is out there for Solaris/BSD ;)) to minimize possible damage. Time spent into this analysis ============================ Due to the knowledge I had before I did not need that much time in order to analyze this one. Maximum 90 minutes including the report. However the forensic analysis of the compromised system where the Adore was found lasted about 2-3 days.