[iwar] Historical posting
From: Fred Cohen
From: fc@all.net
To: iwar@onelist.com
Mon, Jan 1, 1999
fc Mon Jan 1, 1999
Received: (from fc@localhost) by all.net (8.9.3/8.7.3) id FAA15269 for iwar@onelist.com; Tue, 18 Apr 2000 05:21:43 -0700
To: iwar@onelist.com
MIME-Version: 1.0
Mailing-List: list iwar@egroups.com; contact iwar-owner@egroups.com
Delivered-To: mailing list iwar@egroups.com
Precedence: bulk
List-Unsubscribe:
Date: Mon, Jan 1, 1999
From: Fred Cohen
Reply-To: iwar@egroups.com
Subject: [iwar] Historical posting
The following security advisory is sent to the securiteam mailing
list, and can be found at the SecuriTeam web site:
http://www.securiteam.com
Analysis of the Shaft distributed Denial of Service tool
----------------------------------------------------------------------
----------
SUMMARY
The following is an analysis of the "Shaft" distributed denial of
service
(DDoS) tool.
Denial of service is a technique to deny access to a resource by
overloading it, such as packet flooding in the network context. Denial
of
Service tools have existed for a while, whereas distributed variants
are
relatively recent. The distributed nature adds the "many to one"
relationship. Throughout this analysis, most actual host names have
been
modified or removed.
DETAILS
"Shaft" belongs in the family of tools discussed earlier, such as
Trinoo,
TFN, Stacheldraht, and TFN2K. Like in those tools, there are handler
(or
master) and agent programs. The general concepts of these tools can be
found in a Distributed Intruder Tools Workshop Report held in November
1999 at the Computer Emergency Response Team Coordination Center
(CERT/CC)
in Pittsburgh, Pennsylvania:
<http://www.cert.org/reports/dsit_workshop.pdf>
http://www.cert.org/reports/dsit_workshop.pdf
In the first two months of 2000, DDoS attacks against major Internet
sites
(such as CNN, ZDNet, Amazon etc.) have brought these tools further
into
the limelight. There are a few papers covering DDoS to be found at:
<http://packetstorm.securify.com/distributed/>
http://packetstorm.securify.com/distributed/
<http://staff.washington.edu/dittrich/misc/ddos/>
http://staff.washington.edu/dittrich/misc/ddos/
<http://www.cert.org/advisories/CA-99-17-denial-of-service-tools.html>
http://www.cert.org/advisories/CA-99-17-denial-of-service-tools.html
Analysis:
Shaftnode was recovered, initially in binary form, in late November
1999,
then in source form for the agent. Distinctive features are the
ability to
switch handler servers and handler ports on the fly, making detection
by
intrusion detection tools difficult from that perspective, a "ticket"
mechanism to link transactions, and the particular interest in packet
statistics.
Network Communication:
Client to handler(s): 20432/tcp
Handler to agent(s): 18753/udp
Agent to handler(s): 20433/udp
"Shaft" (in the analyzed version, 1.72) is modeled after Trinoo, in
that
communication between handlers and agents is achieved using the
unreliable
IP protocol <http://foldoc.doc.ic.ac.uk/foldoc/foldoc.cgi?query=UDP>
UDP.
Remote control is done via a simple telnet connection to the handler.
"Shaft" uses "tickets" for keeping track of its individual agents.
Both
passwords and ticket numbers have to match for the agent to execute
the
request. A simple letter-shifting is in use.
Commands:
The command structure is divided into the agent and handler command
syntax
groups. The attacker interacts with the handler via a command line.
Agent Command Syntax:
Accepted by agent and replies generated back to the handler:
size <size>
Size of the flood packets. Generates a "size" reply.
type <0|1|2|3>
Type of DoS to run 0 UDP, 1 TCP, 2 UDP/TCP/ICMP, 3 ICMP. Generates
a
"type" reply.
time <length>
Length of DoS in seconds. Generates a "time" reply.
own <victim>
Add victim to list of hosts to perform denial of service on.
Generates
a "owning" reply.
end <victim>
Removes victim from list of hosts (see "own" above). Generates a
"done" reply.
stat
Requests packet statistics from agent. Generates a "pktstat"
reply.
alive
Are you alive?. Generates a "alive blah" reply.
switch <handler> <port>
Switch the agent to a new handler and handler port. Generates a
"switching" reply.
pktres <host>
Request packet results for that host at the end of the flood.
Generates a "pktres" reply.
Sent by agent:
new <password>
Reporting for duty
pktres <password> <sock> <ticket> <packets sent>
Packets sents to the host identified by <ticket> number
Handler (shaftmaster) Command Syntax:
Little is known about the handler, but this is a speculation, pieced
together from clues, of how its command structure could look like:
mdos <host list>
Start a distributed denial of service attack (mdos = massive
denial of
service?) directed at <host list>. Sends out "own host" messages to
all
agents.
edos <host list>
End the above attack on <host list>. Sends out "end host" messages
to
all agents.
time <length>
Set the duration of the attack. Sends out "time <length>" to all
agents.
size <packetsize>
Set the packetsize for the attack (8K maximum as seen in source).
Sends out "size <packetsize>" to all agents.
type <UDP|TCP|ICMP|BOTH>
Set the type of attack, UDP packet flooding, TCP SYN packet
flooding,
ICMP packet flooding, or all three (here BOTH = ICMP amd IP
protocols).
Sends "type <type>" to all agents.
+node <host list>
Add new agents
-node <host list>
Remove agents from pool
ns <host list>
Perform a DNS lookup on <host list>
lnod
List all agents
ltic
List all tickets (transactions?)
pkstat
Show total packet statistics for agents. Sends out "stat" request
to
all agents.
alive
Send an "alive" to all agents. A possible argument to alive is
"hi".
stat
show status?
switch
become the handler for agents Send "switch" to all agents.
ver
show version
exit
Password protection:
After connecting to the handler using the telnet client, the attacker
is
prompted with "login:". Too little is known about the handler or its
encryption method for logging in. A clear text connection to the
handler
port is obviously a weakness.
Detection:
Binaries and their behavior:
As with previous DDoS tools, the methods used to install the
handler/agent
will be the same as installing any program on a compromised Unix
system,
with all the standard options for concealing the programs and files
(e.g.,
use of hidden directories, "root kits", kernel modules, etc.) The
reader
is referred to Dittrich's Trinoo analysis for a description of
possible
installation methods of this type of tool.
Precautions have been taken to hide the default handler in the binary
code. In the analyzed code, the default handler is defined as follows:
#define MASTER "23:/33/75/28"
which would translate into 129.22.64.17 (electrochem1.echem.cwru.edu)
using the same simple cipher mentioned above. Port numbers are munged
before actual use, e.g.
#define MASTER_PORT 20483
is really port 20433.
All these techniques intend to hide the critical information from
prying
eyes performing forensics on the code. The program itself tries to
hide
itself as a legitimate Unix process (httpd in the default
configuration).
Upon launch, the "Shaft" agent (the "shaftnode") reports back to its
default handler (its "shaftmaster") by sending a "new <upshifted
password>" command. For the default password of "shift" found in the
analyzed code, this would be "tijgu". Therefore a new agent would
send
out "new tijgu", and all subsequent messages would carry that password
in
it. Only in one case does the agent shift in the opposite direction
for
one particular command, e.g. "pktres rghes". It is unclear at the
moment
whether this is intentional or not.
Incoming commands arrive in the format:
"command <upshifted password> <command arg> <socket> <ticket>
<optional
args>"
For most commands, the password and socket/ticket need to have the
right
magic in order to generate a reply and the command to be executed.
Message flow diagram between handler H and agent A:
Initial phase:
A -> H: "new", f(password)
Running loop:
H -> A: cmd, f(password), [args], Na, Nb
A -> H: cmdrep, f(password), Na, Nb, [args]
- f(X) is the Caesar cipher function on X
- Na, Nb are numbers (tickets, socket numbers)
- cmd, cmdrep are commands and command acknowledgments
- args are command arguments
The flooding occurs in bursts of 100 packets per host, with the source
port and source address randomized. This number is hard-coded, but it
is
believed that more flexibility can be added. Whereas the source port
spoofing only works if the agent is running as a root privileged
process,
the author has added provisions for packet flooding using the UDP
protocol
and with the correct source address in the case the process is running
as
a simple user process. It is noteworthy that the random function is
not
properly seeded, which may lead to predictable source port sequences
and
source host IP sequences.
Source port = (rand() % (65535-1024)+1024) where % is the
mathematical
'mod' operator
This will generate source ports greater than 1024 at all times.
Source IP = rand()%255.rand()%255.rand()%255.rand()%255
The source IP numbers can (and will) contain a zero in the leading
octet.
Additionally, the sequence number for all TCP packets is fixed, namely
0x28374839, which helps with respect to detection at the network
level.
The ACK and URGENT flags are randomly set, except on some platforms.
Destination ports for TCP and UDP packet floods are randomized.
The client must choose the duration ("time"), size of packets, and
type of
packet flooding directed at the victim hosts. Each set of hosts has
its
own duration, which gets divided evenly across all hosts. This is
unlike
TFN which forks an individual process for each victim host. For the
type,
the client can select UDP, TCP SYN, ICMP packet flooding, or the
combination of all three. Even though there is potential of having a
different type and packet size for each set of victim hosts, this
feature
is not exploited in this version.
The author of "Shaft" seems to have a particular interest in
statistics,
namely packet generation rates of its individual agents. The
statistics on
packet generation rates are possibly used to determine the "yield" of
the
DDoS network as a whole. This would allow the attacker to stop adding
hosts to the attack network when it reached the necessary size to
overwhelm the victim network, and to know when it is necessary to add
more
agents to compensate for loss of agents due to attrition during an
attack
(as the agent systems are identified and taken off-line.)
Currently, the ability to switch host IP and port for the handler
exists,
but the listening port for the agent remains the same. It is
foreseeable
that this will change in the future.
A sample attack:
In this section we will look at a practical example of an attack
carried
out with the "Shaft" distributed denial of service attack tool, as
seen
from the attacking network perspective.
The shaftnode agent when in use, as seen by "lsof" [10]:
# lsof -c shaftnode
COMMAND PID USER FD TYPE DEVICE SIZE NODE
NAME
shaftnode 13489 root cwd VDIR 0,0 400 2
/tmp
shaftnode 13489 root txt VREG 0,0 19492 10
/tmp
(swap)
shaftnode 13489 root txt VREG 32,0 662764 182321
/usr/lib/libc.so.1
shaftnode 13489 root txt VREG 32,0 17480 210757
/usr/platform/sun4u/lib/libc_psr.so.1
shaftnode 13489 root txt VREG 32,0 566700 182335
/usr/lib/libnsl.so.1
shaftnode 13489 root txt VREG 32,0 39932 182348
/usr/lib/libw.so.1
shaftnode 13489 root txt VREG 32,0 15720 182334
/usr/lib/libmp.so.1
shaftnode 13489 root txt VREG 32,0 15720 182327
/usr/lib/libintl.so.1
shaftnode 13489 root txt VREG 32,0 68780 182342
/usr/lib/libsocket.so.1
shaftnode 13489 root txt VREG 32,0 2564 182324
/usr/lib/libdl.so.1
shaftnode 13489 root txt VREG 32,0 137160 182315
/usr/lib/ld.so.1
shaftnode 13489 root 0u inet 0x507dc770 0t116 TCP
hostname:ftp->electrochem1.echem.cwru.edu:53982 (CLOSE_WAIT)
shaftnode 13489 root 1u inet 0x507dc770 0t116 TCP
hostname:ftp->electrochem1.echem.cwru.edu:53982 (CLOSE_WAIT)
shaftnode 13489 root 2u inet 0x507dc770 0t116 TCP
hostname:ftp->electrochem1.echem.cwru.edu:53982 (CLOSE_WAIT)
shaftnode 13489 root 3u inet 0x5032c7d8 0t0 UDP
*:18753 (Idle)
As one can see, the agent is waiting to receive commands on its
default
UDP port number 18753. The TCP connection back to the handler remains
unexplained to date.
Packet flows:
Date Time Protocol Source IP/Port Flow Destination
IP/Port
Sun 11/28 21:39:22 tcp 129.22.64.17.53982 x.x.x.x.21
Sun 11/28 21:39:56 udp x.x.x.x.33198 -> 129.22.64.17.20433
Sun 11/28 21:45:20 udp 129.22.64.17.1765 -> x.x.x.x.18753
Sun 11/28 21:45:20 udp x.x.x.x.33199 -> 129.22.64.17.20433
Sun 11/28 21:45:59 udp 129.22.64.17.1866 -> x.x.x.x.18753
Sun 11/28 21:45:59 udp x.x.x.x.33200 -> 129.22.64.17.20433
Sun 11/28 21:45:59 udp 129.22.64.17.1968 -> x.x.x.x.18753
Sun 11/28 21:45:59 udp 129.22.64.17.1046 -> x.x.x.x.18753
Sun 11/28 21:45:59 udp 129.22.64.17.1147 -> x.x.x.x.18753
Sun 11/28 21:45:59 udp 129.22.64.17.1248 -> x.x.x.x.18753
Sun 11/28 21:45:59 udp 129.22.64.17.1451 -> x.x.x.x.18753
Sun 11/28 21:46:00 udp x.x.x.x.33201 -> 129.22.64.17.20433
Sun 11/28 21:46:00 udp x.x.x.x.33202 -> 129.22.64.17.20433
Sun 11/28 21:46:01 udp x.x.x.x.33203 -> 129.22.64.17.20433
Sun 11/28 21:48:37 udp 129.22.64.17.1037 -> x.x.x.x.18753
Sun 11/28 21:48:37 udp 129.22.64.17.1239 -> x.x.x.x.18753
Sun 11/28 21:48:37 udp 129.22.64.17.1340 -> x.x.x.x.18753
Sun 11/28 21:48:37 udp 129.22.64.17.1442 -> x.x.x.x.18753
Sun 11/28 21:48:38 udp x.x.x.x.33204 -> 129.22.64.17.20433
Sun 11/28 21:48:38 udp x.x.x.x.33205 -> 129.22.64.17.20433
Sun 11/28 21:48:38 udp x.x.x.x.33206 -> 129.22.64.17.20433
Sun 11/28 21:48:56 udp 129.22.64.17.1644 -> x.x.x.x.18753
Sun 11/28 21:48:56 udp x.x.x.x.33207 -> 129.22.64.17.20433
Sun 11/28 21:49:59 udp x.x.x.x.33208 -> 129.22.64.17.20433
Sun 11/28 21:50:00 udp x.x.x.x.33209 -> 129.22.64.17.20433
Sun 11/28 21:50:14 udp 129.22.64.17.1747 -> x.x.x.x.18753
Sun 11/28 21:50:14 udp x.x.x.x.33210 -> 129.22.64.17.20433
There is quite some activity between the handler and the agent, as
they go
through the command request and acknowledgement phases. There was also
what appeared to be testing of the impact on the local network itself
with
ICMP packet flooding, for which we omit the data here due to size
limitations.
Let us look at the individual phases from a later attack.
Setup and configuration phase:
date time src dest dest-port
command
4 Dec 1999 18:06:40 129.22.64.17 x.x.x.x 18753 alive
tijgu hi 5 8170
4 Dec 1999 18:09:14 129.22.64.17 x.x.x.x 18753 time
tijgu
700 5 6437
4 Dec 1999 18:09:14 x.x.x.x 129.22.64.17 20433 time
tijgu
5 6437 700
4 Dec 1999 18:09:16 129.22.64.17 x.x.x.x 18753 size
tijgu
4096 5 8717
4 Dec 1999 18:09:16 x.x.x.x 129.22.64.17 20433 size
tijgu
5 8717 4096
4 Dec 1999 18:09:23 129.22.64.17 x.x.x.x 18753 type
tijgu
2 5 9003
The handler issues an "alive" command, and says "hi" to its agent,
assigning a socket number of "5" and a ticket number of 8170. We will
see
that this "socket number" will persist throughout this attack. A time
period of 700 seconds is assigned to the agent, which is acknowledged.
A
packet size of 4096 bytes is specified, which is again confirmed. The
last line indicates the type of attack, in this case "the works", i.e.
UDP, TCP SYN and ICMP packet flooding combined. Failure to specify the
type would make the agent default to UDP packet flooding.
Now the list of hosts to attack and which ones they want statistics
from on completion:
date time src dest dest-port
command
4 Dec 1999 18:09:24 129.22.64.17 x.x.x.x 18753 own
tijgu
207.229.143.6 5 5256
4 Dec 1999 18:09:24 x.x.x.x 129.22.64.17 20433 owning
tijgu 5 5256 207.229.143.6
4 Dec 1999 18:09:24 129.22.64.17 x.x.x.x 18753 pktres
tijgu 207.229.143.6 5 1993
4 Dec 1999 18:09:24 129.22.64.17 x.x.x.x 18753 own
tijgu
24.7.231.128 5 78
4 Dec 1999 18:09:24 129.22.64.17 x.x.x.x 18753 pktres
tijgu 24.218.58.101 5 8845
4 Dec 1999 18:09:24 129.22.64.17 x.x.x.x 18753 own
tijgu
18.85.13.107 5 6247
4 Dec 1999 18:09:25 129.22.64.17 x.x.x.x 18753 own
tijgu
24.218.52.44 5 4190
4 Dec 1999 18:09:25 129.22.64.17 x.x.x.x 18753 own
tijgu
207.175.72.15 5 2376
4 Dec 1999 18:09:25 x.x.x.x 129.22.64.17 20433 owning
tijgu 5 78 24.7.231.128
4 Dec 1999 18:09:26 x.x.x.x 129.22.64.17 20433 owning
tijgu 5 6247 18.85.13.107
4 Dec 1999 18:09:27 x.x.x.x &
Now that all other parameters are set, the handler issues several
"own"
commands, in effect specifying the victim hosts. Those commands are
acknowledged by the agent with an "owning" reply. The flooding occurs
as
soon as the first victim host gets added. The handler also requests
packet
statistics from the agents for certain victim hosts (e.g. "pktres
tijgu
207.229.143.6 5 1993"). Note that the reply comes back with the same
identifiers ("5 1993") at the end of the 700 second packet flood,
indicating that 51600 sets of packets were sent. One should realize
that,
if successful, this means 51600 x 3 packets due to the configuration
of
all three (UDP, TCP, and ICMP) types of packets. In turn, this results
in
roughly 220 4096 byte packets per second per host, or about 900
kilobytes
per second per victim host from this agent alone, about 4.5 megabytes
per
second total for this little exercise.
Note the reverse shift ("shift" becomes "rghes", rather than "tijgu")
for
the password on the packet statistics.
Detection at the network level:
Scanning the network for open port 20432 will reveal the presence of a
handler on your LAN.
For detecting idle agents, one could write a program similar to George
Weaver's trinoo detector. Sending out "alive" messages with the
default
password to all nodes on a network on the default UDP port 18753 will
generate traffic back to the detector, making the agent believe the
detector is a handler.
This program does not provide for code updates (like TFN or
Stacheldraht).
This may imply "rcp" or "ftp" connections during the initial intrusion
phase.
The program uses UDP traffic for its communication between the
handlers
and the agents. Considering that the traffic is not encrypted, it can
easily be detected based on certain keywords. Performing an "ngrep"
for
the keywords mentioned in the syntax sections (3.3.1 and 3.3.2), will
locate the control traffic, and looking for TCP packets with sequence
numbers of 0x28374839 may locate the TCP SYN packet flood traffic.
Source
ports are always above 1024, and source IP numbers can include zeroes
in
the leading octet.
Strings in this control traffic can be detected with the "ngrep"
program
using for example:
# ngrep -i -x "alive tijgu" udp
# ngrep -i -x "pktres|pktstat" udp
will locate the control traffic between the handler and the agent,
independently of the port number used.
There are also two excellent scanners for detecting DDoS agents on the
network: Dittrich's "dds" and Brumley's "rid".
"dds" was written to provide a more portable and less dependant means
of
scanning for various DDoS tools. Due to time contraints during coding,
"dds" does not have the flexibility necessary to specify arbitrary
protocols, ports, and payloads. A modified version of "dds", geared
towards detecting only "Shaft" agents, is included in the Appendix.
A better means of detecting "Shaft" handlers and agents would be to
use a
program like "rid", which uses a more flexible configuration file
mechanism to define ports, protocols, and payloads.
A sample configuration for "rid" to detect the "Shaft" control traffic
as
described:
start shaft
send udp dport=18753 data="alive tijgu hi 5 1918"
recv udp sport=20433 data="alive" nmatch=1
end shaft
Defenses:
A defense that can be used for example is, rate-limiting is considered
effective against ICMP packet flooding attacks, while anti-spoof
filters
and egress filters at the border routers can limit the problems caused
by
attacking agents faking source addresses.
Conclusion:
"Shaft" is another DDoS variant with independent origins. The code
recovered did appear to be still in development. Several key features
indicate evolutionary trends as the genre develops. Of significance is
the
priority placed on packet generation statistics that allow host
selection
to be refined. The analysis of the code and binary was greatly
enhanced by
the capture of attack preparation and command packets. The captured
packets made it possible to assess the impact of a single agent that
managed to saturate the network pipe.
The version analyzed had hooks that would allow for dynamic changes to
the
master host and control port but not the agent control port. However
such
items are trivially incorporated and must not be taken to be
indicative of
any current versions that may be in active use. The obfuscation of
master
IP, ports and passwords used a relatively simple form of encryption
but
this could easily be strengthened.
The detection of DDoS installations will become very much more
difficult
as such metamorphosis techniques progress, the presence of such agents
will still be more readily determined by analysis of traffic anomalies
with a consequent pressure on time and resources for site
administrators
and security teams.
ADDITIONAL INFORMATION
The article was written by: <mailto:spock@S... Sven
Dietrich.
========================================
This bulletin is sent to members of the SecuriTeam mailing list.
To unsubscribe from the list, send mail with an empty subject line and
body to: list-unsubscribe@s...
In order to subscribe to the mailing list, simply forward this email
to: list-subscribe@s...
====================
DISCLAIMER:
The information in this bulletin is provided "AS IS" without warranty
of any kind.
In no event shall we be liable for any damages whatsoever including
direct, indirect, incidental, consequential, loss of business profits
or special damages.
Det. Robert W. Miller
Colorado Internet Crimes Against
Children Task Force
Pueblo High Tech. Crime Unit
Pueblo County Sheriff's Office
909 Court St.
Pueblo, CO. 81003
Tel (719)583-4736
FAX (719)583-4732
mailto:snooker@i...
mailto:cicactf@i...
http://www.co.pueblo.co.us/sheriff/
PGP key available at: http://pgpkeys.mit.edu:11371/
search on snooker@i...