The CERT Coordination Center publishes incident notes to provide
information about incidents to the Internet community.
<h2>Distributed Denial of Service Tools</h2>
Updated: January 15, 2001 (changed RFC 2267 to RFC 2827/BCP 38)<br/>
Updated: December 8, 1999 (added DSIT Workshop paper and IN-99-05)<br/>
Thursday, November 18, 1999<br/>
<h3>Overview</h3>
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.
<p>
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:
<p>
<dl>
<dd><a href="http://www.cert.org/incident_notes/IN-99-04.html">
IN-99-04</a>, Similar Attacks Using Various RPC Services
<dd><a href="http://www.cert.org/incident_notes/IN-99-05.html">
IN-99-05</a>, Systems Compromised Through a Vulnerability in am-utils
</dd></dd></dl>
<p>
Two of the tools we have seen are known as <i><b>trinoo</b></i> (or
trin00) and <i><b>tribe flood network (or TFN)</b></i>. These tools
appear to be undergoing active development, testing, and deployment on
the Internet.
<p>
<h3>Descriptions</h3>
<ul>
<li><a href="#trinoo">Trinoo</a>
<li><a href="#tfn">Tribe Flood Network</a>
</li></li></ul>
<p>
<hr/>
<a name="#trinoo">
<b>Trinoo</b>
<p>
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
<a href="http://www.cert.org/advisories/CA-96.01.UDP_service_denial.html">
CERT Advisory CA-96.01</a>. A trinoo network consists of a small
number of servers, or <i>masters</i>, and a large number of clients,
or <i>daemons</i>.
<p>
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.
<p>
<ol>
<li>intruder -------> master; destination port 27665/tcp
<li>master -------> daemons; destination port 27444/udp
<li>daemons -------> UDP flood to target with randomized destination ports
</li></li></li></ol>
<p>
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.
<p>
<dl>
<dd>daemon -------> masters; destination port 31335/udp
</dd></dl>
<p>
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".
<p>
<ol>
<li>intruder -------> master; destination port 27665/tcp
<li>master -------> daemons; destination port 27444/udp
<li>daemons -------> master; destination port 31335/udp
</li></li></li></ol>
<p>
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).
<p>
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.
<p>
We have seen trinoo daemons installed under a variety of different
names, but most commonly as
<p>
<ul>
<li>ns
<li>http
<li>rpc.trinoo
<li>rpc.listen
<li>trinix
<li>rpc.irix
<li>irix
</li></li></li></li></li></li></li></ul>
<p>
Running <i>strings</i> 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)
<p>
<table align="CENTER" border="0" cellpadding="1" cellspacing="10" width="100%">
<tr>
<td align="LEFT" valign="TOP"><b>trinoo daemon</b></td>
<td align="LEFT" valign="TOP"><b>trinoo master</b></td>
</tr>
<tr>
<td align="LEFT" valign="TOP">
<pre>
socket
bind
recvfrom
%s %s %s
aIf3YWfOhw.V.
PONG
*HELLO*
X.X.X.X
X.X.X.X
X.X.X.X
</pre>
</td>
<td align="LEFT" valign="TOP">
<pre>
---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 ...
</pre>
</td>
</tr>
</table>
<hr/>
<a name="#tfn">
<b>Tribe Flood Network</b>
<p>
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.
<p>
<dl>
<dd><a href="http://www.cert.org/advisories/CA-96.21.tcp_syn_flooding.html">
CA-96.01</a>, TCP SYN Flooding and IP Spoofing Attacks
<dd><a href="http://www.cert.org/advisories/CA-98.01.smurf.html">
CA-98.01</a>, "smurf" IP Denial of Service Attacks
</dd></dd></dl>
<p>
A denial of service attack utilizing a TFN network is carried out by
an intruder instructing a client, or <i>master</i>, program to send
attack instructions to a list of TFN servers, or <i>daemons</i>. 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.
<p>
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.
<p>
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.
<p>
We have seen TFN daemons installed on systems using the filename
<b><i>td</i></b>. Running strings on the TFN daemon binary produces
output similar to this.
<p>
<pre>
%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
</pre>
<p>
<hr/>
<h3>Solutions</h3>
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.
<p>
There are some basic suggestions we can make regarding distributed
denial of service attacks:
<p>
<ul>
<li><b>Prevent installation of distributed attack tools on your systems</b>
<p>
Remain current with security-related patches to operating systems
and applications software. Follow security best-practices when
administrating networks and systems.
<p>
<li><b>Prevent origination of IP packets with spoofed source addresses</b>
<p>
For a discussion of network ingress filtering, refer to
<p>
<dl>
<dd><a href="ftp://ftp.isi.edu/in-notes/rfc2827.txt">RFC 2827/BCP 38</a>,
Network Ingress Filtering: Defeating Denial of Service Attacks
which employ IP Source Address Spoofing
</dd></dl>
<p>
<li><b>Monitor your network for signatures of distributed attack tools</b>
<p>
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.
<p>
<li><b>If you find a distributed attack tool on your systems</b>
<p>
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.
<p>
<li><b>If you are involved in a denial of service attack</b>
<p>
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.
<p>
</p></p></li></p></p></li></p></p></li></p></p></p></li></p></p></li></ul>
<p>
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.
<p>
<dl>
<dd><a href="http://www.cert.org/reports/dsit_workshop-final.html">
Results of the Distributed-Systems Intruder Tools Workshop</a>
</dd></dl>
<p>
<hr/>
<h3>Acknowledgments</h3>
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.
<p><!--#include virtual="/include/footer_nocopyright.html" --> </p>
<p>Copyright 1999 Carnegie Mellon University.</p>
</p></p></p></p></p></p></p></p></p></p></p></p></p></a></p></p></p></p></p></p></p></p></p></p></p></p></p></a></p></p></p></p></p> |