This document is a technical analysis of the Tribe Flood Network 2000 (TFN2K) distributed denial-of-service (DDoS) attack tool, the successor to the original TFN Trojan by Mixter.
cfd9ab39b27fdf49f0cb4d3d8c500997b796dad7ca44d25f3176e7b85dabcb83<!DOCTYPE HTML PUBLIC "html.dtd">
<HTML>
<HEAD>
<META CONTENT="text/html; charset=windows-1252" HTTP-EQUIV="Content-Type">
<META NAME="Generator" CONTENT="Microsoft Word 97">
</HEAD>
<BODY BGCOLOR="#ffffff" VLINK="#800080" LINK="#0000ff">
<B><FONT SIZE="5" FACE="Arial"><P ALIGN="CENTER">TFN2K – An Analysis</P>
<P ALIGN="CENTER"></B></FONT><FONT SIZE="2" FACE="Arial">Jason Barlow and Woody Thrower<BR>
Axent Security Team</P>
<P ALIGN="CENTER"></FONT><FONT SIZE="1" FACE="Arial">February 10, 2000<BR>
Revision: 1.1</P>
</FONT><B><FONT FACE="Arial"><P ALIGN="CENTER"> </P>
<P>Abstract</P>
</B></FONT><FONT SIZE="2"><P>This document is a technical analysis of the Tribe Flood Network 2000 (TFN2K) distributed denial-of-service (DDoS) attack tool, the successor to the original TFN Trojan by Mixter. Additionally, countermeasures for this attack are also covered. This document assumes a basic understanding of DDoS attacks. Analyses of related DDoS attack tools such as Stacheldraht and Trin00 are not presented here. For information about DDoS attacks and TFN2K’s cousins, please refer to the following documents:</P>
</FONT><P><A HREF="http://www2.axent.com/swat/News/ddos-explanation.htm"><FONT SIZE="2">http://www2.axent.com/swat/News/ddos-explanation.htm</FONT></A> <FONT SIZE="2"><BR>
</FONT><A HREF="http://staff.washington.edu/dittrich/misc/trinoo.analysis"><FONT SIZE="2">http://staff.washington.edu/dittrich/misc/trinoo.analysis</FONT></A> <FONT SIZE="2"><BR>
</FONT><A HREF="http://staff.washington.edu/dittrich/misc/tfn.analysis"><FONT SIZE="2">http://staff.washington.edu/dittrich/misc/tfn.analysis</FONT></A> <FONT SIZE="2"><BR>
</FONT><A HREF="http://staff.washington.edu/dittrich/misc/stacheldraht.analysis"><FONT SIZE="2">http://staff.washington.edu/dittrich/misc/stacheldraht.analysis</FONT></A> <FONT SIZE="2"><BR>
</FONT><A HREF="http://packetstorm.securify.com/distributed"><FONT SIZE="2">http://packetstorm.securify.com/distributed</FONT></A> <FONT SIZE="2"><BR>
</FONT><A HREF="http://www.cert.org/advisories/CA-2000-01.html"><FONT SIZE="2">http://www.cert.org/advisories/CA-2000-01.html</FONT></A> <FONT SIZE="2"><BR>
</FONT><A HREF="http://www.cert.org/advisories/CA-99-17-denial-of-service-tools.html"><FONT SIZE="2">http://www.cert.org/advisories/CA-99-17-denial-of-service-tools.html</FONT></A> <FONT SIZE="2"><BR>
</FONT><A HREF="http://www.cert.org/advisories/CA-98-13-tcp-denial-of-service.html"><FONT SIZE="2">http://www.cert.org/advisories/CA-98-13-tcp-denial-of-service.html</FONT></A> <FONT SIZE="2"><BR>
</FONT><A HREF="http://www.cert.org/incident_notes/IN-99-07.html"><FONT SIZE="2">http://www.cert.org/incident_notes/IN-99-07.html</FONT></A> <FONT SIZE="2"><BR>
</FONT><A HREF="http://www.sans.org/y2k/solaris.htm"><FONT SIZE="2">http://www.sans.org/y2k/solaris.htm</FONT></A> <FONT SIZE="2"><BR>
</FONT><A HREF="http://www.fbi.gov/nipc/trinoo.htm"><FONT SIZE="2">http://www.fbi.gov/nipc/trinoo.htm</FONT></A> <FONT SIZE="2"><BR>
</FONT><A HREF="http://www.fbi.gov/pressrm/pressrel/pressrel99/prtrinoo.htm"><FONT SIZE="2">http://www.fbi.gov/pressrm/pressrel/pressrel99/prtrinoo.htm</FONT></A><FONT SIZE="2"> </P>
</FONT><B><FONT FACE="Arial">
<BR>
<P>Terminology</P>
</B></FONT><FONT SIZE="2"><P>The terminology used in DDoS analyses is often confusing. For clarity, we use the following:</P>
<B><P>Client</B><I> – an application that can be used to initiate attacks by sending commands to other components (see below).</P>
</I><B><P>Daemon</B><I> – a process running on an agent (see below), responsible for receiving and carrying out commands issued by a client.</P>
</I><B><P>Master</B><I> – a host running a client</P>
</I><B><P>Agent</B><I> – a host running a daemon</P>
</I><B><P>Target</B> – <I>the victim (a host or network) of a distributed attack</P>
<BR>
</I></FONT><B><FONT FACE="Arial"><P>Overview - What is TFN2K?</P>
</B></FONT><FONT SIZE="2"><P>TFN2K allows <I>masters</I> to exploit the resources of a number of <I>agents</I> in order to coordinate an attack against one or more designated <I>targets</I>. Currently, UNIX, Solaris, and Windows NT platforms that are connected to the Internet, directly or indirectly, are susceptible to this attack. However, the tool could easily be ported to additional platforms.</P>
<P>TFN2K is a two-component system: a command driven <I>client</I> on the <I>master</I> and a <I>daemon </I>process operating on an <I>agent</I>. The <I>master</I> instructs its <I>agents</I> to attack a list of designated targets. The <I>agents </I>respond by flooding the <I>targets</I> with a barrage of packets. Multiple <I>agents</I>, coordinated by the <I>master</I>, can work in tandem during this attack to disrupt access to the <I>target</I>. <I>Master-to-agent</I> communications are encrypted, and may be intermixed with any number of decoy packets. Both<I> master-to-agent </I>communications and the attacks themselves can be sent via randomized TCP, UDP, and ICMP packets. Additionally, the <I>master</I> can falsify its IP address (spoof). These facts significantly complicate development of effective and efficient countermeasures for TFN2K.</P>
<BR>
</FONT><B><FONT FACE="Arial"><P>TFN2K – The Facts</P>
<UL>
</B></FONT><FONT SIZE="2"><LI>Commands are sent from the <I>master </I>to the <I>agent</I> via TCP, UDP, ICMP, or all three at random. </LI>
<LI>Targets may be attacked with a TCP/SYN, UDP, ICMP/PING, or BROADCAST PING (SMURF) packet flood. The <I>daemon </I>may also be instructed to randomly alternate between all four styles of attack. </LI>
<LI>Packet headers between <I>master </I>and <I>agent </I>are randomized, with the exception of ICMP, which always uses a type code of ICMP_ECHOREPLY (ping response). </LI>
<LI>Unlike its predecessors, the TFN2K <I>daemon </I>is completely silent; it does not acknowledge the commands it receives. Instead, the <I>client</I> issues each command 20 times, relying on probability that the <I>daemon </I>will receive at least one. </LI>
<LI>The command packets may be interspersed with any number of decoy packets sent to random IP addresses. </LI>
<LI>TFN2K commands are not string-based (as they are in TFN and Stacheldraht). Instead, commands are of the form "+<id>+<data>" where <id> is a single byte denoting a particular command and <data> represents the command’s parameters. </LI>
<LI>All commands are encrypted using a key-based CAST-256 algorithm (RFC 2612). The key is defined at compile time and is used as a password when running the TFN2K <I>client</I>. </LI>
<LI>All encrypted data is Base 64 encoded before it is sent. This holds some significance, as the payload should be comprised entirely of ASCII printable characters. The TFN2K <I>daemon</I> uses this fact as a sanity-test when decrypting incoming packets. </LI>
<LI>The <I>daemon</I> spawns a child for each attack against a <I>target</I>. </LI>
<LI>The TFN2K <I>daemon</I> attempts to disguise itself by altering the contents of argv[0], thereby changing the process name on some platforms. The falsified process names are defined at compile time and may vary from one installation to the next. This allows TFN2K to masquerade as a normal process on the <I>agent</I>. Consequently, the <I>daemon </I>(and its children) may not be readily visible by simple inspection of the process list. </LI>
<LI>All packets originating from either <I>client </I>or <I>daemon </I>can be (and are, by default) spoofed.</LI></UL>
<BR>
</FONT><B><FONT FACE="Arial"><P>Detecting TFN2K – The Signature</P>
</B></FONT><FONT SIZE="2"><P>All control communications are unidirectional, making TFN2K extremely problematic to detect by active means. Because it uses TCP, UDP, and ICMP packets that are randomized and encrypted, packet filtering and other passive countermeasures become impractical and inefficient. Decoy packets also complicate attempts to track down other <I>agents </I>participating<I> </I>in the denial-of-service network.</P>
<P>Fortunately, there are weaknesses. In what appears to be an oversight (or a bug), the Base 64 encoding (which occurs after encryption) leaves a telltale fingerprint at the end of every TFN2K packet (independent of protocol and encryption algorithm). We suspect it was the intent of the author to create variability in the length of each packet by padding with one to sixteen zeroes. Base 64 encoding of the data translates this sequence of trailing zeros into a sequence of 0x41’s (‘A’). The actual count of 0x41’s appearing at the end of the packet will vary, but there will always be at least one. The padding algorithm is somewhat obscure (but predictable) and beyond the scope of this document. However, the presence of this fingerprint has been validated both in theory and through empirical data gathered by dumping an assortment of command packets.</P>
<P>A simple scan for the files <B>tfn </B>(the <I>client</I>)<I> </I>and <B>td </B>(the <I>daemon</I>) may also reveal the presence of TFN2K. However, these files are likely to be renamed when appearing in the wild. In addition to this, both <I>client </I>and <I>daemon </I>contain a number of strings that can be found using virus scanning methods. Below is a partial list of some of the strings (or sub-strings) appearing in TFN2K:</P>
<P>NOTE: Scanners should look for pattern combinations unlikely to appear in legitimate software.</P>
<U><P>TFN2K Client (tfn)</P>
</U></FONT>
<FONT SIZE="2" , FACE="Courier New">
[1;34musage: %s <options><BR>
[-P protocol]<BR>
[-S host/ip]<BR>
[-f hostlist]<BR>
[-h hostname]<BR>
[-i target string]<BR>
[-p port]<BR>
<-c command ID><BR>
change spoof level to %d<BR>
change packet size to %d bytes<BR>
bind shell(s) to port %d<BR>
commence udp flood<BR>
commence syn flood, port: %s<BR>
commence icmp echo flood<BR>
commence icmp broadcast (smurf) flood<BR>
commence mix flood<BR>
commence targa3 attack<BR>
execute remote command<BR></FONT>
<U><FONT SIZE="2"><P>TFN2K Daemon (td)</P>
</U></FONT>
<FONT SIZE="2" , FACE="Courier New">
fork<BR>
ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/<BR>
/dev/urandom<BR>
/dev/random<BR>
%d.%d.%d.%d<BR>
sh*<BR>
ksh*<BR>
command.exe**<BR>
cmd.exe**<BR>
tfn-daemon***<BR>
tfn-child***<BR>
</FONT>
<FONT SIZE="3" , FACE="Courier New">
<PRE>* Unix and Solaris systems only
** Windows NT systems only
*** This text is likely to have been changed in many TFN2K installations
</PRE></FONT>
<U><FONT SIZE="2"><P>TFN2K Daemon and Client (tfn and td)</P>
</U></FONT>
<FONT SIZE="2" , FACE="Courier New">
security_through_obscurity *<BR>
D4 40 FB 30 0B FF A0 9F **<BR>
64 64 64 64 ... ***<BR>
</FONT>
<FONT SIZE="3" , FACE="Courier New">
<PRE>* This is a function whose definition is generated at compile time. This
is a strong (and probably unique) signature.
** This byte pattern is present in both <I>client </I>and <I>daemon</I>,<I> </I>and
represents the first eight bytes in the CAST-256 encryption table
(assumes little-endian byte ordering).
*** A contiguous 128-byte sequence of 0x64 values reveals the presence of
the static table used in the Base 64 decoding algorithm.
</PRE></FONT>
<BR>
<B><FONT FACE="Arial">
<P>Defeating TFN2K – A Strategy</P>
</B></FONT><FONT SIZE="2"><P>There is no known way to defend against TFN2K denial-of-service attacks. The most effective countermeasure is to prevent your own network resources from being used as <I>clients</I> or <I>agents</I>.</P>
<U><P>Prevention</P>
<UL>
</U><LI>Use a firewall that exclusively employs application proxies. This should effectively block all TFN2K traffic. Exclusive use of application proxies is often impractical, in which case the allowed non-proxy services should be kept to a minimum. </LI>
<LI>Disallow unnecessary ICMP, TCP, and UDP traffic. Typically only ICMP type 3 (destination unreachable) packets should be allowed. </LI>
<LI>If ICMP cannot be blocked, disallow unsolicited (or all) ICMP_ECHOREPLY packets. </LI>
<LI>Disallow UDP and TCP, except on a specific list of ports. </LI>
<LI>Spoofing can be limited by configuring the firewall to disallow any outgoing packet whose source address does not reside on the protected network. </LI>
<LI>Take measures to ensure that your systems are not vulnerable to attacks that would allow intruders to install TFN2K.</LI></UL>
<U><P>Detection</P>
<UL>
</U><LI>Scan for the <I>client</I>/<I>daemon </I>files by name. </LI>
<LI>Scan all executable files on a host system for patterns described in the previous section. </LI>
<LI>Scan the process list for the presence of daemon processes. </LI>
<LI>Examine incoming traffic for unsolicited ICMP_ECHOREPLY packets containing sequences of 0x41 in their trailing bytes. Additionally, verify that all other payload bytes are ASCII printable characters in the range of (2B, 2F-39, 0x41-0x5A, or 0x61-0x7A). </LI>
<LI>Watch for a series of packets (possibly a mix of TCP, UDP, and ICMP) with identical payloads.</LI></UL>
<U><P>Response</P>
</U><P>Once TFN2K has been identified on a host system, it is imperative that the authorities be notified immediately so that the perpetrators can be traced. Because a TFN2K daemon does not acknowledge the commands it receives, it is likely the client will continue to transmit packets to the agent system. Additionally, a hacker observing the absence of flood activity, may attempt to reestablish direct contact with the agent system to determine the nature of the problem. In either case, the communication can be traced. </P>
<P>TFN2K <I>is </I>traceable but requires a timely response on the part of the victim. If you believe you have been the victim of TFN2K or any other DDoS attack, please contact your local FBI office. </P>
</FONT><P><A HREF="http://www.fbi.gov/contact/fo/fo.htm"><FONT SIZE="2">http://www.fbi.gov/contact/fo/fo.htm</FONT></A></P>
<B><FONT FACE="Arial">
<BR>
<P>Summary</P>
</B></FONT><FONT SIZE="2"><P>TFN2K and other DDoS attack signatures are under continuous investigation by Axent Technologies. As more information becomes available, this document will be updated.</P>
</FONT><B><FONT FACE="Arial">
<BR>
<P>Contact Information</P>
</B></FONT><FONT SIZE="2"><P>If you have questions or comments regarding this article or other security developments, send e-mail to </FONT><A HREF="mailto:security@axent.com"><FONT SIZE="2">securityteam@axent.com</FONT></A><FONT SIZE="2">.</P>
<P> </P>
<P ALIGN="CENTER">Copyright © 2000 Axent Technologies – All Rights Reserved</P></FONT></BODY>
</HTML>
© 2024 Packet Storm. All rights reserved.
%7Cutmcsr%3D(direct)%7Cutmcmd%3D(none)){kind=small}
Follow us on Twitter
Follow us on Facebook
Subscribe to an RSS Feed