- Tricks
- Tools
- Techniques
- How to Use the Tools
- Related Resources
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
How to Use the Tools
This section provides samples of how to use each of the tools covered in the "Tools" section. We provide sample output and tips on interpreting the results. Use this information with the sample attack scenarios in the "Techniques" section.
Using Port Scanners
To demonstrate the capabilities of the Nmap port scanner, we ran the following scan. The output of the scan reveals the services running on the machine. Nmap's ability to identify the OS running on the system is particularly useful because it can significantly reduce the time required to launch a successful attack against the machine.
Based on the Nmap results, this system appears to be a fully loaded Solaris 2.6 or 7 OE system running most of the default services.
The Nmap output is as follows:
# /usr/local/nmap -O ganassi Starting nmap V. 2.53 (http://www.insecure.org/nmap/) Interesting ports on ganassi (10.8.10.231): (The 1515 ports scanned but not shown below are in state: closed) Port State Service 7/tcp open echo 9/tcp open discard 13/tcp open daytime 19/tcp open chargen 21/tcp open ftp 23/tcp open telnet 25/tcp open smtp 37/tcp open time 79/tcp open finger 111/tcp open sunrpc 512/tcp open exec 513/tcp open login 514/tcp open shell 515/tcp open printer 540/tcp open uucp 1103/tcp open xaudio 4045/tcp open lockd 6112/tcp open dtspc 7100/tcp open font-service 32771/tcp open sometimes-rpc5 32772/tcp open sometimes-rpc7 32773/tcp open sometimes-rpc9 32774/tcp open sometimes-rpc11 32775/tcp open sometimes-rpc13 32776/tcp open sometimes-rpc15 32777/tcp open sometimes-rpc17 32778/tcp open sometimes-rpc19 Remote operating system guess: Solaris 2.6 - 2.7 Uptime 0.054 days (since Wed Sep 12 09:41:59 2001) Nmap run completed -- 1 IP address (1 host up) scanned in 37 seconds
Using Vulnerability Scanners
To demonstrate the capabilities of the Nessus vulnerability scanner, we ran the following scan.
The command in our example runs a Nessus scan against the hosts listed in targetfile and stores the output in outfile:
# nessus -T text localhost 1241 noorder targetfile outfile
The Nessus output begins with a summary of the scan results:
Nessus Scan Report ------------------ SUMMARY - Number of hosts which were alive during the test : 1 - Number of security holes found : 2 - Number of security warnings found : 15 - Number of security notes found : 1 TESTED HOSTS 192.168.0.90 (Security holes found)
The output continues with details for each of the security warnings found. The following is an excerpt from the output:
DETAILS + 192.168.0.90 : . List of open ports : - unknown (161/udp) (Security hole found) - unknown (32779/udp) (Security warnings found) - unknown (32775/tcp) (Security warnings found) - unknown (32776/udp) (Security warnings found) - unknown (32778/udp) (Security warnings found) - unknown (32774/udp) (Security hole found) - unknown (32777/udp) (Security warnings found) - unknown (32780/udp) (Security warnings found) - unknown (32775/udp) (Security warnings found) - lockd (4045/udp) (Security warnings found) - unknown (32781/udp) (Security hole found) . Vulnerability found on port unknown (32774/udp) : The sadmin RPC service is running. There is a bug in Solaris versions of this service that allow an intruder to execute arbitrary commands on your system. Solution : disable this service Risk factor : High
Using this output, hackers from our example scenarios ("Techniques") gain access to the system.
In addition to other vulnerabilities, the following "denial of service" (DoS) vulnerability appears in the output:
DETAILS . List of open ports : - general/tcp (Security hole found) . Vulnerability found on port general/tcp : It was possible to make the remote server crash using the 'teardrop' attack. A cracker may use this attack to shut down this server, thus preventing your network from working properly. Solution : contact your operating system vendor for a patch. Risk factor : High CVE : CAN-1999-0015
The result of our Nessus scan reveals two security holes and 15 security warnings on a default Solaris 2.6 OE system.
Using Rootkits
To demonstrate the capabilities of a rootkit, we use one built for Solaris 2.6 OE. This rootkit is detailed in the Sun BluePrints_ OnLine article, The Solaris Fingerprint Database—A Security Tool for Solaris Software and Files. Additionally, this rootkit is documented by the HoneyNet project.
The rootkit has a variety of programs that fit into the following categories:
- Network sniffers
- Log file cleanup
- Internet Relay Chat (IRC) proxy
Included in the rootkit is an installation script for automating the installation of rootkit programs, setting program permissions, and erasing evidence from the log files.
The installation of the rootkit is as follows:
ganassi# ./setup.sh
hax0r w1th gforce
Ok This thing is complete :-)
cp: cannot access l0gin
cp: cannot create /usr/local/bin/find: No such file or directory
mv: cannot access /etc/.ts
mv: cannot access /etc/.tp
- WTMP:
/var/adm/wtmp is Thu Mar 26 13:21:36 1987
/usr/adm/wtmp cannot open
/etc/wtmp is Thu Mar 26 13:21:36 1987
/var/log/wtmp cannot open
WTMP = /var/adm/wtmp
No user re found in /var/adm/wtmp
[...]
./setup.sh: ./zap: not found
./secure.sh: rpc.ttdb=: not found
#: securing.
#: 1) changing modes on local files.
#: will add more local security later.
#: 2) remote crap like rpc.status , nlockmgr etc..
./secure.sh: usage: kill [ [ -sig ] id ... | -l ]
./secure.sh: usage: kill [ [ -sig ] id ... | -l ]
#: 3) killed statd , rpcbind , nlockmgr
#: 4) removing them so they ever start again!
5) secured.
193 ? 0:00 inetd
cp: cannot access /dev/.. /sun/bot2
kill these processes@!#!@#!
cp: cannot access lpq
./setup.sh: /dev/ttyt/idrun: cannot execute
Irc Proxy v2.6.4 GNU project (C) 1998-99
Coded by James Seter :bugs-> (Pharos@refract.com) or IRC pharos on efnet
--Using conf file ./sys222.conf
--Configuration:
Daemon port......:9879
Maxusers.........:0
Default conn port:6667
Pid File.........:./pid.sys222
Vhost Default....:-SYSTEM DEFAULT-
Process Id.......:759
Exit ./sys222{7} :Successfully went into the background.
The installation script is neither elegant nor correct for the Solaris 2.6 OE; however, it performs the job. It replaces the following system files:
/bin/ls /usr/bin/ls /bin/ps /bin/netstat /usr/bin/netstat /usr/sbin/rpcbind
Now the attacker has root access to a system on which:
It is difficult for an administrator to detect the intruder through standard Solaris OE commands, such as ls, find, ps, and netstat, because those binaries are replaced by trojan (hidden inside something that appears safe) versions.
It is easy for the attacker to gain access repeatedly because the new and trojaned system binaries for the login and rpcbind allow the attacker to gain access and execute commands on the system remotely.
The rootkit installs network sniffers on the victim system. This rootkit installs four network sniffers: le, sniff, sniff-10mb, and sniff-100mb.
Only the sniff-100mb executable is usable on ganassi; the other sniffers are hard-coded for specific interfaces.
The sniff-100mb executable defaults to the hme0 interface on ganassi. When the executable is run on ganassi, it produces a nicely formatted summary of network activity on the system:
ganassi# ./sniff-100mb Using logical device /dev/hme [/dev/hme] Output to stdout. Log started at => Thu Aug 26 15:31:10 [pid 856] -- TCP/IP LOG -- TM: Thu Aug 26 15:31:19 -- PATH: 10.8.10.200(34398) => ganassi(telnet) STAT: Thu Aug 26 15:31:48, 111 pkts, 128 bytes [DATA LIMIT] DATA: (255)(253)^C(255)(251)^X(255)(251)^_(255)(251) (255)(251)!(255)(251)"(255)(251)'(255)(253)^E(255)(250)^_ : P : ^X(255)(240)(255)(252)#(255)(252)$(255)(250)^X : DTTERM(255)(240)(255)(250)' : (255)(240)(255)(253)^A(255)(252)^Anoorder : t00lk1t : ls : who : cd /var/tmp : ls -al --
This output includes the user ID and password used to access the system.
The rootkit includes log cleanup programs and an IRC proxy.
Several sets of logs are sanitized by the rootkit: utmp, utmpx, wtmp, wtmpx, and lastlog. The program that sanitizes the logs is called zap; it looks for and removes files in common directories.
The IRC proxy in the rootkit includes a bot. The proxy bounces IRC messages across a private IRC channel. The bot keeps the channel open and responds to certain commands.
Using Sniffers
To demonstrate the capabilities of a sniffer to extract a user ID and password from a Telnet and IMAP session, we use the snoop tool. Collecting the information for the samples only took a few seconds.
The following is an example of the insecurities of Telnet:
# snoop -d qfe0 port telnet ganassi ganassi -> nomex-lab TELNET R port=32835 \377\373\1\377\375\1login: nomex-lab -> ganassi TELNET C port=32835 r ganassi -> nomex-lab TELNET R port=32835 r nomex-lab -> ganassi TELNET C port=32835 o ganassi -> nomex-lab TELNET R port=32835 o nomex-lab -> ganassi TELNET C port=32835 nomex-lab -> ganassi TELNET C port=32835 o ganassi -> nomex-lab TELNET R port=32835 o nomex-lab -> ganassi TELNET C port=32835 nomex-lab -> ganassi TELNET C port=32835 t ganassi -> nomex-lab TELNET R port=32835 t nomex-lab -> ganassi TELNET C port=32835 ganassi -> nomex-lab TELNET R port=32835 Password: nomex-lab -> ganassi TELNET C port=32835 nomex-lab -> ganassi TELNET C port=32835 t ganassi -> nomex-lab TELNET R port=32835 nomex-lab -> ganassi TELNET C port=32835 0 ganassi -> nomex-lab TELNET R port=32835 nomex-lab -> ganassi TELNET C port=32835 0 ganassi -> nomex-lab TELNET R port=32835 nomex-lab -> ganassi TELNET C port=32835 l ganassi -> nomex-lab TELNET R port=32835 nomex-lab -> ganassi TELNET C port=32835 k ganassi -> nomex-lab TELNET R port=32835 nomex-lab -> ganassi TELNET C port=32835 1 ganassi -> nomex-lab TELNET R port=32835 nomex-lab -> ganassi TELNET C port=32835 t nomex-lab -> ganassi TELNET C port=32835 ganassi -> nomex-lab TELNET R port=32835 Last login: Thu Mar nomex-lab -> ganassi TELNET C port=32835 ganassi -> nomex-lab TELNET R port=32835 #
The following is an example of the insecurities of IMAP:
# snoop -d qfe0 port imap2 ganassi jordan -> ganassi IMAP C port=46600 ganassi -> jordan IMAP R port=46600 jordan -> ganassi IMAP C port=46600 ganassi -> jordan IMAP R port=46600 * OK ganassi SIMS (tm) 2.0p12 IMAP jordan -> ganassi IMAP C port=46600 jordan -> ganassi IMAP C port=46600 1 capability\r\n ganassi -> jordan IMAP R port=46600 ganassi -> jordan IMAP R port=46600 * CAPABILITY IMAP4 STATUS SCAN IMAP4 jordan -> ganassi IMAP C port=46600 jordan -> ganassi IMAP C port=46600 2 login "hacked" "t00lk1t"\r\n ganassi -> jordan IMAP R port=46600 2 OK LOGIN completed
Using the snoop tool is fairly straightforward. If it runs for very long, it collects a great deal of data, and it might be noticed. The ideal solution for an attacker is an automated tool that only saves the user ID and password information for a specific list of protocols. Several tools are available to perform this task: the relatively simple sniffit and the much more flexible and extensive dsniff. (The dsniff tool provides automated mechanisms for attacking switched networks.) Either of these tools can be left running on a system for weeks, or months, to collect hundreds, maybe thousands, of passwords.
Switched Networks
No evaluation of network sniffing is complete without covering network switches. Network switches connect multiple systems to the same network segment in much the same manner as a network hub. The major difference is in the switch's ability to forward packets on a per-port basis. In this manner, only network traffic destined for a port is forwarded to it, instead of the port seeing all network traffic. With this configuration, even if a network interface is in the promiscuous mode, it does not see the traffic destined for another port on the same system.
Many people, based on this configuration, believe that network sniffing is useless. This belief is not true for two reasons. First, a sniffer running on a system captures all non-encrypted user ID and password strings sent to and from the system to any other system on the network. Secondly, publicly disclosed address resolution protocol (ARP) attacks can be launched against the network switch itself. These attacks can force the switch to relay all packets through one port, on which the sniffer is running. Network switches are a layer of protection against sniffing, however, they are not a complete solution.
To protect against network sniffing, encrypt authentication information. For example, instead of using Telnet and FTP, use Secure Shell (SSH). Instead of using plain POP3 for email, encrypt the session over secured sockets layer (SSL) for privacy. These precautions protect against network sniffing.
Terminal Servers
Many organizations use terminal servers to manage and administer headless systems (systems without a local display, keyboard, or mouse, and are managed remotely via remote consoles). While effective in leveraging datacenter space and "lights-out" datacenter environments, recognize that terminal servers can have many of the same vulnerabilities as systems. For example, the terminal servers shipped with Sun_ Cluster 3.0 software are normally 8-port Bay Annex servers. These terminal servers are accessed through Telnet.
The following is a snoop trace of a root login into this terminal server:
# snoop -d qfe0 nts01 nts01 -> nomex TELNET R port=34395 \nRotaries Defined: nomex -> nts01 TELNET C port=34395 nts01 -> nomex TELNET R port=34395 \n\nEnter Annex p nomex -> nts01 TELNET C port=34395 nomex -> nts01 TELNET C port=34395 3 nts01 -> nomex TELNET R port=34395 nts01 -> nomex TELNET R port=34395 Attached to port 3 nomex -> nts01 TELNET C port=34395 nts01 -> nomex TELNET R port=34395 ganassi console lo nomex -> nts01 TELNET C port=34395 nomex -> nts01 TELNET C port=34395 r nts01 -> nomex TELNET R port=34395 r nomex -> nts01 TELNET C port=34395 o nts01 -> nomex TELNET R port=34395 o nts01 -> nomex TELNET R port=34395 o nomex -> nts01 TELNET C port=34395 o nomex -> nts01 TELNET C port=34395 t nts01 -> nomex TELNET R port=34395 t nomex -> nts01 TELNET C port=34395 nts01 -> nomex TELNET R port=34395 Password: nomex -> nts01 TELNET C port=34395 nomex -> nts01 TELNET C port=34395 t nts01 -> nomex TELNET R port=34395 nomex -> nts01 TELNET C port=34395 0 nts01 -> nomex TELNET R port=34395 nomex -> nts01 TELNET C port=34395 0 nts01 -> nomex TELNET R port=34395 nomex -> nts01 TELNET C port=34395 l nts01 -> nomex TELNET R port=34395 nomex -> nts01 TELNET C port=34395 k nts01 -> nomex TELNET R port=34395 nomex -> nts01 TELNET C port=34395 1 nts01 -> nomex TELNET R port=34395 nomex -> nts01 TELNET C port=34395 t nts01 -> nomex TELNET R port=34395 nomex -> nts01 TELNET C port=34395 nts01 -> nomex TELNET R port=34395 Mar 26 13:04:36 ga nts01 -> nomex TELNET R port=34395 Last login: nomex -> nts01 TELNET C port=34395 nts01 -> nomex TELNET R port=34395 Thu Mar 26 13:03:06 nts01 -> nomex TELNET R port=34395 SunOS 5.6 Gene
Clearly, these terminal servers need to be protected by the same encryption technology as all the systems on the network. Two alternatives are available to secure terminal servers. The first is to purchase terminal servers that support encryption for privacy through a mechanism such as SSH. The second alternative is to provide a landing pad that functions as a gateway between the terminal servers and the rest of the network. This gateway supports SSH, and the private network on which the terminal services reside isolate the use of Telnet.