TFN2K - An Analysis

[barlow_jason () HOTMAIL COM (Jason Barlow)]

TFN2K – An Analysis
Jason Barlow and Woody Thrower
Axent Security Team
February 10, 2000
Revision: 1.1

Abstract

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:

http://www2.axent.com/swat/News/ddos-explanation.htm
http://staff.washington.edu/dittrich/misc/trinoo.analysis
http://staff.washington.edu/dittrich/misc/tfn.analysis
http://staff.washington.edu/dittrich/misc/stacheldraht.analysis
http://packetstorm.securify.com/distributed
http://www.cert.org/advisories/CA-2000-01.html
http://www.cert.org/advisories/CA-99-17-denial-of-service-tools.html
http://www.cert.org/advisories/CA-98-13-tcp-denial-of-service.html
http://www.cert.org/incident_notes/IN-99-07.html
http://www.sans.org/y2k/solaris.htm
http://www.fbi.gov/nipc/trinoo.htm
http://www.fbi.gov/pressrm/pressrel/pressrel99/prtrinoo.htm

Terminology

The terminology used in DDoS analyses is often confusing. For clarity, we
use the following:

Client – an application that can be used to initiate attacks by sending
commands to other components (see below).

Daemon – a process running on an agent (see below), responsible for
receiving and carrying out commands issued by a client.

Master – a host running a client

Agent – a host running a daemon

Target – the victim (a host or network) of a distributed attack

Overview - What is TFN2K?

TFN2K allows masters to exploit the resources of a number of agents in order
to coordinate an attack against one or more designated targets. 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.

TFN2K is a two-component system: a command driven client on the master and a
daemon process operating on an agent. The master instructs its agents to
attack a list of designated targets. The agents respond by flooding the
targets with a barrage of packets. Multiple agents, coordinated by the
master, can work in tandem during this attack to disrupt access to the
target. Master-to-agent communications are encrypted, and may be intermixed
with any number of decoy packets. Both master-to-agent communications and
the attacks themselves can be sent via randomized TCP, UDP, and ICMP
packets. Additionally, the master can falsify its IP address (spoof). These
facts significantly complicate development of effective and efficient
countermeasures for TFN2K.

TFN2K – The Facts

Commands are sent from the master to the agent via TCP, UDP, ICMP, or all
three at random.

Targets may be attacked with a TCP/SYN, UDP, ICMP/PING, or BROADCAST PING
(SMURF) packet flood. The daemon may also be instructed to randomly
alternate between all four styles of attack.

Packet headers between master and agent are randomized, with the exception
of ICMP, which always uses a type code of ICMP_ECHOREPLY (ping response).

Unlike its predecessors, the TFN2K daemon is completely silent; it does not
acknowledge the commands it receives. Instead, the client issues each
command 20 times, relying on probability that the daemon will receive at
least one.

The command packets may be interspersed with any number of decoy packets
sent to random IP addresses.

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.

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

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 daemon uses this fact as a sanity-test when decrypting
incoming packets.

The daemon spawns a child for each attack against a target.

The TFN2K daemon 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
agent.  Consequently, the daemon (and its children) may not be readily
visible by simple inspection of the process list.

All packets originating from either client or daemon can be (and are, by
default) spoofed.

Detecting TFN2K – The Signature

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 agents participating in the
denial-of-service network.

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.

A simple scan for the files tfn (the client) and td (the daemon) 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 client and daemon
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:

NOTE: Scanners should look for pattern combinations unlikely to appear in
legitimate software.

TFN2K Client (tfn)

[1;34musage: %s <options>
[-P protocol]
[-S host/ip]
[-f hostlist]
[-h hostname]
[-i target string]
[-p port]
<-c command ID>
change spoof level to %d
change packet size to %d bytes
bind shell(s) to port %d
commence udp flood
commence syn flood, port: %s
commence icmp echo flood
commence icmp broadcast (smurf) flood
commence mix flood
commence targa3 attack
execute remote command

TFN2K Daemon (td)

fork
ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/
/dev/urandom
/dev/random
%d.%d.%d.%d
sh*
ksh*
command.exe**
cmd.exe**
tfn-daemon***
tfn-child***

*   Unix and Solaris systems only
**  Windows NT systems only
*** This text is likely to have been changed in many TFN2K
    installations

TFN2K Daemon and Client (tfn and td)

security_through_obscurity *
D4 40 FB 30 0B FF A0 9F **
64 64 64 64 ... ***

*   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 client and daemon, 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.

Defeating TFN2K – A Strategy

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 clients or agents.

Prevention

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.

Disallow unnecessary ICMP, TCP, and UDP traffic. Typically only ICMP type 3
(destination unreachable) packets should be allowed.

If ICMP cannot be blocked, disallow unsolicited (or all) ICMP_ECHOREPLY
packets.

Disallow UDP and TCP, except on a specific list of ports.

Spoofing can be limited by configuring the firewall to disallow any outgoing
packet whose source address does not reside on the protected network.

Take measures to ensure that your systems are not vulnerable to attacks that
would allow intruders to install TFN2K.

Detection

Scan for the client/daemon files by name.

Scan all executable files on a host system for patterns described in the
previous section.

Scan the process list for the presence of daemon processes.

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

Watch for a series of packets (possibly a mix of TCP, UDP, and ICMP) with
identical payloads.

Response

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.

TFN2K is 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.

http://www.fbi.gov/contact/fo/fo.htm

Summary

TFN2K and other DDoS attack signatures are under continuous investigation by
Axent Technologies. As more information becomes available, this document
will be updated.

Contact Information

If you have questions or comments regarding this article or other security
developments, send e-mail to securityteam () axent com.

The original HTML version of this document can be obtained at:

http://www2.axent.com/swat/swat.htm

Copyright © 2000 Axent Technologies – All Rights Reserved

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com