Distributed Denial of Service Tools
Updated: January 15, 2001 (changed RFC 2267 to RFC 2827/BCP 38)Updated: December 8, 1999 (added DSIT Workshop paper and IN-99-05)
Thursday, November 18, 1999
Overview
We have received reports of intruders installing distributed denial of service tools. Tools we have encountered utilize distributed technology to create large networks of hosts capable of launching large coordinated packet flooding denial of service attacks.We have seen distributed tools installed on hosts that have been compromised due to exploitation of known vulnerabilities. In particular, we have seen vulnerabilities in various RPC services exploited. For more information see the following CERT Incident Notes:
-
IN-99-04, Similar Attacks Using Various RPC Services
- IN-99-05, Systems Compromised Through a Vulnerability in am-utils
Two of the tools we have seen are known as trinoo (or trin00) and tribe flood network (or TFN). These tools appear to be undergoing active development, testing, and deployment on the Internet.
Descriptions
Trinoo
Trinoo is a distributed tool used to launch coordinated UDP flood denial of service attacks from many sources. For more information about various UDP flood attacks, please see CERT Advisory CA-96.01. A trinoo network consists of a small number of servers, or masters, and a large number of clients, or daemons.
A denial of service attack utilizing a trinoo network is carried out by an intruder connecting to a trinoo master and instructing that master to launch a denial of service attack against one or more IP addresses. The trinoo master then communicates with the daemons giving instructions to attack one or more IP addresses for a specified period of time.
- intruder -------> master; destination port 27665/tcp
- master -------> daemons; destination port 27444/udp
- daemons -------> UDP flood to target with randomized destination ports
The binary for the trinoo daemon contains IP addresses for one or more trinoo master. When the trinoo daemon is executed, the daemon announces it's availability by sending a UDP packet containing the string "*HELLO*" to it's programmed trinoo master IP addresses.
- daemon -------> masters; destination port 31335/udp
The trinoo master stores a list of known daemons in an encrypted file named "..." in the same directory as the master binary. The trinoo master can be instructed to send a broadcast request to all known daemons to confirm availability. Daemons receiving the broadcast respond to the master with a UDP packet containing the string "PONG".
- intruder -------> master; destination port 27665/tcp
- master -------> daemons; destination port 27444/udp
- daemons -------> master; destination port 31335/udp
All communications to the master on port 27665/tcp require a password, which is stored in the daemon binary in encrypted form. All communications with the daemon on port 27444/udp require the UDP packet to contain the string "l44" (that's a lowercase L, not a one).
The source IP addresses of the packets in a trinoo-generated UDP flood attack are not spoofed in versions of the tool we have seen. Future versions of the tool could implement IP source address spoofing. Regardless, a trinoo-generated denial of service attack will most likely appear to come from a large number of different source addresses.
We have seen trinoo daemons installed under a variety of different names, but most commonly as
- ns
- http
- rpc.trinoo
- rpc.listen
- trinix
- rpc.irix
- irix
Running strings against the daemon and master binaries produces output similar to this (we have replaced master IP address references in the daemon binary with X.X.X.X)
| trinoo daemon | trinoo master |
socket
bind
recvfrom
%s %s %s
aIf3YWfOhw.V.
PONG
*HELLO*
X.X.X.X
X.X.X.X
X.X.X.X
|
---v
v1.07d2+f3+c
trinoo %s
l44adsl
sock
0nm1VNMXqRMyM
15:08:41
Aug 16 1999
trinoo %s [%s:%s]
bind
read
*HELLO*
... rest omitted ...
|
Tribe Flood Network
TFN, much like Trinoo, is a distributed tool used to launch coordinated denial of service attacks from many sources against one or more targets. In additional to being able to generate UDP flood attacks, a TFN network can also generate TCP SYN flood, ICMP echo request flood, and ICMP directed broadcast (e.g., smurf) denial of service attacks. TFN has the capability to generate packets with spoofed source IP addresses. Please see the following CERT Advisories for more information about these types of denial of service attacks.
A denial of service attack utilizing a TFN network is carried out by an intruder instructing a client, or master, program to send attack instructions to a list of TFN servers, or daemons. The daemons then generate the specified type of denial of service attack against one or more target IP addresses. Source IP addresses and source ports can be randomized, and packet sizes can be altered.
A TFN master is executed from the command line to send commands to TFN daemons. The master communicates with the daemons using ICMP echo reply packets with 16 bit binary values embedded in the ID field, and any arguments embedded in the data portion of packet. The binary values, which are definable at compile time, represent the various instructions sent between TFN masters and daemons.
Use of the TFN master requires an intruder-supplied list of IP addresses for the daemons. Some reports indicate recent versions of TFN master may use blowfish encryption to conceal the list of daemon IP addresses. Reports also indicate that TFN may have remote file copy (e.g., rcp) functionality, perhaps for use for automated deployment of new TFN daemons and/or software version updating in existing TFN networks.
We have seen TFN daemons installed on systems using the filename td. Running strings on the TFN daemon binary produces output similar to this.
%d.%d.%d.%d ICMP Error sending syn packet. tc: unknown host 3.3.3.3 mservers randomsucks skillz rm -rf %s ttymon rcp %s@%s:sol.bin %s nohup ./%s X.X.X.X X.X.X.X lpsched sicken in.telne
Solutions
Distributed attack tools leverage bandwidth from multiple systems on diverse networks to produce very potent denial of service attacks. To a victim, an attack may appear to come from many different source addresses, whether or not IP source address spoofing is employed by the attacker. Responding to a distributed attack requires a high degree of communication between Internet sites. Prevention is not straight forward because of the interdependency of site security on the Internet; the tools are typically installed on compromised systems that are outside of the administrative control of eventual denial of service attack targets.There are some basic suggestions we can make regarding distributed denial of service attacks:
- Prevent installation of distributed attack tools on your systems
Remain current with security-related patches to operating systems and applications software. Follow security best-practices when administrating networks and systems.
- Prevent origination of IP packets with spoofed source addresses
For a discussion of network ingress filtering, refer to
- RFC 2827/BCP 38, Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing
- Monitor your network for signatures of distributed attack tools
Sites using intrusion detection systems (e.g., IDS) may wish to establish patterns to look for that might indicate trinoo or TFN activity based on the communications between master and daemon portions of the tools. Sites who use pro-active network scanning may wish to include tests for installed daemons and/or masters when scanning systems on your network.
- If you find a distributed attack tool on your systems
It is important to determine the role of the tools installed on your system. The piece you find may provide information that is useful in locating and disabling other parts of distributed attack networks. We encourage you to identify and contact other sites involved.
- If you are involved in a denial of service attack
Due to the potential magnitude of denial of service attacks generated by distributed networks of tools, the target of an attack may be unable to rely on Internet connectivity for communications during an attack. Be sure your security policy includes emergency out-of-band communications procedures with upstream network operators or emergency response teams in the event of a debilitating attack.
In November 1999, experts addressed issues surrounding distributed-systems intruder tools. The DSIT Workshop produced a paper where workshop participants examine the use of distributed-system intruder tools and provide information about protecting systems from attack by the tools, detecting the use of the tools, and responding to attacks.
Acknowledgments
The CERT/CC would like to acknowledge and thank our constituency and our peers for important contributions to the information used in this Incident Note.
Copyright 1999 Carnegie Mellon University.