Notes on a Solaris Rootkit
Bruce Ediger
manage got cracked, and a rootkit installed. This is the story of
my crack recovery.
I had 2 Solaris 2.7 machines, nearly identically set up. One of
these machines got cracked, I believe because the 2nd box was behind
a firewall that only let in HTTP, Telnet, FTP and a couple of
non-standard TCP ports for an application.
I suspect that the machine outside the firewall got cracked via
some exploit that the firewall blocked. I think that the crackers
got in one of 5 ways:
1. in.fingerd - /sbin/in.fingerd got set to zero length.
fingerd has been at the root of many a crack, going back to
before the '88 Internet Worm.
2. snmpXdmid - it got set to 1 byte with 000 permissions
See http://www.cert.org/advisories/CA-2001-05.html
3. /usr/lib/nfs/statd - the rootkit removed it for some reason. NFS statd
has been the cause of many cracks over the years, too.
4. /usr/dt/bin/rpc.cmsd - also removed for some reason.
5. The sadmind exploit that the last Solaris worm used. See
http://www.cert.org/advisories/CA-1999-16.html The rootkit
edits /etc/inetd.conf so that sadmind no longer appears.
I'm leaning toward snmpXdmid or sadmind, but I have no real reason
to believe this. I vaguely remember deleting a core file in /,
which is symptomatic of both of these cracks.
One distant possiblity for the crack is /usr/openwin/bin/gxfres -
the rootkit deleted this file. I don't think I've ever heard of
a vulnerability in it, though.
The box that got cracked is an Ultra-10, the one that didn't, an
E-450. I ended up ftp'ing the "ls" executable from the E450 to
the Ultra-10 while repairing the crack.
I was running "top" to see what was causing a performance slowdown
that users complained of. I discovered two processes named "lpset"
running. Strangely, "ps" didn't show these processes. I ran
"truss" on "ps" to see what was the matter. In the "truss" output,
I saw that the "ps" process opened and read a file named
/dev/pts/01/uconv.inf. Once again, and very strangely, "ls" wouldn't
show /dev/pts/01, but "echo /dev/pts/01/*" showed uconv.inf and
other suspicious files.
It was all downhill after that. The "/usr/lib/lpset" processes were
TCP sniffers, logging telnet and ftp sessions to a text file named
/dev/prom/sn.l .
The rootkit had trojaned du, ls, passwd, ps, su, find, netstat,
ping and strings. It only trojaned the /usr/bin versions of these
files. It also trojaned /usr/bin/login.
The rootkit messed up /var/adm/utmp and or /var/adm/wtmp. I found
a shell script named /dev/pts/01/cleaner that the rootkit must have
used to do the messing up.
Due to the rootkit modifying /etc/inetd.conf, this host was resistant
to the sadmind/IIS worm that came around a few weeks ago. See
http://www.cert.org/advisories/CA-2001-11.html . The rootkit took
out the "sadmind" line of /etc/inetd.conf.
The rootkit tried, but failed, to download recommended patches for
Solaris 2.7 from sunsolve.sun.com, using "wget". It failed because
whoever coded that piece of the rootkit put in an incorrect filename
for the tar file of the recommended patches.
The file /dev/pts/01/uconv.inf is "encrypted" by the simple means
of inverting all bits. A really simple C program can undo this
encryption:
---cut here---
#include <stdio.h>
int main(int ac, char **av) {
int c; while (EOF != (c = fgetc(stdin))) { c = ~c; fputc(c, stdout); }
return 0;
}
---cut here---
I relied heavily on the other Solaris machine to see (a) what got
modified, and (b) to give me untrojaned copies of "ls" and "ps".
In retrospect, I could have used /usr/ucb/ls or /usr/xpg4/bin/ls
and /usr/ucb/ps, but I didn't think of that on-the-spot. The fact
that Solaris has so many things that give you the same information
(/usr/bin/ps, /usr/ucb/ps, top, the /proc filesystem) makes it
harder to trojan up a machine so that a rootkit can't be found.
In retrospect, I should have put /usr/xpg4/bin at the start of my
PATH once I suspected anything.
Because all the trojaned executables checked the "uconv.inf" file
on every execution, I was worried that the would cause a "pearl
harbor" if they detected that I was un-trojaning the machine, so
I was pretty careful about the order in which I untrojaned ls, ps,
find, etc. I didn't run any trojaned executables while un-trojaning.
I don't believe any such viciousness exists in the rootkit's
programs, though.
This rootkit has existed for a while:
http://www.sans.org/infosecFAQ/malicious/comp_sys.htm
http://www.cert.org/advisories/CA-2001-05.html
Both of those links describe a similar, but not identical, rootkitted
machine. The SANS article came out in November of 2000, so the
rootkit's been around for about 6 months or so. The rootkit has
also mutated. The SANS article says the rootkit installs a "TFN"
DDoS zombie daemon. I saw evidence that in the rootkit remains
that it previously did so, but no longer does install that zombie.
Also, the method of trojaning "ps" has changed from the SANS article.
The CERT article is vague, but appears to describe more than one
variant.
The rootkit that I found is a combination of:
1. "SunOS Rootkit" by tragedy/dor . I got hold of v1.8 and the
distribution contained a file nearly identical to the /usr/lib/lpstart
shell script I found on my machine. I found a reference to a v2.5
"SunOS Rootkit" by the same "tragedy/dor" fellow on another web
page. This contains a trojan "ps" different than in the installed
rootkit I found.
The "setup" script from this rootkit explains why I found a
zero-length in.fingerd, and why /usr/lib/nfs/statd disappeared.
2. "Universal Root Kit". This is the trojaned "ls", "ps", "netstat"
and "find". It contains a file "inv.c" that demonstrates how the
rootkit file /dev/pts/01/uconf.inv gets decoded (invert all bits,
basically).
You can find this stuff at:
http://ouah.bsdjeunz.org/programmes2.htm
"tragedy/dor's" root kit:
http://ouah.bsdjeunz.org/progs/rk18-1.tar.gz
http://ouah.bsdjeunz.org/progs/rk18-2.tar.gz
"Universal Root Kit":
http://ouah.bsdjeunz.org/progs/urk-dist-0.9.7.tar.gz
http://www.ktwo.ca/urk-dist-0.9.8.tar.gz
So, I think that the rootkit got installed on my machine after
somebody got a root shell running. They got this shell by doing
a buffer overflow or formatstring stack smash on sadmind, statd
snpmXdmid or /usr/dt/bin/rpc.cmsd. I can't tell which one.
The rootkit in question is a combination of "tragedy/dor's" rootkit
and the trojaning method used in URK. "tragedy/dor's" rootkit has
better installation scripts and installs the /usr/bin/sshd2 and
login backdoors. URK has better, more complete trojaning - it puts
in "ls", "ps", "find", "netstat", "strings" and "du" trojons, all
configurable to hide files, processes and ports from a casual user's
view.
The combination required source for both URK and "tragedy/dor's"
rootkit, since the trojaned /usr/bin/login put its encrypted password
in /etc/lpconfig, which the "rk18" distribution put the same password
in /etc/ttyhash.
The trojaned "ps", "ls", etc that I found had an "inventory" file
named "uconv.inf", where URK 0.9.8 uses "urk.conf". You need URK
source to change that particular name.
I note that these rootkits are in active development: the SANS
article of Nov 2000 (http://www.sans.org/infosecFAQ/malicious/comp_sys.htm)
clearly describes the "tragedy/dor" rootkit, but just as clearly
does not describe the URK trojaning.