Honeynet Project Reverse Challenge
Matt Messier, Bob Fleck, John Viega
Secure Software, Inc.
A Distributed Denial of Service (DDoS) tool has been discovered on one
of our servers. A Denial of Service attack is an attack that is launched
at either a single or a small number of hosts on a network to deny those
hosts the ability to use their network, usually by saturating the network
connection with useless data. A Distributed Denial of Service attack
is launched from a large number of hosts against either a single or a small
number of hosts. By distributing the source of attack, it is easier
for the attacker to conceal himself, but more importantly, it provides
the attacker with the ability to more easily and quickly saturate the target's
We have analyzed the DDoS tool and learned that it is capable of launching
a variety of DDoS attacks. Each of the attacks works by attempting
to flood a single target host with large amounts of data that it has not
requested. This data must be processed by the target in addition
to any valid data that it should be sending and receiving. In addition,
this tool is capable of providing the attacker with a root shell on our
server or the ability to run any command of the attacker's choosing as
The tool attempts to hide itself by changing its process name to "[mingetty]",
which indicates that the process name is "mingetty" and that it is currently
swapped to disk. It is possible to check a system for the tool by
using the ps command to verify that all instances of mingetty are associated
with a valid tty or any tty at all. Normally, mingetty should be
running with an association to the tty that it is running on (tty1, tty2,
tty3, etc.). It should never be running with an association to a
pseudo-tty (such as pts/1 or ttyp0, etc. depending on the version of Linux
that is running on the system). The tool communicates via raw sockets,
so it is also possible to discover it using a tool such as netstat or lsof
and looking for raw sockets with a protocol of 0xB (11 decimal, or "nvp"
as listed in /etc/protocols), which is a network voice protocol
known as NVP-II. To look for the tool with netstat, use the -a and
-w options. To look for the tool with lsof, run as root and search
for a type of "raw". The command "lsof | grep raw" will work, and
will additionally tell you the name of the binary that was used to start
Unfortunately, it is likely that a "rootkit" has been installed on
any system that has been compromised. A rootkit replaces many system
binaries with special versions that hide the existance of a program or
programs running on the system that should not be. This would mean
that binaries such as ps and netstat cannot be relied upon to detect the
existance of the trojan that has been detected on our network. In
general, when a system has been compromised or is suspected of having been
compromised, nothing on that system can any longer be trusted. This
makes the task of determining whether a system has been compromised much
more difficult. If a machine is suspected of being compromised to this
level the operating system and all the software should be completely
reinstalled, as it is very difficult to be confident that all traces
of the compromise have been removed.
A system that is trusted and known to be uncompromised is required to
determine whether another system (the target) has been compromised
or not. The first task is to perform an exhaustive port scan of the
target machine using a tool such as nmap to determine which ports are listening
for connections. This method can be used to find some common and
well-known DDoS tools such as Trin00, but it will not uncover the tool
that we have found unless it has been placed in listening mode for remote
shell access. In this case, TCP port 23281 will be in a listening
state. Another method for detecting the presence of the trojan is
to scan for network traffic going to it. This would involve looking
for packets using the NVP-II protocol, but would only find commands sent
from the attacker to the running trojan.
The tool is capable of initiating five different types of attacks:
TCP SYN flood. This type of attack creates
half-open connections on the target host by sending connection request packets
with a spoofed source address to the target host. Many TCP/IP
implementations keep a list of pending incoming connections that does not grow
dynamically. Because the list does not grow, it will fill up while waiting
for the source host that was spoofed to ACK the connection, which of course will
never happen. Eventually the pending connections will timeout, but as long
as the attack persists, the table will just fill up again.
ICMP flood. Known as a Smurf attack, this
attack sends ICMP echo requests to broadcast addresses with the
target's IP address as the spoofed source address. The result is that
target host will be flooded with ICMP echo responses from each host
responding to the broadcast ICMP echo request.
UDP flood. Known as a Fraggle attack, this
attack is a variation of the Smurf attack. It works in the same manner as
the ICMP attack, except that exploits the UDP echo service (port 7) because
UDP does not have a built-in echo mechanism as ICMP does.
DNS direct flood. This attack will flood a
host with DNS requests for top-level domains. The packets for the requests
are small, but the responses are considerably larger. Depending on the
mode of operation, the target of the attack could either be the destination host
for the requests or the spoofed source of the requests. In the former
case, the source address is spoofed with a random IP address, causing the
target host's outbound bandwidth to congest sending the large responses to
random hosts that did not request the data. In the latter case, the target
host is flooded with DNS traffic containing the responses for the queries
that it must forward on to either a forwarder or the root name servers.
DNS reflection flood. This attack will also
flood a host with DNS traffic. The IP addresses of 11,441 hosts
are hard-coded into the tool. Each of these hosts will be sent requests
for top-level domain information with the source address spoofed as the target's
IP address. The result is the target host being flooded with large,
unsolicited responses from thousands of hosts.
This tool is not very well developed. It contains many programming
and protocol errors, some of which are intentional and some of which are
not. The most obvious defense strategy would be to firewall all incoming
traffic using an IP protocol that is not expected, which will effectively
block the attacker's ability to control the tool from the outside.
Unfortunately, this defense does not protect against the attacker initiating
commands from inside the network.
A better strategy would be to setup firewall rules for outgoing traffic.
It should be required that all outgoing traffic is well-formed. For
example, the ICMP and UDP attacks send out packets with bad packet
lengths and checksums. In addition, most outgoing traffic contains
spoofed source addresses. Typically, these spoofed addresses will
not be addresses that belong to us. Traffic coming from inside our
network that has an IP address not belonging to us should also be
blocked by the firewall.
We feel it is also necessary for us to reiterate the
importance of keeping all systems up-to-date with respect to all security
related patches issued by the vendor(s) of all software installed on the
network. It is obviously better to do everything possible to prevent the
initial intrustion by the attacker into our networks in the first place.
No systems should remain vulnerable to known security vulnerabilities once fixes
and/or patches have been issued to correct them.