Honeynet Project Reverse Challenge

Matt Messier, Bob Fleck, John Viega

Secure Software, Inc.


 

Abstract

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 network.

Details

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 root.

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 the process.

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.

    Defense

    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.