COMMAND
DoS
SYSTEMS AFFECTED
munices
PROBLEM
Following is based on ISS Security Alert. A new form of
Distributed Denial of Service (DDoS) attack has been discovered
following the release of the trin00 and Tribe Flood Network (TFN)
denial of service programs. For more info, see:
http://oliver.efri.hr/~crv/security/bugs/mUNIXes/dos3.html
http://xforce.iss.net/alerts/advise40.php3
These attacks are more powerful than any previous denial of
service attack observed on the Internet. A Distributed Denial of
Service attack is designed to bring a network down by flooding
target machines with large amounts of traffic. This traffic can
originate from many compromised machines, and can be managed
remotely using a client program. ISS X-Force considers this
attack a high risk since it can potentially impact a large number
of organizations. DDoS attacks have proven to be successful and
are difficult to defend against.
Over the first two months of 2000, several high-capacity
commercial and educational networks have been affected by DDoS
attacks. In addition to the trin00 and TFN attacks, two
additional tools are currently being used to implement this
attack: TFN2K and Stacheldraht. Both of these tools are based
on the original TFN/trin00 attacks described in the December ISS
Security Alert. Description of Stacheldraht can be found at:
http://oliver.efri.hr/~crv/security/bugs/mUNIXes/dos5.html
Attackers can install one of these DDoS programs (trin00, TFN,
TFN2K, or Stacheldraht) on hundreds of compromised machines and
direct this network of machines to initiate an attack against
single or multiple victims. This attack occurs simultaneously
from these machines, making it more dangerous than any DoS attack
launched from a single machine.
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
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.
* The UDP packet length (as it appears in the UDP header) is three
bytes longer than the actual length of the packet.
* The TCP header length (as it appears in the TCP header) is
always zero. In legitimate TCP packets, this value should never
be zero.
* The UDP and TCP checksums do not include the 12-byte
pseudo-header, and are consequently incorrect in all TFN2K UDP
and TCP packets.
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)
tribe_cmd
tfn-daemon
tfn-child
TFN2K Daemon and Client (tfn and td)
security_through_obscurity
D4 40 FB 30 0B FF A0 9F
64 64 64 64 ...
ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/
/dev/urandom
/dev/random
%d.%d.%d.%d
sh
ksh
command.exe
cmd.exe
The TFN2K binaries may be stripped of clear-text method and
variable names, making it difficult to definitively identify the
daemon by conventional string-based scanners.
The original HTML version of this document can be obtained at:
http://www2.axent.com/swat/swat.htm
Tfn2k asks for a password during the build, which is used to
prevent someone from recovering the password from the td or tfn
binaries. Simple Nomad wrote a program that will recover the
password. It will compile and run on Solaris and Intel-based free
Unix systems (didn't test it elsewhere). It can extract the
password from a Sol, Intel-based Linux, or Intel-based FreeBSD
binary td or tfn (also probably others but just tested these). In
other words, you can extract passwords from a Linux td binary on
your Sol 2.7 box. Uses for this include:
Scenario #1
===========
You are a hot cybersleuth, extracting the password as a part of a
forensics effort. If the password matches some other forensic
stuff (like the password of a suspected script kid, or the DES
key that unlocks a cache of hacker tools in a tar file), you
might catch that elusive cyberterrorist.
Scenario #2
===========
You have discovered a cache of tfn2k binaries on your large
network. By recovering the password, you can compile your own
tfn and send a command to be rexec'd to each suspected system,
such as:
echo "0wned!! Clean me!!" | mail yourname@youraddress.com
Optionally if you discover you are flooding someone, you could
send the command to stop the flood from your new tfn binary.
Scenario #3
===========
You are under attack and Zombie Zapper didn't help (ZZ only works
against tfn, trinoo, and stacheldraht). Send the sites attacking
you this software and ask them to send you the password. Once you
have it, compile your own tfn and start telling those zombies to
leave you alone! Okay, this last one is a little far-fetched and
won't work if the attack lasts just a couple of hours and if the
addresses are forged, but it is better than nothing.
/*
* tfn2kpass - tfn2k Password Recovery. Extract password for tfn2k from a
* td or tfn binary.
*
* Written by Simple Nomad [thegnome@razor.bindview.com] 21Feb2000
*
* More fun stuff at http://razor.bindview.com/, licensing at end
* of file.
*
* Should compile and run fine on any Intel/Sun-based system:
* gcc -o tfn2kpass tfn2kpass.c
*
* Example usage:
* ./tfn2kpass tfn-binary-file
*
* Tested against binaries compiled on Intel Linux, Intel FreeBSD, and
* Solaris. Thanks for the help, Jordan <jritter@razor.bindview.com>
* and Paul <pashton@razor.bindview.com> from the RAZOR team.
*
*/
/* includes */
#include <stdio.h>
#include <stdlib.h>
/*
* Main program....
*/
int main(int argc, char *argv[])
{
FILE *ftd;
int i, search = 0, search2, found = 0, rew = 32;
unsigned char recover[32];
unsigned char password[32];
unsigned char offset;
char close[]="@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@";
char check[sizeof(close)];
/* Say hello... */
printf("tfn2kpass - Recover the password from tfn2k's 'td' or 'tfn'\n");
printf("Comments/bugs: Simple Nomad <thegnome@razor.bindview.com>\n");
printf("http://razor.bindview.com/\n\n");
if (argc!=2)
{
fprintf(stderr,"USAGE: tfn2kpass <td_filename>\n\n");
fprintf(stderr,"EXAMPLES:\n");
fprintf(stderr," tfn2kpass renamed_td\n");
exit(-1);
}
ftd=fopen(argv[1],"rb");
if (ftd == NULL)
{
fprintf(stderr,"Unable to open file %s.\n",argv[1]);
exit(-1);
}
/* first we search the file for the first marker that we
are close to the password -- the 40 @'s should be right
after the password */
while(!feof(ftd))
{
fseek(ftd,search,SEEK_SET);
fread(&check,40,1,ftd);
if (!strncmp(check,close,40))
{
found = 1;
break;
}
search++;
}
if (found)
{
found = 0; /* reset our flag for next 'find' */
search--;
search2 = search;
/* Now we'll search backward looking for the first non-zero
value, which is the offset used to mask the password.
The amount of zeroes depends upon platform as well as the
daemon type (td or tfn), so we move back one at a time.
Also it allows us to examine daemons compiled on a freebsd
box from our linux box, for example. */
while(search2!=0)
{
fseek(ftd,search2,SEEK_SET);
fread(&offset,1,1,ftd);
/* Sol bins have the needed "offset" right before the string
of @'s as well as at the end of the password field, so we
need to skip that byte. Also, if we do not shorten the
amount of bytes for a Sol bin by one, we end up with one
extra char at the beginning of the password. Go figure. */
if((offset) && (search2 == search))
{
rew--;
}
else if(offset)
{
found = 1;
break;
}
search2--;
}
if (found) /* if we found the offset, grab and print the password */
{
fseek(ftd,search2-rew,SEEK_SET);
fread(&recover,32,1,ftd);
fclose(ftd);
for (i=0;i<32;i++) password[i]=recover[i] - offset;
printf("The password is - ");
for (i=0;i<32;i++)
{
if (isprint(password[i]))
printf("%c",password[i]);
}
printf("\n\n");
}
}
if(!found) printf("The password was not found\n\n");
exit(0);
}
/*
* BindView License -
Copyright (c) 2000 BindView Corporation. All rights reserved.
By using this software, YOU AGREE to the following license terms. IF YOU
DO NOT AGREE, YOU MAY NOT USE THE SOFTWARE.
1. BindView believes that this software is safe for use in normal
circumstances, and has performed what it believes to be reasonable but
non-exhaustive testing to verify this. The software is intended for use
only by experienced and knowledgeable computer professionals; IT IS
PROVIDED "AS IS, WITH ALL FAULTS," including source code so that the user
can study the source code and independently determine the software's
suitability. BindView makes no warranty of any kind, express or implied,
and DISCLAIMS ANY AND ALL WARRANTIES, CONDITIONS, OR IMPLIED TERM OF
QUALITY, INCLUDING THE IMPLIED WARRANTIES OF TITLE, NON-INFRINGEMENT,
MERCHANTABILITY, AND FITNESS FOR A PARTICULAR PURPOSE. All use of the
software is entirely at the user's own risk.
2. IN NO EVENT WILL BINDVIEW BE LIABLE FOR DAMAGES OF ANY KIND arising
from or relating to use of the software, whether such damages are direct,
indirect, incidental, consequential, exemplary, or any other kind, and
whether arising under contract, tort (including negligence), strict
liability, or otherwise.
3. BindView will not object to your distribution of complete, unmodified
copies of the distribution package of the software as provided by
BindView, PROVIDED that you do not charge a fee other than a reasonable
fee for distribution services. You may charge a fee for any warranty or
support services that you offer to purchasers of copies of the software.
4. You may modify the software and distribute copies of the modified
software, PROVIDED:
(a) that you distribute, together with the executable code of the
modified software:
(1) the source code of the modified software, which must
contain the BindView copyright notice set forth above (in
addition to your own copyright notice if any); and
(2) a copy of the complete, unmodified distribution
package of the software as provided by BindView; and
(b) that you clearly indicate in the source code and in an
accompanying documentation file that the software is based on
BindView's software and was modified by you; and
(c) that you grant users of the modified software the same rights
as are granted to you by this license.
*
*/
Stacheldraht consists of three parts: the master server, client,
and agent programs.
The Client:
===========
The client is used to connect to the master server on port 16660
or port 60001. Packet contents are blowfish encrypted using the
default password "sicken", which can be changed by editing the
Stacheldraht source code. After entering the password, an
attacker can use the client to manage Stacheldraht agents, IP
addresses of attack victims, lists of master servers, and to
perform DoS attacks against specified machines.
The Master Server:
==================
The master server handles all communication between client and
agent programs. It listens for connections from the client on
port 16660 or 60001. When a client connects to the master, the
master waits for the password before returning information about
agent programs to the client and processing commands from the
client.
The Agent:
==========
The agent listens for commands from master servers on port 65000.
In addition to this port, master server/agent communications are
also managed using ICMP echo reply packets. These packets are
transmitted and replied to periodically. They contain specific
values in the ID field (such as 666, 667, 668, and 669) and
corresponding plaintext strings in the data fields (including
"skillz", "ficken", and "spoofworks"). The ICMP packets act as a
"heartbeat" between agent and master server, and to determine
source IP spoofing capabilities of the master server. The agent
identifies master servers using an internal address list, and an
external encrypted file containing master server IP addresses.
Agents can be directed to "upgrade" themselves by downloading a
fresh copy of the agent program and deleting the old image as
well as accepting commands to execute flood attacks against
target machines.
The Attack:
===========
Like TFN/TFN2K, Stacheldraht can be used to perform ICMP, SYN,
and UDP flood attacks. The attacks can run for a specified
duration, and SYN floods can be directed to a set of specified
ports. These flood attacks cause the target machine to slow down
because of the processing required to handle the incoming packets,
leaving little or no network bandwidth. Possible methods for
detection of these flooding attacks are discussed in the
TFN/trin00 ISS Security Alert published December 7, 1999.
Stacheldraht runs on Linux and Solaris machines.
The source code for "stacheldraht" was published on Packet Storm:
http://packetstorm.securify.com/distributed
Below are the differences (which affect packet signatures and
some minimal strings in the binary images) between the code that
analyzed (http://oliver,efri.hr/~crv/security/munixes/dos5.html)
and the current 4.0 release. (Hmm. Jumping from 1.1 to 4.0
because of #define changes).
diff stacheldrahtV4/config.h reg-orig/config.h
11,12c11
< #define ID_SHELL 88 /* to bind a rootshell */
< #define ID_ADDR 616 /* ip add request for the flood server */
---
> #define ID_SHELL 1 /* to bind a rootshell */
14,30c13,31
< #define ID_SETPRANGE 8008 /* set port range for synflood */
< #define ID_SETUSIZE 8009 /* set udp size */
< #define ID_SETISIZE 9010 /* set icmp size */
< #define ID_TIMESET 9011 /* set the flood time */
< #define ID_DIEREQ 6663 /* shutdown request of the masterserver */
< #define ID_DISTROIT 6662 /* distro request of the master server */
< #define ID_REMMSERVER 5501 /* remove added masterserver */
< #define ID_ADDMSERVER 5555 /* add new masterserver request */
< #define SPOOF_REPLY 1016 /* spoof test reply of the master server
< #define ID_TEST 6268 /* test of the master server */
< #define ID_ICMP 1155 /* to icmp flood */
< #define ID_SENDUDP 6 /* to udp flood */
< #define ID_SENDSYN 9 /* to syn flood */
< #define ID_SYNPORT 8 /* to set port */
< #define ID_STOPIT 3 /* to stop flooding */
< #define ID_SWITCH 5 /* to switch spoofing mode */
< #define ID_ACK 4 /* for replies to the client */
---
> #define ID_ADDR 699 /* ip add request for the flood server */
>
> #define ID_SETPRANGE 2007 /* set port range for synflood */
> #define ID_SETUSIZE 2006 /* set udp size */
> #define ID_SETISIZE 2005 /* set icmp size */
> #define ID_TIMESET 2004 /* set the flood time */
> #define ID_DIEREQ 2003 /* shutdown request of the masterserver */
> #define ID_DISTROIT 2002 /* distro request of the master server */
> #define ID_REMMSERVER 2001 /* remove added masterserver */
> #define ID_ADDMSERVER 2000 /* add new masterserver request */
> #define SPOOF_REPLY 1000 /* spoof test reply of the master server
> #define ID_TEST 668 /* test of the master server */
> #define ID_ICMP 1055 /* to icmp flood */
> #define ID_SENDUDP 2 /* to udp flood */
> #define ID_SENDSYN 3 /* to syn flood */
> #define ID_SYNPORT 4 /* to set port */
> #define ID_STOPIT 5 /* to stop flooding */
> #define ID_SWITCH 6 /* to switch spoofing mode */
> #define ID_ACK 7 /* for replies to the client */
Common subdirectories: stacheldrahtV4/leaf and reg-orig/leaf
diff stacheldrahtV4/mserv.c reg-orig/mserv.c
24c24
< #define SALT "dRFWfIGlF0zrE\0"
---
> #define SALT "zAHp635Fd0u/g\0"
27c27
< #define MSERVERPORT 65512
---
> #define MSERVERPORT 16660
29c29
< #define SERVVERSION "[*]stacheldraht[*] mserver version: 4.0\n"
---
> #define SERVVERSION "[*]stacheldraht[*] mserver version: 1.1\n"
31,32c31,32
< /* masterserver handles up to 6000 bcasts */
< #define MAXBCASTS 6000
---
> /* masterserver handles up to 1000 bcasts */
> #define MAXBCASTS 1000
34c34
< #define BCASTFILENAME ".bc"
---
> #define BCASTFILENAME "bcasts"
36c36
< #define LOCALIP "193.116.54.15"
---
> #define LOCALIP "205.198.186.38"
41c41
< #define COMMANDPORT 65513
---
> #define COMMANDPORT 65000
49c49
< #define CURPROMPT "stacheldraht"
---
> #define CURPROMPT "regulate"
Common subdirectories: stacheldrahtV4/telnetc and reg-orig/telnetc
SOLUTION
ISS SAFEsuite intrusion detection solution, RealSecure, detects
the Denial of Service attacks that these distributed tools use,
providing early warning and response capabilities. RealSecure
can reconfigure firewalls and routers to block the traffic. On
some firewalls this can be as granular as blocking a particular
service or protocol port. In conjunction with the December 7,
1999 ISS Security Alert, RealSecure 3.2.1 included signatures to
detect the communications between the distributed components of
TFN and trin00. RealSecure will add signatures to detect TFN2K
and Stacheldraht in its next release, which will also include an
X-press Update capability to speed future signature deployment.