4788319 2000-02-12 01:45 /304 rader/ Postmaster
Mottagare: Bugtraq (import) <9752>
Ärende: TFN2K - An Analysis
------------------------------------------------------------
Approved-By: aleph1@SECURITYFOCUS.COM
Delivered-To: bugtraq@lists.securityfocus.com
Delivered-To: BUGTRAQ@SECURITYFOCUS.COM
X-Originating-IP: [166.70.2.118]
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <20000211201308.35807.qmail@hotmail.com>
Date: Fri, 11 Feb 2000 20:13:08 GMT
Reply-To: Jason Barlow <barlow_jason@HOTMAIL.COM>
Sender: Bugtraq List <BUGTRAQ@SECURITYFOCUS.COM>
From: Jason Barlow <barlow_jason@HOTMAIL.COM>
X-To: BUGTRAQ@SECURITYFOCUS.COM
To: BUGTRAQ@SECURITYFOCUS.COM
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 TFN2Ks 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 commands 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
0x41s (A). The actual count of 0x41s 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
(4788319) ------------------------------------------(Ombruten)