Background Reading - Electrical and Information Technology

Transcription

DDoS in Experimental Environment
Johan Haleby
Franz Levin
Department of Information Technology
Lund University
Advisor: Ben Smeets
15th July 2005
Printed in Sweden
E-huset, Lund, 2005
Abstract
Distributed Denial of Service (DDoS) attacks have been a threat to Internet
services for the last couple of years. Massive distributed and distributed
reflective DoS attacks have the potential to cause major disruption of Internet
functionality and availability even to the extent as concerning backbones. It
is important for companies and institutions to maintain an accurate network
configuration and knowledge to be able to take appropriate actions to reduce
the risk of such an attack. This thesis focuses on how to setup and configure a
test environment for these kinds of attacks to facilitate learning and simulate
attacks within a LAN. The thesis also includes topics on what can be done
to prevent DDoS attacks as well as a detailed look at different techniques to
perform such attacks.
i
ii
Preface
This master thesis was performed at the Department of Information Technology at Lund Institute of Technology. We would like to thank all people who
supported us in the making of this thesis. Especially our advisor Ben Smeets
who provided us with hints and tips. A big thanks is also sent to Morgan
Persson, also at the Department of Information Technology, for his help on
several issues. At last but not least, we would like to thank Bertil Lindvall
and Mats Cedervall.
Johan Haleby and Franz Levin
iii
iv
Contents
1
2
3
Background
1.1 Introduction .
1.2 Purpose . . .
1.3 Scope . . . .
1.4 Project goals
1.5 Outline . . .
1.6 Timetable . .
TCP
2.1
2.2
2.3
2.4
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
1
1
1
2
2
3
and Raw Sockets
TCP connection establishment
Raw Sockets . . . . . . . . .
Raw Sockets in Unix . . . . .
Raw Sockets in Windows . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5
5
6
6
7
Attacks
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
11
11
12
14
15
15
16
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
System resource consuming Denial of Service
3.1 TCP/SYN flood . . . . . . . . . . . . . .
3.2 Teardrop . . . . . . . . . . . . . . . . . .
3.3 Ping of Death . . . . . . . . . . . . . . . .
3.4 Winnuke . . . . . . . . . . . . . . . . . .
3.5 Pepsi Attack . . . . . . . . . . . . . . . .
3.6 Mail bombing . . . . . . . . . . . . . . . .
4
Bandwidth consuming denial of Service Attacks
17
4.1 Distributed Denial of Service Attacks . . . . . . . . . . . . . . . 17
4.2 Distributed Reflective Denial of Service Attacks . . . . . . . . . . 19
4.3 Non distributed bandwidth consuming DoS Attacks . . . . . . . 22
5
Defending against Denial of Service Attacks
v
23
5.1
5.2
5.3
5.4
5.5
5.6
6
7
DoS proof TCP/IP stack
Ingress filtering . . . . .
Egress filtering . . . . .
Change of IP address . .
Additional resources . .
Conclusion . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
23
24
26
26
27
27
Tracing Denial of Service Attacks
6.1 Actively querying routers about traffic they forward .
6.2 Logging-based IP traceback . . . . . . . . . . . . .
6.3 Probabilistic Packet Marking (PPM) scheme . . . .
6.4 iTrace . . . . . . . . . . . . . . . . . . . . . . . . .
6.5 Intention-Driven iTrace (ID-iTrace) . . . . . . . . .
6.6 Caddie Message Generation . . . . . . . . . . . . .
6.7 IPSec-Based Source Tracing . . . . . . . . . . . . .
6.8 Conclusion . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
29
29
29
30
31
32
33
36
39
Denial of Service applications
7.1 Trinoo . . . . . . . . . . . .
7.2 Tribe Flood Network . . . .
7.3 Stacheldraht . . . . . . . .
7.4 Comparison and conclusion .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
41
41
42
44
46
Denial of Service
Control Center .
Zombie . . . . .
Misc . . . . . . .
using SYN
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Cookies
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
8
Our
8.1
8.2
8.3
application
47
. . . . . . . . . . . . . . . . . . . . . . . . . . 47
. . . . . . . . . . . . . . . . . . . . . . . . . . 47
. . . . . . . . . . . . . . . . . . . . . . . . . . 48
9
Test scenario
53
9.1 The test environment . . . . . . . . . . . . . . . . . . . . . . . . 53
9.2 The tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
10 Discussion
97
11 Abbreviations
99
Bibliography
101
A EthernetII Packet
105
B ARP packet
107
vi
C IP datagram
109
D ICMP packet
111
E
UDP datagram
113
F
TCP segment
115
G Manual for the Control Center and Zombie application
117
G.1 Control Center . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
G.2 Zombie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
123
H Class Diagrams
H.1 Control Center Class Diagram . . . . . . . . . . . . . . . . . . . 123
H.2 Zombie Class Diagram . . . . . . . . . . . . . . . . . . . . . . . 124
vii
viii
List of Figures
2.1
2.2
2.3
TCP connection establishment . . . . . . . . . . . . . . . . . .
Unix TCP/IP stack . . . . . . . . . . . . . . . . . . . . . . . .
Windows TCP/IP stack . . . . . . . . . . . . . . . . . . . . . .
3.1
3.2
DoS Attack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
The concept of a legitimate and a malicious fragment concatenation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.1
4.2
4.3
DDoS attack using zombies . . . . . . . . . . . . . . . . . . . . 18
Distributed reflective TCP/SYN DoS attack . . . . . . . . . . 20
Smurf attack . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
5.1
Server initial TCP sequence number . . . . . . . . . . . . . . . 23
6.1
The different modes available in the Caddie Message Generation scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A brief comparison of iTrace, ID-iTrace, and Caddie Message
Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The concept of CutSet . . . . . . . . . . . . . . . . . . . . .
The secure tunnels between the routers which exposes the attacker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
An illustration on how PHIL switching can be used to traceback an attack . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2
6.3
6.4
6.5
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 35
. 35
. 37
. 39
. 40
7.1
7.2
7.3
7.4
7.5
A trinoo network . . . . . . . . . .
Ports used in standard configuration
A TFN network . . . . . . . . . . .
A stacheldraht network . . . . . . .
Ports used in standard configuration
8.1
Memory layout of the value 0x12345678 in big and little endian 49
9.1
Captured packets in a smurf attack . . . . . . . . . . . . . . . 60
ix
. . . . . .
of trinoo
. . . . . .
. . . . . .
of trinoo
5
8
9
.
.
.
.
.
41
42
43
44
45
9.2
9.3
9.4
9.5
9.6
9.7
9.8
9.9
9.10
9.11
9.12
9.13
9.14
9.15
9.16
9.17
9.18
9.19
9.20
9.21
9.22
9.23
9.24
9.25
When using two Zombies in the smurf attack, more request
packets were generated . . . . . . . . . . . . . . . . . . . . . .
High throughput to all Windows hosts but nothing was returned
The responding units . . . . . . . . . . . . . . . . . . . . . . .
Different data sizes caused different behaviors in Windows. . .
The CPU utilization at the victim reached to about 100%
when receiving a large amount of packets per second which is
not the primary intention of the ICMP Ping attack . . . . . .
About 97 Mbit per second of bogus data was sent to the victim.
CPU utilizations with different intervals by the LAND attack .
A screenshot of Ethereal when capturing the SNMP traffic
generated by the Zombie to and from the switch. . . . . . . . .
PRTG lost contact with the switch due to all the bogus SNMP
traffic. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The infamous bluescreen after executing a WinNuke attack. .
3 Zombies and 3 reflectors with 1408 bytes of data was enough
to cause a distributed reflective ICMP DoS attack . . . . . . .
A legitimate ping test shows that some packets get through
even though the inbound network utilization is close to 100% .
2 computers each running 2 Zombies and 4 reflectors was
enough to cause a total distributed reflective ICMP DoS attack
An example of how to initialize a successfull distributed reflective ICMP attack . . . . . . . . . . . . . . . . . . . . . . . . .
2 Zombies flooding and 2 victims flooding between themselves
was enough for an ICMP Bounce DoS attack. . . . . . . . . .
PRTG screenshot where 3 Zombies flooding with 4000 pps
each, causing denial of service. . . . . . . . . . . . . . . . . . .
PRTG screenshot where 4 Zombies flooding on two computers
with about 4000 pps per Zombie, causing denial of service. . .
An extract of ping replies between two VMware 4.5 hosts . . .
Ethereal saw a multiplication of requests which explains the
extra reply packet . . . . . . . . . . . . . . . . . . . . . . . . .
A screenshot from TcpView by SysInternals. All ”SYN RCVD”
states are half open TCP connections. . . . . . . . . . . . . . .
Approximately 3300 TCP/SYN packets per second was sent
to the victim. . . . . . . . . . . . . . . . . . . . . . . . . . . .
An extract of the netstat command in Knoppix while the host
was under a TCP/SYN attack. . . . . . . . . . . . . . . . . . .
Packets captured in Ethereal. . . . . . . . . . . . . . . . . . . .
Packet rate for each computer in the setup when exposed to
the attack. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
x
61
62
63
63
65
66
68
69
70
72
73
74
75
76
77
78
79
80
80
82
83
84
85
87
9.26 An example of how to initialize a distributed reflective TCP/SYN
attack. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.27 The Sygate firewall detected a Ping of Death attack . . . . . .
9.28 The ramdisk created by the Windows 95A boot loader that
occupied drive A: . . . . . . . . . . . . . . . . . . . . . . . . .
9.29 In discordance with Ethereal, Tcpdump found that 8 bytes
were missing in the packet . . . . . . . . . . . . . . . . . . . .
9.30 The error message displayed in VMware 4.5.2 after the PoD
attack was executed with a packet size of 65525 bytes . . . . .
9.31 Ethereal was used to see that the packets received were really
fragmented . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.32 A comparison between the CPU and network utilization of the
Teardrop flood (the two topmost figures) and distributed UDP
Flood (the two bottom most figures) . . . . . . . . . . . . . .
G.1
G.2
G.3
G.4
Control Center startup arguments . .
Default attack parameter values . . .
Zombie startup arguments . . . . . .
Zombie initialized with an ICMP ping
xi
. . . .
. . . .
. . . .
attack
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
88
89
90
92
92
93
94
117
120
120
121
xii
Chapter
1
Background
1.1 Introduction
Attacks on computer systems such as DoS attacks have been and are still a
big threat to Internet services and availability. A wisely configured network
of hacked machines remotely controlled by a single person may cause big
financial damage to large sites.
This thesis describes some of the DoS attack techniques that are used
today and also some of yesterday’s. The thesis also presents methods of
defending as well as different schemes that may be used to trace back these
kinds of attacks. A DoS application that supports some of the old attacks as
well as some of the new are also implemented for experimental purposes. The
implemented attacks are also tested in a test environment. The outcome will
be used as a foundation for a new course in Computer Security.
1.2 Purpose
The purpose of this thesis is to simulate real DoS attacks in a test environment
as well as presenting some of the techniques that may be used to trace back or
defending against an attack. The outcome should be used as a foundation for
a laboratory experiment in an upcoming Computer Forensics course at Lund
Institute of Technology.
1.3 Scope
The implemented DoS application should work in the given test environment
to the greatest extent possible. Due to time restrictions only the most significant traceback and defending techniques will be presented in the thesis with
1
2
Background
reasonable detail. Covering all available techniques in the smallest of detail
is not possible and probably not even desirable.
1.4 Project goals
One goal of this project is to have a fully operating DoS application that
will support numerous DoS attacks. Another goal is to present facts and
background information about various attacks as well as traceback techniques
and ways of defending against an attack.
1.5 Outline
This thesis is divided into 7 parts. The first part (Chapters 1 and 2) presents
the background for the thesis as well as an introduction to raw sockets and why
they are important in a DoS application. The second part (Chapters 3 and 4)
deals with different kinds of DoS attacks. The third part (Chapters 5 and 6)
is about defence and traceback techniques. The fourth part (Chapters 7 and
8) presents different real DoS attack networks as well as our DoS application
for experimental environments. The fifth part (Chapter 9) describes the test
scenario and the problems encountered while using our DoS application in
the test environment. The sixth part (Chapter 10) presents a discussion of
the outcome and possible future improvements. The last part is the appendices describing protocol packets, the manual for our DoS application, class
diagrams, and program listings.
Week
Start
Abstract
Choice of objection
DDoS research
TCP research
Diary
Objection completed
Coding start
Coding complete
Assembly of the whole report
Report ready for objection
Presentation
Report completed
Work on report
Class diagram
Programming
Test, LAND
Test, WinNuke
Test, PoD2
Test, Smurf
Test, Distributed ICMP Ping
Test, ICMP Ping Bounce
Test, Distributed UDPFlood
Test, Distributed
Reflective ICMP Ping
Test, TCP/SYN
Test, Pepsi
Test, Teardrop
Test, Fraggle
Test, Distributed
Reflective TCP/SYN
1.6 Timetable
5
x
x
x
x
4
x
Ti
x
x
x
x
x
x
x
x
6
x
x
x
x
x
x
8
x
7
x
x
x
9
x
x
x
x
10
x
x
x
x
11
x
x
x
x
12
x
x
x
13
x
x
x
14
x
x
x
15
x
x
x
x
x
16
x
x
x
x
x
x
17
x
x
x
x
x
18
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
20
19
x
x
x
x
x
x
x
x
21
x
x
x
x
x
x
x
x
x
22
x
x
x
x
x
x
x
23
x
x
x
x
x
x
24
x
x
x
x
x
x
25
x
x
x
x
1/7
x
x
x
26
x
x
x
x
x
x
27
x
x
15/7
x
x
28
22/7
x
x
29
Background
3
4
Background
Chapter
2
TCP and Raw Sockets
2.1 TCP connection establishment
This may be a well known topic for the reader but since it is of great importance for the understanding of this article, the TCP initiation phase will be
presented here as a reminder.
Although a client-server application usually initiates its session with a
client inquiring the server for permission to connect, it is possible to establish
a connection in different ways. In a more general application not based on
the client-server model it is possible for both parties to initiate a connection
at the same time. Because of this, a connection is established by using a
three-way handshake procedure as seen in Figure 2.1 [1].
Figure 2.1: TCP connection establishment
1. The TCP client sends a connection request packet known as a SYN
packet (a TCP/IP packet with the SYN flag set) to the server on a
specific port.
5
6
TCP and Raw Sockets
2. The TCP server receives the SYN packet and responds with an acknowledgement packet known as an ACK packet (a TCP/IP packet with the
ACK and SYN flag set) to initiate a connection in the returning direction. The packets returned include information specifying the source
and destination IPs as well as source and destination ports. This will
indicate to the client that the server is willing to start a TCP session
and also that a round trip path exist between the two participants. If
the server was unable or unwilling to process the clients connection request an RST/ACK (Reset Acknowledgement) packet or an ICMP port
unreachable packet is sent to inform the client that the connection was
denied if the port was configured to reject packets. It is also possible
to silently discard a packet by configuring a port as blocked.
3. When the client receives the SYN+ACK packet it replies with a new
ACK packet. This tells the client that a two way TCP connection has
been established. When the server receives the last ACK packet it gets
a similar confirmation. By now both client and server have setup a
connection and data is ready to be sent or received in both directions
[2].
2.2 Raw Sockets
A vital part for a person performing an attack is to remain anonymous and
untraceable to the greatest extent possible. There are numerous ways to
complicate the task of tracing the origin of an attack after it has been utilized.
Using a stolen dial-up connection to the internet in a combination with hacked
shell accounts is just one effective way to disguise oneself. Another way is for
the attacker to create his own TCP/IP packets where the source ip is spoofed
(falsified). This is where raw sockets become a vital part of any DoS attack
application. Only by using raw sockets is it possible to spoof the source IP
of a TCP package. By setting the source IP to be an arbitrary IPv4 address
makes finding the perpetrator of the attack extremely difficult. If combined
with other ”disguise techniques” as the ones mentioned above it becomes
virtually impossible to locate the attacker.
2.3 Raw Sockets in Unix
In 1981 The Computer Systems Research Group (CSRG) at the University
of California made it possible to connect Unix to the Internet. They did this
by implementing a TCP/IP stack as illustrated in Figure 2.2 into the Unix
environment. They also created an abstraction of the complex underlying
TCP and Raw Sockets
7
protocols called sockets. The purpose was to simplify the task of creating applications that needed access to Internet communication. They did retain the
option to create and use the so called raw socket for the purpose of research.
A full raw socket can be seen as a shortcut (which ignores the TCP/IP stack)
to directly access the underlying network data transport layer[3].
Many Unix and Linux distributions today supports the use of Raw sockets.
Since it is possible to disregard the TCP/IP stack it is possible for Unix and
Linux users to implement their own protocol on top of IPv4. A user must be
given root access (effective user id 0) to be able to make use of raw sockets.
Raw sockets use the standard address structure defined in IPv4 [5].
2.4 Raw Sockets in Windows
The raw socket implementation in most versions of Windows does not reach
beyond the IP protocol level. It is still possible to create functional utility
packets such as ICMP echo requests, but they will have no access to the
physical lower level of Internet. There are some versions of Windows which
do implement full raw socket support. These are Windows 2000, Windows
2003 Server and Windows XP prior to service pack 2. For reasons described
earlier, full raw socket support was retained in the release of the second service
pack. It is still possible to get full raw socket support in a Windows version
not supporting it from scratch. Certain device drivers can be created to
bypass the Windows blocking mechanisms [2]. But despite what is being
said in [2], a Windows application called Winject can be used under several
Windows environments to bypass the security mechanisms and use raw sockets
[8]. There is also an open source library for packet capture and network
analysis called WinPcap that can be used to gain access to raw sockets under
Windows 95, 98, ME, NT, 2000, XP and 2003 [49]. There are no known DDoS
applications utilizing this kind of technique today [2].
8
TCP and Raw Sockets
Figure 2.2: Unix TCP/IP stack
TCP and Raw Sockets
9
Figure 2.3: Windows TCP/IP stack
10
TCP and Raw Sockets
Chapter
3
System resource consuming Denial of
Service Attacks
The goal of any DoS attack is to make a computer system or network unreachable for its user, thus having these users denied of service. One way to
achieve this is by overloading the resources of the attacked system [4]. There
are several different attacks available. Many of these are quite old and are
not working in the modern operating systems of today. But to know about
what may emerge in the future, it is important to know about the past.
3.1 TCP/SYN flood
Figure 3.1: DoS Attack
11
12
System resource consuming Denial of Service Attacks
When a server receives a SYN packet from a proposed client to initiate
the connection sequence, it allocates resources and data about the client. For
instance memory buffers used for the transmission of data and in most cases
are also information about the client, such as IP address and port number
used, stored in a log file. Thinking about this for a moment, one can probably
figure out that the resources allocated are of a limited nature and should be
able to be abused if no protection mechanism is installed on the server. This
is exactly what a malicious hacker can take advantage of. As we just saw, the
use of raw sockets may contribute to the use of a spoofed source IP address
from the client side. Utilizing the technique of having the IP address set
as an arbitrary one, the SYN+ACK package sent in step 2 in Section 2.1 in
response to the previously sent SYN package from the client will not reach the
real client computer system. No real connection will then be available, only
a so called half open one. There is no way for the server to know that the IP
address from the client was spoofed and therefore it need to treat it like any
other non abusive connection initiation. In other words it needs to allocate
the necessary resources, wait a while for the client to respond and then resend
the SYN+ACK packet up till three times1 , believing the package may have
been lost in transmission. But if the client repeats sending SYN packages
fast enough, the server will accumulate all the half open connections and its
resources will eventually be exhausted. This will lead to the maximum number
of half open connection will be reached. But since these are all ”fake” half
open connections, new legitimate users of the server will have to be denied. A
denial of service point has been reached. It is possible that a single computer,
even with a slower connection speed than the exposed computer, can cause
this denial of service phenomenon [2]. In most cases the attack does not
concern existing connections to the server but only the new ones. However,
in some cases, the system may exhaust memory or crash [21]. It is possible
to protect a system from this kind of attack. This is discussed in detail in
Section 5.1 on page 23.
3.2 Teardrop
The goal of this attack is to send a maliciously fragmented UDP packet whose
offset and payload is constructed in such a way that it does not overlap the
endpoint of the previous fragment sent. If the OS is not patched it will
most likely crash. Since this is a really old and well known attack, no modern
operating systems are vulnerable to this attack and patches have been released
to the old ones. When this exploit was first found, all Linux systems were
1
According to [2], but our own experiments showed that a Linux host resends
SYN+ACK packets 6 times. More on this in Section 9.2.11 on page 84
13
vulnerable as well as Windows 95 and Windows NT 4. The reason for the
crash is that when the OS kernel reassembles the IP fragments to form the
original IP datagram, it runs in a loop, copying the payload from all the
queued fragments into a newly allocated buffer. While it does check to see if
the fragment length is too large, which would have the kernel copy too much
data, it does not check to see if the fragment length is too small, which would
have the kernel copy way too much data. It will work fine if the current
fragment’s offset is inside the end of a previous fragment (overlap) and its
payload reaches beyond the end of the previous packet. The topmost picture
in Figure 3.2 describes this behavior. The striped part of the new fragment
(striped+dotted is the whole new fragment) is overlapping a previous fragment
so the part being outside the endpoint is concatenated to the previous (gray)
fragment. The striped part of the new fragment is discarded since the data
←→
Added part from fragment
←→
Negative packet length
Figure 3.2: The concept of a legitimate and a malicious fragment concatenation
contained in that part have already been received earlier. Problems occur
when the payload of the new fragment is not large enough to cross the endpoint
of the previous fragment as seen in the bottom most picture of Figure 3.2.
The reason why is that an unpatched kernel only wants to concatenate the
part of the new fragment that is outside the endpoint of the previous one
(i.e. the dotted part in the top most picture of Figure 3.2). Therefore it
copies the part that is equal to the new fragment endpoint − the old fragment
endpoint. In normal scenarios this works fine since it will always return a
positive integer value for memcpy() to copy. But if the endpoint of the new
fragment does not overlap the endpoint of the previous packet due to a too
14
small payload (such as the striped fragment in the bottom most picture in
Figure 3.2), the value of the subtraction will be negative. Since memcpy()
expects an unsigned integer, the negative value will result in a wrap-around
of the lower bound of the 32 bit integer and therefore memcpy() will end up
copying extremely much data resulting in a reboot or a halt, depending on
the amount of physical memory present [36].
3.3 Ping of Death
In a ping of death attack the attacker attempt to destabilize an operating
system by sending an ICMP Echo Request (ping) packet with an oversized
total packet size. This means greater than 65535 bytes including the header
length [10, 16]. Sending packets this large is not possible in most operating
system with the exception of Windows 95 and Windows NT 3.51 or 4. But
a problem emerge since it is possible to manually build fragmented packets
that, when reassembled, have a total packet length greater than 65535 bytes.
The fragmentation of packets is a fundamental part of the Internet architecture. Packets that contains a payload greater than the maximum size the
underlying layer can handle (the MTU) are fragmented into smaller packets,
which are then reassembled by the receiver. For ethernet style devices, the
MTU is typically 1500 bytes. An ICMP Echo Request packet (the ICMP
header is embedded in the IP packet) can have a maximum payload of totally
65535−IP header size−ICMP header size= 65535−20−8 = 65507 bytes. The
fragmentation relies on an offset value in each fragment to determine where
the individual fragment goes upon reassembly. Thus in the last fragment, it
is possible to combine a valid offset with a suitable fragment size such that
(offset+size) > 65535 bytes. Since typical machines do not process the packet
until they have all fragments and have tried to reassemble it, there is the
possibility for overflow of 16 bit internal variables, which is the reason why
too much memory has to be copied resulting in that the operating systems
may crash or reboot or something similar. Note that it is possible to use
other packet types than just ICMP to make use of the fragmentation bug.
Malformed TCP and UDP packets will work just as well [35].
To protect against this attack one can block the ICMP Echo requests
by using a firewall. The backside of this is of course that valid ICMP Echo
requests are ignored. Patches have though been available for years [10, 16].
There is also a second version of the ping of death attack. Instead of
sending just one 64k ICMP packet which becomes fragmented, the ping of
death 2 attack sends a cluster of 64k packets which are all fragmented. This
also causes Windows and some Linux hosts to lock up or crash. An OS able
to protect from a normal ping of death attack may still be vulnerable to this
15
attack. To protect oneself from this annoyance, another hotfix from Microsoft
must be installed [14]. The hotfix was also implemented into the new service
packs of the concerned systems [15].
3.4 Winnuke
In June of 1997 a new kind of remote DoS attack exploited a bug in the Windows 95 and Windows NT systems [11]. This DoS attack was called Winnuke.
The exploit sent a string of out of bound data to the victims computer on
port 139 exposing programming flaws. This led to the infamous bluescreen
and ultimately caused the system to crash [11, 12]. A reboot was necessary
for continued use of the network. Microsoft responded quickly to this threat
by releasing so called hotfixes (patches). The original version of Winnuke will
hardly be seen as a threat by today’s standards but there is a new version of
Winnuke functioning on systems such as Windows XP SP 1, Windows 2000
up till SP3, Windows NT and some versions of .NET. It operates on port 139
used by NetBIOS and port 445 used by Active Directory. What happens in
an attack is that a specially crafted Server Message Block (SMB) packet is
sent to one of the ports [11]. This is the protocol that Microsoft uses to share
files, printers and serial ports. In a network environment where the server provides files and resources to clients, clients can make SMB requests to request
resources from the server and the server make SMB responses to the client.
When the malformed packet request is sent to an unpatched host, a denial
of service state may be reached since the computer may stop responding and
hang. It is possible for an attacker to use both user accounts and anonymous
access to carry out the attack.
To be protected from this kind of attack a hotfix (MS02-045) from Microsoft has to be downloaded and installed. The update is also included in
most of the latest service packs for the respective operating systems [13].
Though it is not yet fixed in the latest version of the service pack (6a) to
Windows NT 4. Another way of protection is to install a firewall and have it
block ports 135 to 139 and 445 from being used from the Internet. To really
be safe, both methods should be applied [11].
3.5 Pepsi Attack
This is a form of UDP flooding directed at harming network devices and especially Internet Service Providers by transmitting a large number of spoofed
UDP packets, such as echo request (SNMP packets), to the diagnostic port
of the network device [17, 18]. If the amount of UDP packets sent is large
16
enough, all CPU resources will be consumed serving bogus requests and no
valid requests can get through.
There are a couple of different ways to defend against this attack. One
thing to do is to disable the UDP diagnostic ports or have them secured by a
firewall. The drawback of this is obvious [18].
3.6 Mail bombing
Mail bombing is something that is typically quite easy to execute. What happens is that the attacker sends thousands of e-mails to a single mail account.
It is usually pretty harmless but if the attack is well coordinated, for instance
distributed, the SMTP (mail) server can be filled up. The most serious thing
about this attack usually is that lots of time is wasted for a person to single out which mails are bogus mail and which are not. The purpose for the
attack is not primarily to consume the bandwidth of the victim (although it
is possible) but rather to fill up hard disk space and take up peoples time
[19]. The normal approach for executing an attack is that a zombie trojan is
installed on a host. When an attack is launched the zombie is called remotely
and the infected host is used as a mail server and sends e-mails directly to the
recipients. Because of this it has been pretty easy to block machines flooding
e-mails.
A new kind of e-mail bombing have emerged though. Here the zombie
uses the mail server of its ISP to send the spam. The problem now is that it
is very impractical to block mail with domain names from large ISPs since this
will also block lots of legitimate e-mails as well. ISPs around the world are
trying to deal with this problem which is predicted to increase in the future.
For instance, some ISPs have blocked relay ports such as port 25 to stop
spammers from spreading mails from servers operated from home. Others
say they have implemented safeguards in the form of SMTP authentication
servers and rerouting of legitimate e-mail to decrease the flow [20].
Chapter
4
Bandwidth consuming denial of Service
Attacks
4.1 Distributed Denial of Service Attacks
In 1999 a new kind of widespread DoS attack was brought to the surface.
These attacks used a distributed approach to cause a denial of service. Back
then, the most popular DDoS network application used was called Trinoo
(described later in this article in Section 7.1 on page 41) [7]. As opposed to
most ordinary DoS attacks, a DDoS attack is mostly not of a system resource
consuming kind but rather of a bandwidth consuming one. DDoS focuses
on consuming the bandwidth of a victimized server and in the end causing
a denial of service state. This can be achieved by sending loads of nonsense
Internet traffic through the aggregation router to where the attacked system
is located. This causes regular users to be denied of service since all the
bogus traffic transmitted from the network of attacking hosts overwhelms
the amount of meaningful traffic. Although system resources are naturally
consumed, it is not the main reason for this kind of denial of service to users
[2]. The attacking computer hosts (often referred to as zombies [2]) often have
broadband connections to the Internet and have been infected by various kinds
of viruses, worms or trojan horses. These allows the perpetrator to remotely
control and synchronize an attack, often through a network of bots such as
botnet [4].
4.1.1 Zombie attack
What happens is that the perpetrator sends a go signal to a number of presumably hacked zombie machines. These will activate the flooding sequence
and start jamming the victim with Internet traffic. Even if the victim has a
good Internet connection, the combined amount of data received will probably
17
18
Figure 4.1: DDoS attack using zombies
19
be more than it can handle. In other words, the amount of data is so great
that the aggregation router has to drop and discard a large percentage of the
packets trying to reach the attacked server.
4.2 Distributed Reflective Denial of Service Attacks
Distributed Reflective DoS attacks are among the worst attacks a system can
be put under. Here the attacker floods an intermediate device which in turn
multiplies the data sent from the attacker to the victim. This may force the
victim to receive an enormous amount of Internet data traffic quickly letting
regular users be denied of service.
4.2.1 Distributed Reflective TCP/SYN Attack
By sending SYN packets to intermediate hosts (possibly random) with a
spoofed source IP address of the victim, the hosts will reply with SYN+ACK
packets to the victim. Since the victim is unaware of what has happened and
has not requested a connection, it will try to send an RST packet back to
the intermediate host to signal a connection termination. But because it is
being flooded with SYN+ACK packets from many different locations, it will
not have time to reply to all of them and has no choice but to start dropping
packets. The intermediate host will therefore not receive an answer from what
it believes to be a legitimate connection request. It will therefore assume that
the SYN+ACK packet previously sent has been lost in transit and will try to
send it again up till 6 times depending on the OS. Using this multiplying (reflective) technique, the attacker does not require as many compromised hosts
as ordinary DDoS due to the fact that the intermediate hosts may multiply
the amount of data it receives [2]. This attack is illustrate in Figure 4.2.
4.2.2 Smurf IP Denial of Sercive Attack
A smurf Denial of Service attack, or ICMP packet magnification, consists of
spoofed ICMP echo request packets sent to the broadcast address of a network
[9]. If the router delivering traffic to those broadcast addresses performs the
IP broadcast to the layer 2 broadcast function, most hosts on that IP network
will take the ICMP echo request and reply to it with one ICMP echo reply
each. This reply will reach the host of the spoofed source IP address. Thus
the flooding effect may be multiplied by a great number since there may be
several hundreds of hosts on a single IP network.
There are two parties that are affected by the attack. The intermediary
broadcast devices and of course the victim whose IP address is contained in
20
Figure 4.2: Distributed reflective TCP/SYN DoS attack
the spoofed source IP address. The victim will most likely receive much more
bogus traffic than the broadcast device. For instance lets say that a network
has 100 hosts attached to it. The perpetrator sends a stream of ICMP echo
request packets at 123 kbps with the victims IP address in the source address
field to the broadcast address of the network. All hosts of the network will
then reply with an ICMP echo reply packet to the victim. The 123 kbps has
been multiplied by a 100 resulting in a flow of 12.3 Mbps leaving the network
and heading towards the victim [17].
Protection
There are ways to protect against this type of attack. One technique is to
block all incoming ICMP echo requests destined for the broadcast address in
the router, and the second approach is to configure every host to not reply
to ICMP echo request to the broadcast address [9]. More general techniques
can be found in Section 5.2 on page 24.
Note: There is a variant to this attack, called Fraggle attack, that instead
of using ICMP echo request packets uses UDP echo request packets in the
same way. This was just a rewrite of the Smurf attack [17].
Figure 4.3: Smurf attack
21
22
4.3 Non distributed bandwidth consuming DoS Attacks
4.3.1 PHP and WEB page overloading
It is also possible to launch a denial of service attack by misusing PHP scripts
by continually loading them. This is especially dangerous if a large cluster of
zombie machines are set to do this at the same time so that all the bandwidth
of a server can be maxed out. The same thing concerns web servers which can
be overloaded by repeated reloading of a web page and also databases can be
overloaded by using search queries.
A good way of defending against attacks like this is to prevent the zombies to have more than one connection per IP session. This will reduce the
bandwidth consumption and the attack needs far more zombies to achieve
something from the attack [19].
Chapter
5
Defending against Denial of Service
Attacks
It is possible to defend against certain types of DoS attacks. As seen earlier
one can protect oneself from mail bombing and so on. There are other, more
general ways to be protected or help to protect others. One is by enabling
ingress and egress filtering on the router (see Section 5.3 on page 26) and
another is by enabling SYN cookies.
5.1 DoS proof TCP/IP stack using SYN Cookies
It is possible to defend against a TCP/SYN flood described earlier in Section 3.1 on page 11. One can postpone the effects of the attack by using
a large SYN queue and random early drops may make TCP/SYN flooding
more expensive but it does not solve the problem. It will still be possible to
exhaust system resources. SYN cookies use cryptographic techniques to solve
the problems concerning TCP/SYN flooding. They are particular choices of
initial TCP sequence numbers by TCP servers.
t mod 32
5 bits
encoded MSS
3 bits
secret function
24 bits
Figure 5.1: Server initial TCP sequence number
23
24
In Figure 5.1, t is a 32-bit time counter that increases every 64 seconds
and the next 3 bits are an encoding of the server Maximum Segment Size
(MSS) in relation to the clients MSS. The bottom 24 bits are the output of a
secret function combining the client and server IP-address and port number
with t. It is selected by the server.
A server that uses SYN cookies does not have to drop new connections
in the case of a full SYN queue. Instead it deceives the client by returning
a SYN+ACK packet just as it would if the queue had been larger. There
are some exceptions though. One is that the server does not make use of the
TCP large window option and it must use one of the eight MSS values that
it can encode. When the server receives the ACK packet from the connecting
client, it checks that the secret function is valid for a recent value of t, and
then rebuilds the SYN queue entry with regard to the encoded MSS [22].
It is not completely unrealistic that an attacker can guess a sequence number from someone else’s host, using that to forge a connection from that host.
It is also possible for an attacker to analyze the cryptographic mechanism
used as the secret function for the purpose of intelligently guessing a new
valid cookie. But if the function is secure enough it will take approximately
the same time as to just guess randomly. An attacker will succeed in a connection forgery after having sent millions of ACK packets but there are ways
to postpone this, for instance by increasing the size of the sequence numbers
used.
Today SYN cookies are implemented in most variants of unix including
Linux, FreeBSD, and SunOS (though nothing is said that they are enabled
by default). The first implementation was done by Jeff Weisberg in October
1996 and a Linux implementation followed soon after in February 1997 by
Eric Schenk. The first one to design an Internet Protocol that used cookies to
defend against DoS attacks like these was Phil Karn. To enable SYN cookies
in Linux or FreeBSD one could add
echo 1 > /proc/sys/net/ipv4/tcp_syncookies
to the boot script [22].
5.2 Ingress filtering
Ingress filtering is usually applied at the network edges to ensure that the
traffic arriving to an interface really are routable from that interface. When
applied correctly it is an effective mechanism to stop spoofed traffic from
entering the network and the closer to the source this is applied the more
efficiently it will stop spoofed traffic. There are five major approaches to
apply these filters [31].
25
• Ingress Access Lists
• Strict Reverse Path Forwarding
• Feasible Path Reverse Path Forwarding
• Loose Reverse Path Forwarding
• Loose Reverse Path Forwarding ignoring default routes
5.2.1 Ingress Access Lists
An Ingress Access List is a filter that is used by a router to check every incoming packet for a valid source address against a predefined list of acceptable
addresses. This list should contain all the addresses that can possibly enter the router on that interface. If it does not match an entry in the list, the
packet is dropped. The drawback of this technique is that the lists usually are
maintained manually and must be updated on a regular basis to not discard
legitimate packets [31].
5.2.2 Strict Reverse Path Forwarding
Strict Reverse Path Forwarding is an dynamic technique for building lists like
the ones that the Ingress Access Lists approach uses. The key feature is that
it looks at the source address of the incoming packets and looks it up in the
Forwarding Information Base (FIB) table (routing table). If the router is to
accept a packet it first validates that the source address is actually a part of the
subnet. This is possible by comparing the interface where the packet arrived
with the interface that the router would have forwarded packets destined to
this sender. If the interfaces differ the packet is dropped, otherwise it is
accepted.
This technique is only of practical value when the incoming and outgoing
traffic share the same path, like in most border network interfaces for an ISP.
Between ISPs it is common to use asymmetric paths (these are paths where
the sending and receiving path differs) in routing and thus almost all traffic
will be blocked by this approach [31].
5.2.3 Feasible Path Reverse Path Forwarding
This is an extension to Strict RPF where not just the symmetric routes but
also all the asymmetric routes are included in the FIB for consideration. The
lists are usually managed by routing specific protocols like BGP. Most problems with asymmetric routes with Strict RPF is solved with this relatively
easy method to update the tables.
26
The biggest problem with this is if a secondary ISP does not forward the
BGP information to the primary ISP which then will not have any information
about the routes in the secondary ISPs network and the packets will be filtered
too.
This is a very powerfull technique in asymmetric routing paths but it has
to be applied very carefully otherwise ligitimate packets will be lost [31].
5.2.4 Loose Reverse Path Forwarding
The algorithm in Loose RPF reminds of the one used in strict RPF, but with
the difference that it only checks if a route, even the default route, exists and
not on which interface it points to. It is rather useless as an ingress filter
at the edge of a network because it does not check where the source of the
packets is. One application of this filter would be in an ISPs upstream to its
providers to get rid of foreign and non-routable addresses coming into his own
network [31].
5.2.5 Loose Reverse Path Forwarding ignoring default routes
This is the same as Loose RPF with the difference that it ignores the default
routes when examining a packet. Hence the filter is mostly used when the
default route is only used to catch bogus packets [31].
5.3 Egress filtering
The main idea about egress filtering is to only allow traffic with a source
address originating in your own network to slip through. This can be applied
in the border router to your ISP or in a firewall. As a general rule it is
better the closer to the sender it is applied. An ISP can also apply a more
general rule as an egress filter to only allow customers to send traffic into the
Internet. Big service suppliers will usually have difficulties as they often send
traffic between other ISPs and do not have any traffic originating from their
networks [23, 32].
5.4 Change of IP address
When a single system is under attack a temporary countermeasure could be
to just change the IP address of the attacked system. The DNS record should
also be updated and the new address should only be given to a few selected
users.
27
This technique cannot be used to prevent a flooding attack that consumes
all available bandwidth from the ISP, since there will not be any bandwidth
left for users. But in a low bandwidth consuming attack this would solve the
problem and the service can still be used by trusted users.
5.5 Additional resources
During a system resource consuming attack it would be possible to add an
extra server during the attack to accommodate the extra requests and postpone the DoS attack. But if it is a big attack with many participants this
will not be enough, despite how many servers are added. There will still more
requests to handle. The only thing left is to wait until the attack is over.
5.6 Conclusion
As seen in this chapter, there are ways to defend or complicate the task of
performing a spoofed DoS attack. Ingress and/or egress filtering may be used
by an ISP to filter legitimate traffic from malicious traffic. It is recommended
for each system administrator to enable some kind of filtering. This is often as
easy as just looking up the setting in the manual. For a normal user, one way
to prevent one’s own computer from being used as a zombie host, is to run an
OS such as Windows XP SP2 that have built-in mechanisms to complicate
the use of spoofed packets. Firewalls and anti virus software should always
be enabled.
28
Chapter
6
In many cases is it important to figure out the path that packets take through
the Internet. Especially when a computer is affected by a denial of service
attack using a spoofed IP address. There are other fields of application as
well, such as path characterization and detection of asymmetric routes. There
are existing tools, such as traceroute, but these generally provide the forward
path, not the reverse [24]. One way of identifying an attack path is by reconstruction, using a collection of packets, marked or especially generated by
routers along the attack path. Another way is to query routers about what
traffic they are forwarding. Yet another approach is to use logging [27].
6.1 Actively querying routers about traffic they forward
If a victim recognizes that it is being attacked, it develops an attack signature,
consisting of some data common and unique to the attack traffic. A query
including the attack signature is then sent hop-by-hop to each router along
the path. This presuppose that each routing device supports input debugging
and is able to tell through which interface a packet corresponding to the attack
signature arrived. This technique is however not very efficient and requires a
lot of manpower and good contacts with other network providers. Some ISP’s
may have implemented a more sophisticated and automated technique for this
to speed up the trace procedure within their own network. A drawback is that
tracing can only be done during an ongoing attack [27].
6.2 Logging-based IP traceback
Generally logging of such great proportions as needed in this case should be
avoided since it often requires huge storage capacities. The basic idea is to
setup the routers to store information about forwarded packets. Later on, the
29
30
victim of an attack can query a specific router to find out whether that router
forwarded a specific packet [28]. But there is an approach called Hash-Based
IP traceback that can actually make this work without humongous storage
usage. With the use of an efficient logging technique, only collecting small
hashes of the packets instead of storing the entire contents in the packet,
which would require 20 to 1,500 bytes of storage per packet, it is possible to
trace a single route of one packet [27, 28].
6.3 Probabilistic Packet Marking (PPM) scheme
This scheme implicates that the intermediate routers sample packets with a
predefined probability constant and encode its identification (router ID) into
these sampled packets. Each packet will be forwared to the address specified
in the IP header. The end host can then decode each sampled packet and
obtain its path.
There are several implementation proposals for this scheme. One is called
node sampling. This technique inserts the routers 32-bit IP address into
the IP header of each sampled packet. A drawback of this scheme is that
the probability of finding a marked packet will decrease significantly with
the number of hops between the sending and receiving hosts. Thus making it
difficult to trace the original host. Furthermore, since this method just provide
node identification, it is hard for the end host to figure out the sequence of
intermediate routers and then to discover correct routing paths. To address
this issue, another technique called edge sampling can be used. Here the link
between two routers (edge) is stored into the packet along with the number
of hops between them. This requires additional data (72 bits) to be inserted
into each packet sampled. Two 32 bit IP addresses and one 8 bit field to store
the number of hops. Under these circumstances 72 bits is quite a lot and
therefore the packets are fragmented. When all fragments have reached the
end host, the data is reassembled and the edge information can be obtained.
Even though this approach solves some of the sequence and space problem
issues there are still several drawbacks to this approach. First of all it requires
a lot of overhead when marking the packets. The attack also requires more
marked packets due to the fragmentation. Another problem with both node
and edge sampling is that there is a possibility for a users to mark packets
with falsified data.
There is a third technique created to address the issues of overhead and
authentication called Advanced Marking Scheme. Instead of fragmenting 64
bits of IP address data, this scheme uses two unique hash functions to compute
the hash of one router IP address. As input it will take a 32 bit IP address
and the output will be a 11 bit hash sequence. To generate the edge id, the
31
two hashes are XOR:ed together. This value is stored in the IP identification
field (16 bits) and the rest 5 bits are used to store the number of hops. When
a packet is received by the end host it can use the hashes to figure out the
path of the packet and also the sequence of the nodes. Though it is still
possible for an attacker to overwrite legitimate markings with garbage or false
markings. Authentication can be supported if the scheme is extended by the
Authentication Marking Scheme. This scheme lets the end host authenticate
the marked packets. If it fails to authenticate, the packet will be dropped.
The drawback of these two techniques is the massive amount of overhead
time it takes to mark a packet. To efficiently discover routing paths with
these techniques a sample probability of 1/25 to 1/10 must be used. In the
long run this may add up to a lot of process overhead.
Another huge drawback for all of the techniques described in this section
is that none of them can detect the true source if the attack is distributed and
reflective. In a distributed attack zombies (reflectors) are used. The malicious
user forges the source address and sets it to point towards the victim’s IP
address. This will cause the zombies to reflect the received packets to the
victim. The reason why the victim does not have any use of the schemes is
that packets are only marked and forwarded in the direction of the destination
host. So in this example where the destination IP points to the zombies, the
schemes assume that the packet has reached the end host so there is no need
of marking more packets. But in the case of a distributed reflective attack,
the zombie replies to the received packets and therefore sends an answer to
the source address, which in this case is the same as the victim. No packets
are being marked so the victim cannot trace the true host [28].
6.4 iTrace
Another way to help solve the problem of tracing back to the original host is
by using the ICMP Traceback (iTrace) scheme. When routers are forwarding packets they can, with low probability (e.g. generating one iTrace packet
for an average of 20,000 forwarded packets), generate a traceback message
that is sent along to the destination. The good thing about this is that the
process does not require too much delay, no extra time is needed to alter the
existing packet. This is possible since the randomly selected packets are actually copied and then forwarded immediately. After the real packet has been
forwarded, an out of band ICMP packet (the iTrace packet) is sent to the destination address located in the IP header. The message contains information
about the IP and MAC address of both the upstream and downstream links
of the router that selected the packet. There is also information about the
packet’s destination and source address and a bit of the payload. It is also
32
possible to use authentication, but this is optional. With enough traceback
messages from enough routers along the path, the traffic source and path can
be determined [24, 28]. ITrace can also trace back attacks that are distributed
and reflective but it depends on the configuration. This is possible since the
scheme stores both the source and the destination addresses. If an iTrace
packet is sent both to the destination and the source, instead of only to the
destination, the victim will receive an iTrace packet disregarding if the attack
is distributed reflective or not. There are special tools that can be used to log,
extract information, and analyse the iTrace packets known as Intrusion Detection Systems (IDS). They can be used to (in realtime) reconstruct attack
paths [28].
There are some statistic problems with this approach though. One thing
is that routers closer to the victim have a higher probability of generating
iTrace packets toward the true victims. The other thing is that the routers
close to DDoS zombies might have a relatively small probability (smaller than
the routers around the victims) to generate ”useful” iTrace packets [25]. An
iTrace packet is called useful when it is sent towards the domain of the victim
since only then can it be used to trace back an attack. There is also the issue
of a potential bottleneck. For instance, if the probability of sending an iTrace
packet is 1/20000, one iTrace packet will be sent every 1/500th second on a
10 Mbit router. If the router is slower it will take much longer time before an
iTrace packet is sent. Since the routers randomly determines which packets
to iTrace, it may require many iTrace processes before the first useful iTrace
packet is received by the victim [28].
6.5 Intention-Driven iTrace (ID-iTrace)
This approach has an enhancement over the iTrace scheme such that it can
dynamically trace more closely to the DDoS slaves with the same number
of ICMP trace-back messages [26]. It increases the probability of receiving
a useful iTrace message when really needed. By using a special intention
value that can be propagated to routers through BGP updates it is possible
for a host or victim to raise the probability of receiving iTrace packets from
remote routers [27]. This can be done without the need to adjust the sample
probability. Instead of randomly choosing a packet for which an iTrace packet
is transmitted, the thing about ID-iTrace is that it uses so called intention
bits and triggers (iTrace Execution bits) [28]. By splitting up nodes into
three different kinds, the ID-iTrace method distinguishes between these kind
of nodes [25]:
• DDoS victims with intention to trace the slaves.
33
• DDoS victims without the intention.
• non-DDoS victims without the intention to trace and with a strong
aversion not to receive any.
For instance, let us say a router that uses the ID-iTrace scheme has three
entries in the routing table: A, B, and C. Let us also assume that entry A is
under a DoS attack and the administrator would like to find the attack source.
Instead of having the router sending iTrace packets whether the receiver wants
it or not, as in the case of normal iTrace, the victim instead tells the router
that uses ID-iTrace to set the intention bit for entry A. This tells the router
that entry A wants to receive iTrace packets. The intention bit is initally set
to zero for all entries in the routing table. Now some of the packets will be
sampled with a certain probability just as in normal iTrace. Since packets
arriving to the router are destined for either entry A, B, or C it is not certain
that the packet that was just sampled belongs to an entry that is under attack
(in this case A which have its intention bit set and wants to receive iTrace
packets). So instead of just sending an iTrace packet about the sampled packet
directly, it checks whether this packet is destined for an entry in the routing
table that has its intention bit set. If it is, an iTrace packet is sent. If it is
not, the incoming packet was not an attack packet destined for the victim in
entry A. Instead of just letting the sample go to waste and hope that the next
sample is an attack packet, the iTrace Execution bit is set for those entries in
the routing table that have their intention bits set (in this case entry A). This
means that the next packet arriving to the router that is destined to entry A
will trigger an iTrace packet to be sent towards the victim (after the iTrace
packet was sent, the execution bit will be reset to zero). The next packet does
not neccessarily have to be an attack packet though but this approach is still
much better than normal iTrace in the terms of lower bandwidth consumption
and that only systems that would like to receive iTrace packets are actually
receiving them.
6.6 Caddie Message Generation
In Caddie Message Generation an ICMP Caddie message is generated to follow
the original packet with a certain probability. The scheme is implemented in
the intermediate routers. It distinguishes between three types of routers. One
is a router that is not a part of the communication link between the attacker
and the victim. The second one is called a Caddie Initiator which is the
routing device that creates a new Caddie message (the first router in the link
between the attacker and the victim). Finally there is the third kind which are
called Caddie Propagators which are used to update Caddie messages coming
34
from another (previous router) with useful data. Routers not supporting the
scheme, but which are still used in the link between the attacker and the
victim, only forwards a Caddie message as a normal ICMP packet. Thus it
is possible that a Caddie message does not contain a complete path between
the attacker and the victim but instead it is highly flexible.
A Caddie message contains information such as a copy of the source and
destination address taken from the original message and information about
the previous Caddie propagator (or Caddie initiator) and the next Caddie
propagator (or destination host) in the link. Whenever a Caddie message
passes a Caddie propagator, new information about this router will be appended to the Caddie message along with the number of hops between this
and the previous one. To later verify the router list in the Caddie message,
the Caddie destination can make use so called ”Time-Released Key Chains”.
What this means is that each router generates a sequence of secret keys (that
are valid for a certain time slot) by applying a one way hash function to a
random seed. These keys are revealed after a delay at the end of each time
slot. This is a good alternative of instead having each router sharing a secret
key with several Caddie destinations. The Caddie destination is now only
required to retrieve the latest key. By using this key it is possible to compute
all the secret keys for the previous time slots and use these to retrieve information. To reduce overhead the secret keys are precalculated and the session
keys are reused. The values generated will still be distinct.
A Caddie initiator or propagator uses a Caddie timer to check for how
long time the device has been operating without generating or propagating
a Caddie message. If the time has exceeded a certain value, the router will
automatically function as a Caddie initiator and send a new Caddie message
to the destination.
There are four different modes that can be used which are shown in Figure 6.1.
As seen in Figure 6.1, Caddie messages can also be used to identify packet
dropping DoS attacks. These are attacks that will make routers or switches
maliciously drop particular packets. Since each packet entering a routing
device should also leave the routing device (if not destined for that router), a
Caddie destination can find which routers that are dropping packets [44].
Compared to other schemes, Caddie Message Generation uses less network
and router storage overhead and supports incremental deployment since not
all routers in the link between the attacker and the victim have to support the
scheme. It also have higher precision and lower computation costs. An brief
comparison between iTrace, ID-iTrace, and Caddie Message Generation can
be seen in Figure 6.2 [44, 45]. Network A indicates the network from where
the ICMP message is sent and Network B is the network receiving the packet.
Mode
Simple
Basic
Responsive
Enhanced
35
Description
Only append router information to the Caddie
message when passing a Caddie propagator.
Simple mode features + protect the router information using a hash value (HMAC) at each Caddie propagator.
Basic mode features + a response is sent back to
the origin for each Caddie propagator and Caddie destination. This enables detection of packet
dropping at the router.
Basic mode features + matching each Caddie message with its original packet at every Caddie propagator or destination.
Figure 6.1: The different modes available in the Caddie Message Generation
scheme
Scheme
iTrace
ID-iTrace
Caddie
Message
Generation
Bandwidth
overhead
High
High
Fair
Storage overhead
Network A Network B
None
High
High
Fair
Low
Low
Computation overhead
Network A Network B
Low
Very High
Low
High
Low
Fair
Figure 6.2: A brief comparison of iTrace, ID-iTrace, and Caddie Message
Generation
36
6.7 IPSec-Based Source Tracing
Node-to-node authentication provides a way to trace back an attack since a
receiving node can be sure that an authenticated packet must have been sent
from a specific node. In other words the attack origin should be traceable.
A protocol that can be used in an implementation of a traceback nodeto-node authentication algorithm is the IPSec which provides this type of
authentication by default. There are at least two tracing approaches that
utilize IPSec to trace back an attack to the originating source. One is the
Decentralized Source Identification for Network-based Intrusion also known
as DECIDUOUS and another one is the Packet Head Information List also
known as PHIL. The PHIL switching technique was designed to enhance the
tracing ability of DECIDUOUS [28]. To be able to understand how the algorithms work, it is necessary to have basic knowledge about IPSec. A description about IPSec is presented below.
6.7.1 Introduction to IPSec
IPSec is a protocol suite that allows for integrity, confidentiality and authentication of data communications over an IP network. It has two operating
modes called transport mode and tunnel mode. Using transport mode will
have the source and destination hosts performing the cryptographic operations directly. This allows for end to end security. Using tunnel mode on
the other hand will allow for special gateways to perform the cryptographic
operations and therefore allow for gateway to gateway security [39].
There is also an authentication header (AH) protocol, whose (only) purpose is to provide authentication for IP packets. To provide the encryption
and authentication, the encapsulating security payload (ESP) protocol may
be used. Another important part of IPSec architecture is the key manager
which provides the negotiation of connection parameters such as which protocol (AH or ESP) to use [28].
When a packet is passed through a gateway supporting IPSec tunnels, the
packet is wrapped into a new header which includes the Security Parameter
Index (SPI). The SPI specifies which keys and algorithms used by the previous
system to view the packet. Using this technique will also protect the payload
of the packet since any error or change to the payload will cause the end system
in the tunnel to drop the packet. When a packet is received by the end system
in the tunnel, the header that was previously added is now removed (if the
packet is successfully verified and validated) to avoid unnecessary overhead.
Another part of the IPSec architecture is the security association (SA). It
uses the SPI number that is carried in the AH or ESP part in the IPSec packet
to identify which SA that is being used in the packet in question. Also included
37
in the SA is the destination IP address to which the packet is finally destined
to as well as the security protocol (AH or ESP) [39]. Each IPSec connection
have its own specific SA and therefore a security association database (SAD),
that stores which SAs being used for the different connections, is needed [28].
6.7.2 DECIDUOUS
One way to identify spoofed attacks by using IPSec would be to establish SAs
between every pair of nodes that might ever need to communicate. This is
however too expensive from a computational viewpoint. There would be a lot
of IPSec processing overhead even when there are no attacks so this option
is not feasible. Another way would be to set up static SAs between a limited number of communicating node pairs but this will not guarantee source
identification since not all nodes are covered. The solution is to dynamically
establish IPSec tunnels and locate the attack with the help of an IDS [37].
The purpose of DECIDUOUS is to decide where, when and how to establish SAs using IPSec [38]. It uses a concept called CutSet which is a group
of routers that are on the same hop count away from the victim. CutSet
enables DECIDUOUS to transform the network topology into a linear topology. Only then is DECIDUOUS able to establish IPSec tunnels between the
different CutSets and with the help of the IDS it can trace back the attack.
Figure 6.3 helps to clarify what is going on. CutSet 0 in (the blue filled circle
Figure 6.3: The concept of CutSet
in Figure 6.3) is the victim itself. The CutSet index represents the number of
hops between the current CutSet and the victim. The dashes in the circles are
38
routers (nodes) in the current CutSet. Using Figure 6.3 as an example, the
linear topology created by DECIDUOUS will look like: Attacker↔ CutSec
3↔CutSec 2↔CutSec 1↔ CutSec 0 (victim). The arrows indicate a secure
IPSec tunnel between the routers within the participating CutSets.
If the IDS detects an ongoing attack, it signals to an DECIDUOUS daemon to start tracing. Knowing about the converted linear network topology,
DECIDUOUS dynamically sets up IPSec tunnels from routers within the same
CutSet of the victim. Each tunnel gets a unique SPI. The IDS will then verify
the attack once again and, based on the authentication information gathered
from the tunnels, send the results to DECIDUOUS. DECIDUOUS will start
checking if the attack packets (identified by the IDS) are forwared through
an authenticated border router within the current CutSet. If this is not the
case, the true origin of the attack is not within the current CutSet and so
DECIDUOUS will destroy the IPSec tunnels already built and set up other
tunnels with a border router located in a CutSet one step further away from
the victim. This will continue until DECIDUOUS finds the first authenticated
border router in a CutSet that do not forward attack packets. DECIDUOUS
now knows that the true origin of the attack is a host located between the
previously authenticated router found (which forwarded attack packets) and
the last authenticated router found (which did not forward attack packets).
Using the information stored in the SPI, DECIDUOUS can then locate the
true origin of the attack.
For instance say that the routers in Figure 6.4 are border routers of different CutSets. What DECIDUOUS does is to first see if the router closest
to the victim (Router A in CutSet 1) are forwarding attack packets. Since
it does, DECIDUOUS knows that it must search one step further and finds
border router B in CutSet 2. This router does also forward attack packets
and therefore the attacker is not located in this CutSet either. DECIDUOUS
continues to search this way until it finally finds that Router D in CutSet 4 is
not forwarding attack packets. Since the previous router checked to forward
attack packets was located in CutSet 3, DECIDUOUS concludes that the true
origin of the attack is located in CutSet 4 and will be able to find the true
source by using an intra-domian tracing technique [28, 38].
There are some problems with the DECIDUOUS approach though. First
it is difficult to obtain the IPSec header information needed to traceback the
attack because every time an end system of an IPSec tunnel is reached this
information is removed from the packet. One solution would be to integrate
the IDS into the network protocol stack to detect the attack in the network
layer. Otherwise there is no way for DECIDUOUS to fetch the IPSec authentication header and thus a traceback is not possible. Another problem is
regarding security issues such as the unwillingness for domain administrators
to share the local network topology with others. Without the knowledge of
39
Figure 6.4: The secure tunnels between the routers which exposes the attacker
the network topology, DECIDUOUS will not function [28].
6.7.3 PHIL
PHIL was designed to tackle the issues of DECIDUOUS. PHIL may be seen
as an extension to DECIDUOUS that provides an application layer approach
instead of the network layer approach used by DECIDUOUS as well as a possibility to trace back an attack without knowledge of the different network
topologies. The first challenge is solved since PHIL uses a special data structure to store the IPSec headers whenever an IPSec system throws them away.
This is done by using special PHIL API socket interfaces so that applications
may retrieve data as well as IPSec headers. When sending data, PHIL also
provides options to send data along with SAs to be processed by IPSec.
Another improvement from DECIDUOUS is that PHIL no longer needs
complete knowledge of the network topology in the different networks on
which it operates. PHIL provides a switching scheme that coordinates security information among different administration domains by maintaining
relationships between their SAs in a PHIL switching table. If someone in
one of these domains would like to know the IPSec tunnel relationship with
another domain a query can be sent to the PHIL switching table to gather
the requested information. Either an SNMP model or a UDP client/server
model can be used. By utilizing this technique it is possible to trace back a
spoofed DoS attack. For an example refer to Figure 6.5 [28].
6.8 Conclusion
As seen in this chapter there are numerous ways to trace back an attack even
if the source address of the packet was spoofed. Though nothing is said that
40
Figure 6.5: An illustration on how PHIL switching can be used to traceback
an attack
this should be easy. Special schemes must be used and intermediate routers
in the link between the attacker and the victim must support these schemes.
It can be costly to implement, both time and money wise.
When talking about the ”attacker” in this sense it does not necessarily
mean the initiator of the attack. The ”attacker” rather means the host directly responsible for transmitting malicious data. For instance, if the true
perpetrator is using a flood network such as one of those described in Chapter 7, he can hide behind zombies and reflectors. A traceback scheme can only
trace back as far as the zombie actually transmitting the malicious packets.
Theoretically it is possible for the perpetrator to send an attack command
to a zombie that is not initiated until several hours or days later. It will
be impossible for a traceback scheme (and extremely difficult for the system
administrator of the zombie infected host if he has no previous knowledge of
the attack) to locate this packet and trace back the attack. It is even possible
for the perpetrator to initiate this delayed attack by just sending one spoofed
UDP packet.
So the main purpose of all the schemes presented above is not to find the
true initiator of the attack (even if this may be possible in some cases) but
rather to locate the presumably hacked attack source that is transmitting the
bogus traffic to later be able to contact its administrator to deal with the
problem. For this issue, traceback schemes are invaluable.
Chapter
7
7.1 Trinoo
Trinoo is an implementation of a distributed UDP flood attack. A trinoo
network is built up of a network with a couple of masters controlling a larger
network of daemons as seen in Figure 7.1. There is no communication between
two masters or between two daemons, the communication flows only in top
to bottom direction and reversed.
Figure 7.1: A trinoo network
Trinoo masters and daemons were first seen on Solaris 2.x systems and
were wide spread thanks to a buffer overflow in RPC. Later it was also found
on Linux systems. The big focus on these two systems was due to the easy
availability of root kits and exploits for these system. In the original version of
trinoo the communication was handled on the ports as showed in Figure 7.2.
To connect to a trinoo network all that is required is a TCP connection
to a master, typically a telnet application is used here. In the beginning of
the session the user have to enter the correct password and if someone else
41
42
attacker to master
master to daemon
daemon to master
27665/tcp
27444/udp
31335/udp
Figure 7.2: Ports used in standard configuration of trinoo
is already connected to the master a warning is issued that there is someone
already connected.
When a daemon starts it sends out a ”*HELLO*” string to all masters it
knows about and the master adds this daemon to a list over active daemons.
Most commands between masters and daemons are password protected and
look like the following:
arg1 password arg2
These commands all have different password phrases. The passwords are
stored in the binary encrypted with crypt() [6] but it is sent unencrypted over
the network. When a password is received it is encrypted with crypt() and
compared with the stored password phrase. If they are the same the command
is executed otherwise nothing happens.
When a master is started it first asks for a password and if the correct
password is entered it prints a confirmation and forks a process to be run in
the background and finally it terminates its execution.
The masters have a list over active daemons stored in the file ”...”. To
update it the master can send out a ”png” command to all known daemons
and they will answers back with a ”PONG”.
To protect oneself against hosting a trinoo daemon is not as easy as to
just block the ports because high port numbers are usually used by legitimate
programs. A better approach is to study and block all UDP packets that
contain footprints from trinoo commands which is possible since they are sent
unencrypted [41].
7.2 Tribe Flood Network
The Tribe Flood Network (TFN) is a flooding network with a couple of clients
controlling a lot of daemons, see Figure 7.3. It implements ICMP flood,
TCP/SYN flood, UDP flood, and smurf attacks. It can even start a remote
root shell listening on a TCP port on demand. There is no password protecting
the client, instead a list with IP adresses to daemons must be supplied from
the user. To connect to a client one of the following ways may be used:
• remote shell bound to a TCP port
43
• UDP based client/server remote shell
• ICMP based client/server shell
• SSH terminal session
• telnet TCP terminal session
Figure 7.3: A TFN network
TFN was spread about one month after trinoo and the main target for
TFN was also Solaris 2.x due to the RPC buffer overflows.
The communication between the client and the daemons is done with
ICMP Echo Reply packets. No TCP or UDP traffic exists between them.
One big reason for this is that some network analyzing tools do not show
ICMP packets in standard configuration. The traffic is encrypted by using
the ID field of the ICMP header to represent different commands and with
the sequence number set to 0x0000 it looks like a reply to an ordinary ”ping”
commando. Arguments for the commands are sent as null terminated strings
in the data field of the packets. The choice of using ICMP Echo Reply instead
of Echo Request is that the kernel would have answered back with an ICMP
Echo Reply to every request sent by the client.
Later versions of TFN have been found but no new source. From the
binaries it have been possible to come to the conclusion that encryption have
been added, probably to the IP list, the list over clients and the traffic in the
ICMP data field.
By using ICMP packets for communication the network administrator
have a difficult task to block these packets because blocking all ICMP packets will break a lot of legitimate program relying on ICMP messages. A
workaround would be to investigate the difference between TFN commands
and ordinary ”ping” traffic.
44
Because the daemon does not do any authentication of the source of commands it is possible to flush it with only one packet if the commands have not
been changed. Even if they have been changed it is still possible to flush it by
using brute force and test every possibe combination of the ID field, because
it is only 16 bits wide there are only 65536 possible combinations [42].
7.3 Stacheldraht
Stacheldraht is based on TFN with features from trinoo. New features include
encryption between client (attacker) and handlers (masters) and a commando
to update the agents (daemons) automaticaly on demand. The first known
stacheldraht version was found in late September 1999 and had competition
by TFN2k (a new version of TFN). Also stacheldraht was wide spread thanks
to the RPC exploit in solaris 2.x systems. Even stacheldraht included support
for ICMP flood, TCP/SYN flood, UDP flood, and smurf attacks. There has
not been found any versions with a remote root shell in stacheldraht. A
stacheldraht network is built up of one or a few handlers controling a large
set of agents as seen in Figure 7.4. The attacker connects to the handler with
a special client with encryption capabilities so the communication between
client and handler can not be easily read. With this encryption stacheldraht
tried to overcome the biggest flaws in TFN, that where subject for standard
TCP attacks such as session hijacking and RST sniping.
Figure 7.4: A stacheldraht network
An attacker controls or a few handlers that each can control up to 1000
agents. The limit is set to 1000 because most unix implementations have a
45
hard limit on 1024 filehandlers. In the original version the communication is
handled on the ports shown in Figure 7.5.
client to handler
handler to/from agent
16660/tcp
65000/udp, ICMP Echo Reply
Figure 7.5: Ports used in standard configuration of trinoo
When the client is started it asks for a password and applies the crypt()
encryption on it. The encrypted password is checked against the password
stored in the binary. If it matches, blowfish encryption is applied on the
already ”crypt()” encrypted password before it is sent to a handler.
As in TFN commands between handler and agents are sent in the id field
of an ICMP header.
In the startup of an agent it begins by reading a configuration file with
a list, encrypted with blowfish, over known handlers. If the list is empty
or nonexisting it has a fallback in form of one or two hardcoded handlers
in the binary. In the second phase the agent starts to send an ICMP Echo
Reply to all known handlers and the handlers will respond to the agent with a
confirmation. This communication continues throughout the execution of the
agent. When the agent has got a confirmation from a handler it tests for the
possibility to send spoofed packets by sending a spoofed ICMP Echo Request
packet to a handler. The ID field and the Type of Service field of the ICMP
header have a predefined value so the handler knows that an agent sent it and
the IP of the agent is written down in the datafield of the ICMP packet. If
a master replies to this request with another predefined value in the ID field
and a message in the data field that spoofing is successful the agent will use
spoofing in the future.
When the hander commands the agents to upgrade themself the agents
start by removing the old binary and download the new from a stolen account
by the RPC protocol. When the new version is downloaded the agent starts
it and terminate itself.
It is not a good idea to block all ICMP traffic to stop stacheldraht from
using a network because many applications rely on ICMP messages. One
approach is to look for outgoing ICMP Echo Requests with spoofed source
address (as in Section 5.3) as the agent sends them in the startup. If the packet
is logged then it will be easy to find which computer sent it. It is also possible
to detect a running agent/handler by the continuous communication with
ICMP Echo Request packets beeing sent between an agent and its handlers
and if many RPC connections are made in a rapid flow it could be agents
upgrading themselves and should be further investigated [43].
46
7.4 Comparison and conclusion
All three of these DDoS networks were wide spread a short time after each
other and thus could use the same security flaw in the targeted systems, this
time it was the RPC buffer overflow. They all used some kind of technique
to disguise or hide them selves so they would not be easily discovered. On
some systems they were even restarted automatically if something happened
to them.
The first DDoS network to show up was trinoo and it only had one attack implemented and utilized ordinary UDP and TCP connections. The
communication was also unencrypted so it was rather easy to watch the communication and take control over a master. The successor, TFN, added a
couple of attacks and also thought about encrypting the communication between clients and daemons. Due to the unencrypted communication between
the attacker and a client it was still possible to take over a TFN network just
by sniffing the communication. The next version to be seen was stacheldraht,
with most of the functionality in TFN and encryption between attacker and
handler. The current big flaw in the stacheldraht communication is that the
command arguments are sent unencrypted in the data field, so a wise step
would be to add encryption here.
Chapter
8
Our Denial of Service application
8.1 Control Center
The Control Center is a multithreaded CLI that is used to remotely control
zombies by a TCP/IP connection. For instance it may be used to initialize,
start, stop, and monitor an attack. It may be regarded as a master in a flood
environment such as the trinoo network (Section 7.1). There are several implemented attacks that may be used to attack another computer by a DoS
attack (for details refer to the manual in Section G). The actual implementation of the attacks is realized, in the zombie. The Control Center has been
tested in Windows 2000 and XP but it will probably work in other versions
as well as long as they have support for Winsock 2 and Boost threads. At the
moment there is no support for Linux but it has been implemented in such
a way that it would be easy to port. It is mainly the network part that is
platform specific.
8.2 Zombie
The Zombie is the application that actually performs an attack. It is controlled by a Control Center and cannot be used as a stand alone tool. TCP/IP
connection is used to communicate with the Control Center which can transmit commands for the Zombie to execute. The connection is established when
the Zombie is started and if the connection is lost the Zombie will end its execution. It uses IPC to exchange IP and MAC information with other Zombies
on the same computer (the reason why is described later in Section 9.1.1).
When an attack command is received from the Control Center the specified
attack will start in a new thread. This thread will end its execution and will
be deleted when the attack is stopped. The Zombie requirements are the same
as for the Control Center but with the addition of WinPcap 3.1 beta 4.
47
48
8.3 Misc
8.3.1 Boost threads
To allow the Control Center to have multiple Zombie clients connected at the
same time and for the exchange of messages between them, threads were used.
Since there are no built-in thread support in STL C++ and because it should
be easy to port the application to Linux, Boost threads were chosen.
Boost [46] is a collection of free portable C++ libraries with the emphasis
on working well in the STL library. Another goal of the Boost project is to
eventually have the library standardized in C++.
To get Boost running can be quite tricky. First of all it must be downloaded and compiled. To compile Boost for Visual Studio .NET the following
steps should be performed:
1. Download Boost from the Boost homepage [46]
2. Download Boost jam from the same site
3. Build Boost jam by running build.bat
4. Copy bjam.exe to a directory in the path
5. Start a Visual Studio command prompt
6. Enter the Boost directory and execute ”bjam -sTOOLS=vc-7 1”
Be aware, compiling Boost requires about 600 Mb of free disk space and takes
several hours to compile.
To setup a Visual Studio debug solution configuration of Boost, the following steps should be performed:
1. Goto Tools → Options → Projects → VC++ Directories → Library
files and add the path to libboost thread-vc71-mt-sgd-1 32.lib
2. Goto Tools → Options → Projects → VC++ Directories → Include
files and add the path to the Boost root directory
3. Change Visual Studio to support multithreaded application by: right
clicking on the project → Properties → C/C++ → Code Generation
→ Runtime Library and choose Multi-threaded (/MT)
4. Right click on the project → Properties → Linker → Command Line,
add /NODEFAULTLIB:LIBCMT
In order to setup a Visual Studio release solution configuration, the lib
file called ”libboost thread-vc71-mt-s-1 32.lib” should be used instead of the
one mentioned in the first item above.
49
Before trying out Boost threads another thread library called PThreads
(POSIX) were installed and evaluated. But after a while the decision to choose
Boost threads instead was very prominent since PThreads did not seem to
work in an object oriented manner in C++ and is better suited for C.
8.3.2 Endian
The different ways that multi byte data can be represented by a computer
system and dictated by the CPU is called endianness. Different systems uses
different representation thus making it harder to create platform independent
software. There are two different ways to represent multi byte integers, big
and little endian. In big endian the most significant byte (MSB) is stored
at the lowest address of the memory address while in little endian the MSB
is stored at the highest address [47]. For example refer to Figure 8.1. Since
the host running a Control Center or a Zombie may use a different endianness
than Ethernet (big endian) a class that is able to convert between big and little
endian was implemented. For instance is the Intel 80x86 CPU architecture
using little endian. There are built-in functions in C to convert to and from
from big endianness but these do not support 64 bit conversions nor are they
platform independent. The implemented class supports both. It has though
only been tested in little endian environment but it should work in both.
Endian
Big Endian
Little Endian
00
12
78
Address
01 02 03
34 56 78
56 34 12
Figure 8.1: Memory layout of the value 0x12345678 in big and little endian
8.3.3 Multicast sockets
Multicasting is a bandwidth conserving technique that makes it possible to
simultaneously send a stream of data to many systems without adding any
additional burden to the source or receivers. The packets from the source are
replicated by the routing device and forwarded to all listening receivers. This
is especially useful in video streaming technology [48].
To avoid having to manually enter the IP address and port of the Control Center each time a Zombie is started, the use of multicast sockets was
implemented. Multisockets uses the address space between 224.0.0.0 and
239.255.255.255. Whenever a Zombie is started it will listen to 224.0.0.1 on
port 1337 for a message from the Control Center. The address of 224.0.0.1
50
will only reach systems in the local subnet which is the intension since the
application should not reach beyond the test environment.
When the Control Center is started it connects to the multicast address
and sends a message containing its IP address and port to the listening Zombies that were started prior to the Control Center. The Control Center will
then continue to listen on the multicast address for messages. When a Zombie
is started it connects to the multicast address and sends a request for the IP
and port to the Control Center. The Control Center will reply with this information and the Zombie disconnects from the multicast address and connects
to the Control Center. It is possible to skip the multicast IP lookup, refer to
the manual in Appendix G for more details.
8.3.4 Protocol
Each message sent from the Control Center to the Zombie and vice versa are
sent in accordance with the protocol described in ”Protocol.h”.All messages
begins with a pre string and ends with a post string defining the beginning
and the end of a message. Commands and arguments have only a pre string.
”Protocol.h” is shared between all classes that compose messages to be sent,
both in the Zombie and the Control Center. ”Protocol.h” also contains macro
like functions to ease the use of the protocol. Below is a couple of examples
of communication between the Zombie and the Control Center.
Initialization: When an attack is initialized by the Control Center it sends
out a message to the specified Zombie, all if none specified, and does
not wait for any replies.
Status: If the Control Center needs to know what state every Zombie is in
it can send out a status request to the Zombies and they will reply
with the current state they are in. If an attack is ongoing the number
of packets sent as well as how long time the attack have been running
are returned. If no response is received within 5 seconds the Zombie is
considered dead.
Start attack: To start an attack the Control Center sends a message to the
specified Zombies, or all, to start the initialized attack. If the Zombie
has an attack initialized, it starts the attack and returns its current
state. If it does not have any attack initialized it returns a message
specifying that.
Stop attack: A stop of an attack is handled in the same way as to start
an attack. The Zombie returns one of: attack stopped successfully, no
attack running, and no attack initialized.
51
Shutdown: When the Control Center is shutting down it sends out a message
to every Zombie connected and then ends its own execution.
Broken link: If at any time the connection between a Zombie and its Control
Center is broken the Zombie ends its execution and the Control Center
closes that socket and continues as normal.
8.3.5 stdint
Since different compilers use different bit length representation of primitive
data types, this had to be dealt with in the implementation. For instance
may the primitive data type ”long” be treated as either a 32 bit or a 64
bit representation depending on the compiler. To get around this problem
a special library file called ”stdint.h” was created that made it possible to
define exactly how many bits that were to be used. For instance ”int64 t ”
represents a 64 bit integer.
8.3.6 WinPcap
A mayor part of the Zombie application is the use of raw sockets. As described
in earlier sections this feature was withdrawn from Windows XP SP2 but by
using a third party software called WinPcap it is still possible to send raw
sockets from this OS.
WinPcap is an open source packet capture and network analysis library for
the Win32 platform. It will work under most version of Windows. It provides
direct access to raw sockets independent of underlying network hardware.
WinPcap was mainly designed to be used in open source network analysis
tools that may be freely distributed under a BSD-style license [49].
Although this may sound quite fantastic there are still some limitations
when using WinPcap in Windows XP SP2. The problems are presented in
Section 9.1.1.
52
Chapter
9
Test scenario
9.1 The test environment
The test environment used to test the Denial of Service application consisted
of 16 IBM compatible computers with Intel 2.0 GHz CPUs and 256 MB of
system RAM. The operating system installed on all the hosts was Microsoft
Windows XP with service pack 2. The hosts also used active directory and
network login. The network speed was 100 Mbit and all hosts were connected
to a 3Com SuperStack 3 switch (”stack-2” (130.235.4.52)). Windows XP was
configured to automatically download and install the latest security patches
using Windows Update when available.
9.1.1 Problems
The problems concerning the test environment mainly originated from Windows XP SP2 and the network configuration. One thing was the frequent
security updates which on at least one occasion caused disturbances. Attacks
that previously had worked did no longer work for example. There were also
an unresolved issue of the Smurf attack whose outcome seemed to change over
night without any functional changes in the code (more on this later in this
chapter). But the main issue was regarding Windows XP SP2. Some of the
problems that came up during the test face are presented below.
Problems with Windows XP SP2
ARP problem
The problem was that when several Zombies were used simultaneously on the
same computer, some of them did not receive a response from an ARP request. A Zombie sends out an ARP request to find a host’s Ethernet address
53
54
Test scenario
from an IP address. If no response is received the Zombie will use the default MAC address of ff:ff:ff:ff:ff:ff which is the MAC address for the broadcast
address. This would slow down an attack significantly, packet rates around
100 packets per second were not unusual. This effected all Zombies on the
same computer. If only one of the started Zombies failed to retrieve an ARP
response all other Zombies would flood at a very slow level. One confusing
thing about this was that it did not seem to matter if there were say 15 Zombies running on the same computer or if there were only 5. There were always
around 1-3 Zombies that failed to get an ARP response. To see that it really
was a Windows XP SP2 related problem a test was executed. 18 Zombies
were started on a Windows XP SP1 host. An attack was initialized against
a Windows XP SP2 machine located in the test environment (an attack initialization automatically triggers an ARP request). Running this OS resulted
in that all Zombies received the MAC address just as they were supposed to.
This test was repeated over and over again and only once did one of the 18
Zombies fail to retrieve the MAC address from the SP2 computer. But when
starting only 15 Zombies on a Windows XP SP2 host in the test environment
and initializing an attack against the same computer, there were always 1-3
Zombies failing to get a response. The problem was therefor not that the
remote Windows XP SP2 host detected a flood and stopped responding to
the ARP requests. The same test was conducted both with the Windows
Firewall enabled and disabled but there were no difference of behavior. What
caused this problem is unknown. There is no mentioning of this behavior in
[33] which is Microsoft’s own documentation about the updates in Windows
XP SP2.
It was possible to find a workaround for this problem. The first thing tried
was to simply resend an ARP request up till 10 times for each Zombie process
with 1 s interval between each retransmission. This did however not solve
the problem. The next thing tried was to implement Inter-Process Communication (IPC) between the Zombies who now shared a memory mapped file.
When a Zombie retrieves a MAC address it checks the memory mapped file to
see if the IP/MAC address pair exists in the file. If it does not the IP/MAC
pair will be appended to the file. If it does the previous IP/MAC pair will be
overwritten. The reason why it is overwritten and not just discarded is because there is a small chance that the MAC address have been changed since
a previous attack. If a Zombie fails to retrieve an ARP response it will first
wait 100 ms then check the memory mapped file to see if another Zombie has
inserted the IP/MAC pair. This is done by matching the IP address whose
MAC address did not resolve to already inserted IP/MAC address pairs. If
the IP/MAC pair does not exist it will go back and send a new ARP request
and repeat the whole process up till 10 times. This solved the problem in a
sufficient manner.
Test scenario
55
Restricted traffic over raw sockets
With the release of Windows XP service pack 2 the full use of raw sockets was
withdrawn. According to Microsoft [33], these are the raw socket restrictions
in SP2:
• TCP data cannot be sent over raw sockets.
• UDP datagrams with an invalid source address (one that does not exist
on a local network interface) will be dropped.
Our experiments have shown that this not true. It is possible to spoof the
source address of a TCP packet (using WinPcap) just as well as an UDP
packet in Windows XP SP2. The test environment was configured to drop
packets that had an invalid source MAC address which was very confusing
at first. This led to the belief that the SP2 non spoof barrier did indeed
work but as proven later it does not if WinPcap is used to send the packets.
It is possible to set an arbitrary IP source address for a packet in the test
environment but the source MAC address had to be accepted by the switch
otherwise the packet was dropped.
This problem is really important to keep in mind when using the flood
application since the problem will not be noticeable from the Control Center.
Checking the status for each connected Zombie will not indicate any dropped
packets. Not even by using Ethereal on the Zombie computer is it possible
to see this behavior (Ethereal will show that the forged packet is sent as it
should). To see that the packet does not reach the victim, a packet sniffer
must be installed at the victim or the data flow in the switch may be checked
with PRTG or a similar application. But as stated earlier, it is possible to
spoof the source MAC address to an address that exist in the local network
and thus is accepted by the switch.
When a packet with an spoofed source MAC address set to an address
outside the local network is sent, connections are blocked for a short period
of time (approximately a minute or so). It is not possible to use a browser
to access web pages for example. It was not possible to reinitialize the attack
with a functional source address until this time had passed. The problem with
dropped packets were experienced in some tests, for instance in the distributed
UDP flood (Section 9.2.8).
Microsoft has implemented these functions to limit the ability for DoS
applications to send spoofed packets [33].
56
Test scenario
Limited number of simultaneous incomplete outbound TCP connection
attempts
Windows XP SP2 will limit the number of simultaneous incomplete outbound
TCP connections attempts. When this limit has been reached, the following
TCP connections will be put in a queue and will be resolved in a fixed rate
and an event (ID 4226) will appear in the system log [33]. What the actual
limit is, is not defined in [33] but using a tool such as ”EvID4226Patch” it
was found to be 10. By using this tool it is also possible to set a new limit of
maximum 16777214 connections. The patch alters tcpip.sys which is located
in the %windir%\system32\drivers directory. It is not possible to alter all
versions of tcpip.sys. For instance it works fine on version 5.1.2600.2685 but
it fails on version 5.1.2600.2180.
According to the same source, this restriction has been implemented to
limit the speed at which malicious programs (for instance viruses and worms)
spread to other computers. These programs often use random addresses to
find new infectable systems.
This restriction may cause some security tools such as port scanners to
run more slowly [33].
9.1.2 Task manager only monitors own packets
This is not really a problem but rather a weakness in Windows XP (and quite
possibly other Windows versions as well). The task manager will only monitor
outgoing network traffic when the source addresses (IP and MAC) of the sent
packet matches the network interface card installed. Hence spoofed traffic
sent by WinPcap will not be detected. This could be quite confusing for a
network administrator if he only relies on the network monitor in Windows
task manager (or other network monitoring tools for that matter) to monitor the data flow (though this is hopefully very unlikely). Traffic should be
monitored from the switch by, for instance, PRTG. The traffic is fully visible
in the network monitor at the victim so it seems that this issue only regard
outgoing traffic.
9.1.3 Packet rate limit per process
Running only one instance of the Zombie application in the test environment
would not make use of all available bandwidth. A rate above approximately
4000 packets per second (per Zombie) was not possible in our tests. This phenomena occurred only in the test environment. When testing the Zombies on
Windows XP SP2 (and SP1) hosts outside the test environment this behavior
did not occur.
Test scenario
57
To get around this issue, several Zombie instances have to be started
on the same computer as seen in many of the conducted tests (described
in Section 9.2). A simple batch file could be created to easily start several
Zombies ”at once”.
9.1.4 Recommended test environment
Windows XP SP2 is not the ideal OS to use as a test environment because
of its many built-in protective mechanisms. It is quite possibly one of the
worst. Linux would probably be best suited in most situations since it is free
and has better configuration support. For instance it is possible to enable
broadcast ping responses and set a port to blocking mode without commercial
third party applications (problems that are described more in detail later). It
would also be more convenient to run the Zombies on a Linux host since there
would be no need of a WinPcap-like application to send raw sockets. But this
is currently not possible since there is no Linux support for the implemented
DoS application at the moment. At the moment Windows 2000 or Windows
XP with SP1 is recommended as the platform for the Zombies. The Control
Center will work just as fine on a Windows XP SP2 host since it does not
require the use of raw sockets.
To test some of the old attack such as WinNuke and possibly PoD2 and
Teardrop, Windows 95 should also be installed on at least one computer.
Another important thing is that under laboratory circumstances the test
environment should be cut off from all other networks to avoid interferences
and disturbances. It is possible to cause severe damage to other systems and
networks if these are reachable from the test environment. Other reasons
for having the test environment as a separate network is to avoid automatic
updates and to allow for easier configuration.
9.1.5 Configuration
Several third party applications were used when testing the DoS application.
Some of them are required, some are optional.
Ethereal
Ethereal is an open source licensed protocol analyzer that
was used to sniff packets in a network to see their contents. Ethereal is supported in both Windows and Linux,
although the Windows version was mainly used. A utility
like this was invaluable in the creation of the DoS application and also to see how different packets are built. It
was also used, together with the Windows task manager,
to see if a flood actually reached the victim computer.
58
Firewalls
PRTG
VMware
WinPcap
Task Manager
Tcpdump
Test scenario
Several firewalls were tried to see if it was possible to
set a port to block mode. The firewalls used were Zone
Alarm 4.5 Pro, Sygate personal firewall 5.5 pro and Tiny
Personal firewall. Zone Alarm was the only one capable
of doing this. They are all available for trial use.
PRTG is a Windows software (based on MRTG) that can
monitor bandwidth, memory and CPU usage via SNMP.
This was the application used to gather data from the
switch in the test environment. It is available in different editions. During our tests, a trial version of the
commercial edition (version 4) was used. The trial version supported up to 50 sensors that could be used to
monitor the switch. Prior to PRTG, MRTG was tried
but it could not update the graphs as fast as PRTG and
it is not as easy to configure.
VMware workstation was used to run multiple virtual
x86 computers simultaneously. This was very useful
when several different operating systems were to be
tested. There were, for instance, no need for rebooting when switching between operating systems. VMware
workstation is also a safe and convenient way to install
and test different operating systems. The system that is
running VMware is called a host OS and a system that
is used in a virtual computer within VMware is called a
guest OS. A trial version of the VMware workstation 5
is available for download.
WinPcap 3.1 beta 4 is a required tool that has to be
installed on every Windows computer that will host a
Zombie in the test environment. Its purpose have been
described earlier in Section 8.3.6.
The Windows task manager was frequently used to monitor incoming traffic at the victim. It is not a good tool
for checking outgoing traffic as described in Section 9.1.2.
Tcpdump is another open source licensed packet sniffer that was used in Linux. It detected some errors
that Ethereal was unable to detect (see Section 9.2.12
for more details).
The only required application of those listed above is WinPcap (and of
course the Zombie and Control Center application). Ethereal is highly recommended and PRTG is recommended to overview broadcast attacks. VMware
workstation is a nice application to use if an attack should be conducted
Test scenario
59
against several operating systems. VMware workstation can then be used at
the victim to avoid time consuming reboots when switching operating system
as well as safe installation and maintenance.
9.2 The tests
9.2.1 Smurf
When first testing this attack a few errors were found in the code and several
obstacles were encountered. The first test run was started using
attack type smurf destip 130.235.5.255 srcip 130.235.5.174
zombieid 0
but to our surprise there was only one unit replying to the ICMP Echo Request. Using the normal ping utility in Windows resulted in many more replies
than this so something was obviously wrong. By examining the packets sent
in Ethereal, a conclusion was made that the length of the Echo Request packet
was too small. After a couple of new unsuccessful test runs even more errors
in the packet were detected. The IP checksum was not correct, an Ethernet
II checksum was used even though it was not needed and the IP identification and ICMP sequence number was not updated. After fixing these errors,
replies were fetched from 6 computers, but only 3 of them replied continuously
to each request. Discussions led to the conclusion that the switch examines
the incoming spoofed packets and thinks that the victim’s MAC address had
been moved to the port of the sender in the switch. Therefore a reply was
returned on the same port as the request was sent from. This resulted in a
vast majority of replies returned to the sender even though the address was
spoofed. The expected victim did not get nearly as many results. The solution to this problem was to use a non valid MAC address in the source field.
The following command triggered a working Smurf attack in the switched
environment:
attack type smurf destip <BroadcastAddress>
srcip <VictimAddress> srcmac <NonValidSourceAddress>
The attack was later optimized even more, i.e. the checksum was no longer
calculated for each packet but instead only the affected parts of the checksum
were updated. It was once again tested in the test environment (this test
was conducted approximately 3 weeks after the last test) but this time with
a completely different outcome. If the source (victim) MAC address was set
to a non existing one, no packets would reach the victim. The results shown
in the first couple of tests could not be reproduced. Instead, the source MAC
60
Test scenario
Figure 9.1: An extract of packets that reached the victim an early Smurf
attack
address had to be that of the correct MAC of the victim. There were now 16
units replying to the broadcast ping request. Using 1 Zombie and a data size
of 1408 bytes, the result shown in Figure 9.1 appeared in Ethereal. That was
exactly what was expected. 16 units responded to the broadcast ping requests
sent by the Zombie. But the network utilization of approximately 30% was
not enough for a DoS attack though.
The same attack was then executed with 2 Zombies on 2 computers. This
was enough to cause a DoS attack and the CPU utilization rose to 98%. Even
though the victim was flooded enough to be denied of service, it is uncertain
whether one really can consider this a successful smurf attack or not. Sure
enough, the malicious packets from the Zombies were sent to the broadcast
address and that was what made the victim DoS:ed. But it was not the
responding units that caused the DoS attack, rather it was the requests generated by the Zombies as seen in Figure 9.2. The majority of the responding
units were not fast enough to reply to this massive amount of request packets. This explained the irregularities among the request and reply packets in
Figure 9.2. Another thing was that all computers in the subnet were exposed
to the request flood by the two Zombies. That in it self is not wrong but
they received too many requests in a too short period of time, which should
be unnecessary. The intension of the attack is to send a small number of
requests and have the amount of packets multiplied by repliers. The second
Zombie could might as well have been used to flood the victim directly in-
Test scenario
Figure 9.2: When using two Zombies in the smurf attack, more request packets were generated
61
62
Test scenario
stead of taking the detour via broadcast address. This would have spared a
lot of bandwidth consumption for the units not responding to broadcast ping
requests such as computers running Microsoft Windows. Figure 9.3 illustrates
that a lot of traffic is sent to Windows hosts and nothing is returned.
Figure 9.3: The smurf attack demonstrated high throughput to all Windows
hosts but nothing was returned
The attack was also tested with packets using the default data size of
64 bytes. When using only one Zombie the network utilzation at the victim
went up to 20% but after a couple of seconds it went down to 7%. The unit
responses that still got through are shown in Figure 9.4. This was interesting
because when flooding with a large data size of 1408 bytes, the network utilization was on a quite stable level of about 30% all the time, with 17 units
responding. The reason seemed to be that Windows XP has a built in flood
protection. When the packet rate exceeds a certain threshold it seems like
Windows blocks some of the packets. In other words Windows XP does not
seem to care about the amount of bandwidth actually getting through but
rather it only cares about the packet rate. This is illustrated in Figure 9.5.
The attack was stopped for a short period of time, which can be seen in the
small area of Figure 9.5 where the network utilzation is at 0%. The attack
Test scenario
63
was then started again but this time with a data size of 1408 bytes. The
figure shows that the network utilization fluctuated a whole lot upon starting
the attack again, all the way from 9 to 43% before temporary stabilizing at
9%. The reason for this was thought to be that Windows was still blocking
labcam.it.lth.se
rex-7.it.lth.se
bast.it.lth.se
ExLaser.it.lth.se
dplaser.it.lth.se
Figure 9.4: The responding units
packets but since the packet rate dropped with the larger data size it allowed
more packets to get through. Finally after a few seconds the blocking mech-
Figure 9.5: Different data sizes caused different behaviors in Windows.
anism switched off and all the large packets went through again, causing the
network utilziation to raise close to 30% again. The Zombies sent packets in
the rate of approximately 3900 packets per second with the default data size
of 64 bytes. When using a large data size of 1408 bytes, the rate was just 170
64
Test scenario
packets per second. Note that it did not matter if the firewall was turned on
or off, the same result occurred.
Another thing worth mentioning is that a normal ping request was sent
to the broadcast address to see if there were equally many units responding
as when using the Zombie application. This was not the case. There were
actually one unit less responding to the normal ping than to the Zombies ping
request. The reason for this was because the normal ping request was issued
after the last test suite was completed. One of the units, duolaser.it.lth.se, did
no longer respond. It is possible that this unit went down during the attack.
Conclusion
Since Microsoft has chosen to silently discard broadcast ping requests in accordance with [40] the result of the smurf attack in the test environment
is somewhat dubious. The replies were mainly from network units such as
printers, cameras and other embedded systems which were not fast enough
to generate the amount of bandwidth necessary to cause a denial of service
by themselves. It is nothing wrong with the implemented attack, but the
responding units need to be faster. It was shown that by using two Zombies
to flood the broadcast address, the victim was indeed denied of service, but
not in the manner it really should in an optimal smurf attack. The attack
may still very well be used as proof of concept. To initialize a working attack
one can use the following command:
attack type smurf destip <BroadcastAddress>
srcip <VictimAddress> datasize <largeDataSize>
9.2.2 Distributed ICMP Ping
When this attack was first tested the setup consisted of 10 Zombies uniformly
distributed on 10 computers. But each Zombie was only capable of sending
data in the rate of approximately 1000 packets per second. The reason was
due to the high CPU utilization needed to recalculate the packets each and
every time a new packet was sent. The aggregated throughput was only about
9900 packets per second. This was only enough for a 12% network utilization
at the victim.
To speed up the execution, the generation of a packet was moved outside
the sending loop in the Zombie attack and the same packet was sent over
and over again. This payed off and the Zombies now produced about 40000
packets per second. Though moving the packet generation outside the loop
results in a static ICMP identification. This was however solved by increasing
the identification at the same time as decreasing the checksum for each packet
Test scenario
65
sent. This was possible since the identification value is aligned at an even 16
bit offset and the checksum is equal to the bitwise inversed sum of the whole
packet. In english this means that if a value in the ICMP packet is increased
by one, the checksum is decreased by one, though compensations must be
made when the 16 bit integer wraps around its maximum or minimum value.
Using this approach saved a lot of CPU resources and generated a greater
throughput but still not enough for a denial of service attack. The network
utilization at the victim did increase significantly but still not more than to
33%.
Figure 9.6: The CPU utilization at the victim reached to about 100% when
receiving a large amount of packets per second which is not the
primary intention of the ICMP Ping attack
After a while it was noticed that when only using one Zombie per computer
the CPU utilization was only about 66%. In other words, Windows would
not let the Zombie application use all resources and thus the attack could
not be used with full potential. The reason lies within the test environment
and have been discussed earlier in section 9.1.3 on page 56. So instead of
using just one Zombie, 6 Zombies were started on each computer and now
the CPU usage went well up to 100% resulting in an aggregated throughput
of about 53000 packets per second. Though the network utilization at the
victim did not get any higher than 45% which was still not enough for a
66
Test scenario
bandwidth consuming denial of service attack. An interesting observation
was that the CPU utilization at the victim went up to about 100% when
receiving a large amount of packets per second as seen in Figure 9.6. From
the usage perspective this may be regarded as a denial of service attack since
the user cannot operate the computer in a sufficient manner. But this was
not the kind of denial of service attack the attack was intended for primarily.
After thoroughly going through the Zombie application using the AutomatedQA AQtime 4.5 profiler it was noticed that the sendPacket() method
used lots of CPU time. It contained time consuming memory copying from a
vector to an array which were executed every time a packet was sent. By moving this outside the main flood loop the performance increased significantly.
The .NET environment was also set to compile the application as a release
version which was optimized for Pentium 4. After all these improvements
our application was about 150% faster than the previous version. Still the
network utilization did not reach beyond 65% when conducting a full scale
flood. Since the amount of data in the packets used to flood the victim was
of minimal size, experiments were conducted to see if the network utilization
increased with the data size. As expected, a fewer amount of packets were
sent but due to their size 1408 bytes, the bandwidth consumption at the victim increased well up to 99%. A denial of service state was finally reached
due to bogus traffic with large packets. PRTG showed that about 97 Mbit of
malicious data was sent towards the victim which can be seen in Figure 9.7.
Figure 9.7: About 97 Mbit per second of bogus data was sent to the victim.
Test scenario
67
Conclusion
Before optimizing the application, the test environment used was not enough
to flood a victim with bogus requests to cause a denial of service attack in the
common sense. Though the CPU usage would raise close to 100% making the
computer almost impossible to use, hence one could regard this as a denial
of service from the usage perspective. This was due to the time the tcp stack
takes to process a large amount of small packets.
After optimizing the code and increasing the data size to 1408 bytes a
denial of service state was reached. Only 2 computers running 6 Zombies
each were needed. The reason for using big packets is that it takes longer
time to create a huge amount of small packets than a smaller amount of big
packets. Therefore it is easier to produce a high amount of data throughput
using big packets.
9.2.3 LAND
The LAND attack aims for victims running Windows XP SP2 and whose goal
is to raise the CPU utilization to the maximum level due to a weakness in
the system. On the 14th of May 2005 there was a mayor confusion when the
implemented attack had gone from working perfectly to not working at all in
what seemed to be a split second. The reason was that Microsoft had released
a security update (hotfix) called KB893066 one day earlier. To make use of
the attack this hotfix has to be removed from the victims system. To do
this go to settings→control panel→ Add/Remove programs, check the ”Show
updates” box and uninstall the Microsoft XP Hotfix KB893066. When this
has been done, the attack is really easy to execute and it is a great attack in
the terms of low bandwidth consumption. It is initialized by
attack type land ip <victimip> interval <interval>
port <open port>
Note that it is crucial that the source IP address is the same as the destination
IP address and the source port is the same as the destination port. This is
easily done by using the ”ip” and ”port” command in the Control Center.
When exposing a computer to the LAND attack the results depends on
whether the victim have the Windows Firewall turned on or off. If the firewall
is on, Windows XP SP2 will block it self from the network. This happens
because the Windows Firewall recognizes that the computer is under attack
and tries to block the IP sending the packets. But since the source IP is forged
and set to the same IP as the victim, the firewall will block itself from the
network thinking it have blocked the perpetrator. In other words, Windows
has put itself in a denial of service position. The second alternative is when
68
Test scenario
the Windows Firewall is disabled. This will raise the CPU utilization to 100%
making the computer almost impossible to use.
The really interesting part of the LAND attack is that only a few packets
have to be sent to cause this effect. Other attacks requires thousands of
packets per second whereas this attack may require as little as one packet
every 5 seconds. In Figure 9.8 illustrates some different intervals used in
the test and their results on the CPU utilization at the victim. In order to
Figure 9.8: CPU utilizations with different intervals by the LAND attack
guarantee 100% CPU utilization all of the time the interval must be pretty
low, around 200 ms. But it can be increased significantly and still cause a
pretty decent CPU utilization of 100% most of the time. Though the CPU
utilization can fall for a short period of time before the next packet arrives if
the intervall is too great.
Conclusion
The LAND attack is a very nice attack in the terms of low bandwidth consumption. Much can be done with only a few packets per second. The outcome depends whether the Windows Firewall is enabled or not. The drawback
is that Microsoft recently released a patch for this vulnerability (Microsoft XP
Hotfix KB893066) which has to be uninstalled. When that is done, the attack
works great in the test environment.
9.2.4 Pepsi
This attack is aimed against a switch by flooding its diagnostic port with
valid SNMP requests. The goal is to have the switch (in our case 130.235.4.52
(stack-2)) max out its CPU resources so no ordinary packets can be processed
and forwared. By using an application called snmpwalk it was possible to
Test scenario
69
read all available MIBs in the switch. It was decided to query the switch for a
string value hoping it would take longer time to process strings than integers.
The following SNMP message was sent to the switch:
Version: 1
Community: public
PDU type: GET
Request ID: 4a0f
Object identifier: 1.3.6.1.2.1.2.2.1.2.198
(IF-MIB::ifDesc.198)
In the first test flood, 60 Zombies uniformly distributed on 15 computers were
used. The initiating was done by:
attack type pepsi destip <switch ip> srcip <spoofed ip>
An interesting thing about this was that there were actually two units being
exposed to the attack. First there was the switch which was the main objective
for the attack, and secondly there was also the host of 130.235.5.168 which
would receive all the repsonses from the bogus SNMP requests sent by the
Zombies. Using this many Zombies was more than enough to overload the
Figure 9.9: A screenshot of Ethereal when capturing the SNMP traffic generated by the Zombie to and from the switch.
switch with SNMP requests. Since the switch went down the Control Center
lost contact with the Zombies since they were behind the same switch. And
of course PRTG lost contact with the switch as well and could not gather
data. This is the actual proof that the attack worked since this was exactly
what was supposed to happen. The switch was down for almost 10 minutes
after the attack was stopped but after that it seemed to work as it should
once again.
Using 15 computers with totally 60 Zombies for this attack was an overkill.
The same attack was later conducted using only 4 computers with 4 Zombies
each. The switch went down this time as well but came back only shortly
after the attack was stopped (about 1 minute). But this was sufficient to
show that only 4 computers are needed for the attack.
70
Test scenario
Figure 9.10: PRTG lost contact with the switch due to all the bogus SNMP
traffic.
Test scenario
71
Conclusion
The attack itself works very well in the test environment. The switch stops
responding to ”real” SNMP requests and no other traffic gets through the
switch. You cannot use the Internet from the computers that are connected
to the switch for instance. There is one problem with this attack in the test
environment though. That was because the switch that was exposed to the
attack was connected to the Zombies conducting the attack. The contact with
the Control Center was therefore lost. If possible it would be more convenient
to attack a switch not essential for the connection between the Control Center
and Zombies.
9.2.5 WinNuke
This version of WinNuke will only work in Windows 95. To initialize the
attack run:
attack type winnuke destip <Win95 host ip>
interval <interval>
Note that it is not possible to spoof the source address since a TCP connection
needs to be established in order to send an OOB packet. The attack worked
as expected and the infamous bluescreen appeared. The Windows 95 system
had to be rebooted in order to continue usage. It is recommended to use a
high interval since there is usually no need of sending more than one OOB
packet.
Conclusion
This version of WinNuke only works in Windows 95 and is very straight
forward. In all of the tests conducted against a Windows 95 box, a Windows
bluescreen appeared and the computer crashed. Trying to execute this attack
on a computer running something other than Windows 95 as OS will not lead
to anything noticeable.
9.2.6 Distributed Reflective ICMP Ping
When first conducting the test, 2 Zombies and 2 computers were used as
reflectors. A data size of 64 bytes were used but this proved to be insuffcient
to cause a denial of service attack. The network utilization at the victim did
not surpass 7% when sending packets this small. When changing the data
size to a larger size of 1408 bytes, the throughput increased a lot but was still
72
Test scenario
Figure 9.11: The infamous bluescreen after executing a WinNuke attack.
not enough for a successful DoS attack. The network utilization at the victim
now reached to 94%, but still no DoS.
It was not until the test was conducted for the third time, now using 3
Zombies and 3 reflectors, that it was possible to fill up all available bandwidth
and maximize the network utilization at the victim. Hence the attack was
proved to be successful as a DoS attack. Figure 9.12 shows the incoming and
outgoing bandwidth in the switch for the involved ports. Port 222 was the
port for the victim, port 218 was the port for the intermediate host and port
223 was the port for one of the Zombies.
Due to limitations of the test environment (described in Section 9.1.1 on
page 53) a test using 4 Zombies on 2 computers with 2 reflectors were also
conducted. This resulted in a greater total throughput than 3 Zombies on
3 computers with 3 reflectors but in spite of this, all traffic was not totally
blocked to or from the victim. With the first alternative (3 Zombies on 3
computers with 3 reflectors) there were a total throughput of about 140 Mbit
from the Zombies and the second one (4 Zombies on 2 computers with 2
reflectors) provided a total throughput of 190 Mbit. But the victim was still
able to respond to small ping packets about 90% of the time and it was possible
to browse small web pages such as www.google.com and www.wikipedia.com.
Though more demanding pages such as www.idg.se failed to load. It seemed
like the switch had easier to forward data if it is distributed on several ports
than just a few, this might be the reason for this behavior but it has not been
able to get confirmed and is therefore only a speculation.
Test scenario
73
Figure 9.12: 3 Zombies and 3 reflectors with 1408 bytes of data was enough
to cause a distributed reflective ICMP DoS attack
Figure 9.13 shows an extract of a legitimate ping test, which shows that
most packets get through even though the inbound network utilization was
close to 100%.
A final test was also conducted to see if it was possible to cause a total
denial of service attack by still using only two computers but instead using
4 reflectors. The test was also conducted to see whether it was possible to
camouflage the attack by distributing the data on more reflectors so that only
a small amount of the available bandwidth were utilized per reflect. This
test proved to be successful! Using 4 reflectors totally blocked the computer
under attack and each reflector only used half of its available bandwidth as
seen in Figure 9.14. The more reflectors and Zombies used, the harder it is to
spot which computers are participating in the attack. Port 221 and 224 are
Zombies, port 211 to 214 are intermediates (reflectors) and port 222 is the
victim.
To initialize a successfull attack the following command should be used:
attack type icmpping zombieid <id> srcip <victim IP>
destip <intermediate IP> datasize 1408
For an example refer to Figure 9.15.
74
Test scenario
U:\>ping -t fox-24
Pinging fox-24.it.lth.se [130.235.5.174] with 32 bytes of data:
Request timed out.
Reply from 130.235.5.174:
Reply from 130.235.5.174:
Request timed out.
Request timed out.
Reply from 130.235.5.174:
Reply from 130.235.5.174:
Reply from 130.235.5.174:
Request timed out.
Reply from 130.235.5.174:
Request timed out.
Reply from 130.235.5.174:
Request timed out.
Reply from 130.235.5.174:
Request timed out.
Reply from 130.235.5.174:
Request timed out.
Request timed out.
Reply from 130.235.5.174:
Reply from 130.235.5.174:
Reply from 130.235.5.174:
Reply from 130.235.5.174:
bytes=32 time=1ms TTL=128
bytes=32
bytes=32
bytes=32
bytes=32
time=1ms
time=1ms
time=1ms
time=1ms
TTL=128
TTL=128
TTL=128
TTL=128
Ping statistics for 130.235.5.174:
Packets: Sent = 22, Received = 13, Lost = 9 (40% loss),
Approximate round trip times in milli-seconds:
Minimum = 1ms, Maximum = 1ms, Average = 1ms
Figure 9.13: A legitimate ping test shows that some packets get through
even though the inbound network utilization is close to 100%
Test scenario
Figure 9.14: 2 computers each running 2 Zombies and 4 reflectors was
enough to cause a total distributed reflective ICMP DoS attack
75
76
Test scenario
Figure 9.15: An example of how to initialize a successfull distributed reflective ICMP attack
Conclusion
It was possible to conduct a successful distributed reflective ICMP ping attack
in the test environment used. A minimum of 8 computers were needed. 2
computers were used as Zombies (but each computer had to run 2 Zombies),
4 computers as reflectors, one as Control Center and one as victim. Another
alternative would be to have 3 computers each running one Zombie and use
3 reflectors instead (as in Figure 9.15). The data size should be set to 1470
bytes which is the maximum data size for an non fragmented ICMP packet
in Ethernet II.
9.2.7 ICMP Ping Bounce
The purpose of an ICMP ping bounce (or just ICMP bounce) attack is to
overflow two hosts simultaneously with malicious data. The special thing
about this attack is that the two victims should help to contribute to the
overload by sending packets between themselves as well. The trick is to have
two Zombies, one flooding the first victim with the source IP address set to
the IP address of the second victim and vice versa. For instance this will
trigger a working ICMP ping bounce attack:
attack type icmpping zombieid <id0>
destip <victim IP0> datasize
attack type icmpping zombieid <id1>
destip <victim IP1> datasize
srcip <victim IP1>
1408
srcip <victim IP0>
1408
The attack worked perfectly the first time it was launched using 1408 bytes
as data size. 2 Zombies flooding and 2 victims flooding between themselves
was enough for a DoS attack as expected. As seen in Figure 9.16 the two
Test scenario
77
victims sent data between themselves in half the rate of the received data
from the Zombies.
Figure 9.16: 2 Zombies flooding and 2 victims flooding between themselves
was enough for an ICMP Bounce DoS attack.
Conclusion
The attack worked as expected and since the two victims also flooded each
other, not as many Zombies were needed. It would have been nice to be able
to limit the packet rate since then it would have been possible to determine
how many packets each Zombie needed to send to cause a DoS attack. But
despite this the attack was very well suited in the test environment.
9.2.8 Distributed UDP Flood
The attack was first initialized using:
attack type udpflood srcip 10.0.0.1 destip 130.235.5.174
datasize 1408
where the srcip was a spoofed address. Two Zombies were used on two computers. When the attack was started, contact was lost to both Zombies after
just a few seconds. This appeared to be quite strange at first so a second
test was conducted in an environment not running Windows XP SP2. Here
78
Test scenario
the attack worked flawlessly and no problems were encountered. The problem was that the source IP of ”10.0.0.1” resolved to MAC address 0. The
switch in the test environment was configured to drop packets such as these
since the source MAC should not exist in the network. If a spoofed packet is
sent, the real address is blocked for a certain amount of time (as described in
Section 9.1.1) and therefor the connections to the Zombies were lost.
After initializing the attack as
attack type udpflood srcip 130.235.5.160
destip 130.235.5.174 datasize 1408
now using a source IP and MAC inside the same network as the Zombie, the
attack worked without any problems in the test environment as well. Using
only two Zombies on two computers was not enough for a denial of service
attack though. Only about 94% of the bandwidth was consumed at the victim
(94 Mbit malicious data was sent from the switch to the victim).
Using 3 Zombies on 3 computers, each one sending about 4000 packets
per second, resulted in denial of service. The victim only received about 8500
packets per second, the rest of the packets were dropped by the switch due
to insufficient bandwidth as seen in Figure 9.17. Port 221, 223, 224 are the
Zombies and port 222 is the port of the victim.
Figure 9.17: PRTG screenshot where 3 Zombies flooding with 4000 pps
each, causing denial of service.
Test scenario
79
The attack was later tested to see if only using two computers were necessary for a successful attack when running two Zombies on each one. This
proved to be successful and another denial of service attack was witnessed.
The results can be seen in Figure 9.18. Port 221 and 224 are the computers
each running two Zombies and port 222 is the victim. When looking at the
figure more closely one can notice that the victim is not really overloaded
with malicious requests. The victim still have a small amount of bandwidth
left to responde to a small percentage of the incoming requests. But this did
not really matter in this case since it only contributed the achievement of the
DoS attack.
Figure 9.18: PRTG screenshot where 4 Zombies flooding on two computers
with about 4000 pps per Zombie, causing denial of service.
Conclusion
It was possible to achieve a denial of service attack using 3 computers running
one Zombie each or using 4 Zombies on two computers. Though one had to
be certain to use a source MAC of the same network as the Zombies when
running in the test environment. This should not be of any concern if the
attack is performed in a network without MAC filtering on the switch. In
the test environment used in this test, the following initialization command
triggers a working attack:
attack type udpflood srcip 130.235.5.160
80
Test scenario
destip 130.235.5.174 datasize 1408
9.2.9 Fraggle
Since neither Windows nor Linux replies to UDP echo requests by default,
there were small hopes of actually witnessing a denial of service attack when
running this attack. To see that the implementation was correct, Fedora Core
3 (Linux) was installed in VMware 4.5 and it was configured to answer on
UDP echo requests by issuing the following command:
chkconfig echo-udp on
as root.
A test was then conducted by sending UDP echo request packets with
spoofed source addresses to the broadcast address. The specially configured
Linux host replied to the request, not just once, but to our surprise twice.
The suspicions were directed against VMware 4.5 and when sending a normal
ping request to another VMware guest OS the result seen in Figure 9.19
appeared. This showed that there were 4 replies for each request, 3 of these
ping -i 10 cyan
PING cyan.net (192.168.15.43) 56(84) bytes of data.
64 bytes from cyan.net (192.168.15.43): icmp_seq=0 ttl=128
time=3.92
time=4.09
time=4.09
time=4.09
ms
ms (DUP!)
ms (DUP!)
ms (DUP!)
Figure 9.19: An extract of ping replies between two VMware 4.5 hosts
were dupes. To see why, Ethereal was used to sniff packets at the receiving
host (cyan.net). Ethereal showed that it received two requests even though
only one was actually sent. An extract can be seen in Figure 9.20. It first
Figure 9.20: Ethereal saw a multiplication of requests which explains the
extra reply packet
looked as VMware somehow duplicated directed packets that were sent within
VMware since the host receiving the ping requests saw two requests instead
of one. Therefore it responded with two ping replies. These replies would also
be duplicated and resulted in the 4 replies seen in Figure 9.19. But pinging a
VMware guest from another computer resulted in no multiplication of packets.
Test scenario
81
So this did not explain why there were 2 replies for each ICMP ping request
packet that was sent to the broadcast address. The reason seemed to be
that the attack was tested between two VMware guest systems on the same
host which had two enabled network devices. This caused the duplication of
packets. This problem only occurred with this configuration.
The attack was also tested in the test environment. As expected, there
were no hosts listening on the UDP Echo port and thus a DoS attack could
not be produced.
Conclusion
The attack did not work in the test environment since there were no hosts
that replied to the UDP echo port. It may be possible to activate this port
and reply to UDP echo requests in Windows by using a special service or
daemon (as it is in Linux) but this has not been looked into further. The
implementation of the attack was correct which was proven in Linux. Though
there were some problems with the test due to multiple network devices in
VMware 4.5 which resulted in more replies than what is usually expected.
This should however not be of a big concern since this behavior should not
be common. The ping issue was successfully tested in VMware 5.0 on a
system with two network devices (but only one was physically connected to
a network) without multiplication of packets which proves that the attack
works as expected.
9.2.10 TCP/SYN Flood
This attack has several limitations when being used in the current test environment. When this test was first executed it was initialized without specifying an open TCP port at the victim end when the Zombie was running
on Windows XP SP2. This will not work, the specified port must be open.
Secondly, it was not possible to spoof a source MAC address outside the test
environment. It does not matter if the source IP address of a packet is set
to a non existing IP address inside the test environment, since the source
MAC address has to be valid. The victim will therefore always have a valid
source address to reply to. This means that if a Zombie floods a victim with
TCP/SYN request packets, the victim will respond to a valid source address
with a SYN+ACK respond packet. The source host will in its turn respond
to the victim with an RST (reset connection) packet since it have not actually
requested a connection. Because of this, the connection will close and therefore there will be no half open TCP connections which is essential for this kind
of attack. In other words is it impossible to successfully execute a TCP/SYN
denial of service attack in the test environment. Windows XP SP2 also have
82
Test scenario
Figure 9.21: A screenshot from TcpView by SysInternals. All ”SYN RCVD”
states are half open TCP connections.
Test scenario
83
a limitation of how many incomplete outbound TCP connections that can
exist simultaneously (Section 9.1.1 on page 56). This is also a reason why it
is virtually impossible (without a third party patch) to conduct a TCP/SYN
flood from a Windows XP SP2 host.
The attack can however be demonstrated by running the Zombie on a
Windows XP computer with SP1 or lower or also Windows 2003 Server. It is
almost certain that it can be conducted (using our application) from a Zombie
running on other versions of Windows as well, like for instance Windows NT
and Windows 2000 but this has not been tested. Using an XP SP1 host
outside the test environment made it possible to spoof the source IP and
MAC addresses and therefore the victim would not receive any RST packets
that terminated the connection. The result - half open TCP connections that
has to be taken care of by the operating systems TCP stack or a denial of
service attack will be present.
Windows 2000 and XP incorporate a form of adaptive encrypted token
SYN spoofing immunity that automatically ”kicks in” when a Windows 2000
or XP machine is under a SYN spoofing attack [34]. Therefore the Windows
XP SP2 victim the attack was directed against was immune to the TCP/SYN
flood (i.e. no DoS) but a proof of concept is shown in Figure 9.21 and Figure 9.22.
Figure 9.22: Approximately 3300 TCP/SYN packets per second was sent to
the victim.
To see that the attack actually do work, an attack was directed against
84
Test scenario
a Linux host running Knoppix 3.8.2. The default settings for Linux is to
have SYN Cookies (Section 5.1 on page 23) turned off. The attack proved to
work as expected. There were 769 half open TCP connections and it was not
possible to connect to the SSH server running on the Linux host nor was it
possible to reach the web from the same machine.
# netstat -ta|head -n2;netstat -ta|grep SYN_RECV
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address
Foreign Address
tcp
0
0 knoppix.it.lth.se:ssh
fox-15.it.lth.se:31875
tcp
0
tcp
0
tcp
0
tcp
0
tcp
0
tcp
0
State
SYN_RECV
SYN_RECV
SYN_RECV
SYN_RECV
SYN_RECV
SYN_RECV
SYN_RECV
Figure 9.23: An extract of the netstat command in Knoppix while the host
was under a TCP/SYN attack.
When turning on SYN Cookies there were even more half open connections, more specifically 1024, but it was still possible to surf the web and
connect to the SSH server.
Conclusion
The following command will initialize a working TCP/SYN attack for a Zombie outside the test environment (i.e. on a network that this is not dropping
packets with a falsified MAC address):
attack type tcpsyn srcip 130.235.5.190 srcmac aabbccddeeff
destip 130.235.5.174 destport 135
The victim’s operating system will decide whether a DoS attack is possible
or not. Flooding a Windows XP machine will not result in a DoS attack.
Flooding a Linux host will result in a DoS attack if SYN Cookies are not
used. The attack can always be used as a proof of concept if the Zombie is
running on a Windows OS other than XP SP2. TcpView by SysInternals is
a good utility for detecting half open TCP connections in Windows.
9.2.11 Distributed Reflective TCP/SYN
Because of the limitations in the test environment, problems were expected
when running this attack. To be sure that the attack actually did work and
was properly implemented, it was first tested in another environment using
Test scenario
85
a Linux host running Knoppix 3.8.2 as victim and another Linux host running Gentoo (2.4.24 kernel) as intermediate. The victim host was configured
to block all incoming TCP traffic on a specific port. By doing so, no RST
packet was sent back to the intermediate host. This is crucial in order to get
the intermediate host to retransmit SYN+ACK packets. If an RST packet
is received by the intermediate host it will stop sending SYN+ACK packets.
If no RST packet or connection confirmation is received by the intermediate
host, it will retransmit the SYN+ACK packet believing it was lost in transfer,
thus multiplying the amount of data sent from the Zombie (see Section 3.1
on page 11). So when using Linux as the host OS of the victim, the intermediate host retransmitted the TCP/SYN packets 6 times for each SYN packet
received from the Zombie.
Figure 9.24: Packets captured in Ethereal during a distributed reflective
TCP/SYN attack. SYN+ACK packets are sent 6 times for
each SYN query.
According to [2], a SYN+ACK packet should only be resent up till 3
times but this test showed twice that value. The difference depends on which
operating system that is being used for the intermediate host. A test with
Windows XP SP2 as the intermediate host and with a victim (Windows 2000
Pro running Zone Alarm 4.5, not a part of the test environment) configured to
block connections showed that Windows only multiplies SYN+ACK packets
three times. This agrees with what is being said in [2] if the author is referring
to a Windows host. But as this experiment (using Linux as intermediate host)
showed, different operating systems may resend SYN+ACK packets different
amount of times.
Trying to recreate this scenario in the Windows XP SP2 test environment
proved to be very difficult. After having studied the Windows firewall it
was concluded that it only supported two modes for each port, enabled and
disabled. Configuring the port as disabled would return an RST packet to
the sender which was undesirable. If it on the other hand was configured as
enabled, it would reply with an ACK packet which was equally undesirable.
So configuring Windows XP to block packets (i.e. just drop the incoming
packets instead of sending a reply) without a third party software seems to
86
Test scenario
be impossible.
Several other firewalls were tested to see if they would provide what was
needed. First off was Zoom Alarm 4.5. By using this application it was
possible to block certain ports and it was also successfully tested on a Windows
2000 Pro host. But after having installed first Zone Alarm at the victim in
the test environment, the machine would fail to boot. It stopped during
the loading of Windows when login information was to be gathered from the
domain. That same problem occurred with Sygate Personal Firewall Pro.
So using either one of these two applications made it impossible to login to
the domain in our test environment and therefore it was also not possible to
conduct any tests. A third firewall was also tested, Tiny Personal Firewall.
But it was an application specific firewall and could not deal with the more
advanced features that was needed for this test.
Despite all this the attack was tested in the test environment. During
all tests, a total number of 28 Zombies were used on 7 computers and 7
computers were also used as intermediate hosts. The first time the test was
executed it used destination port 999 which was closed on all the intermediate
hosts. The result was that the victim was flooded with RST packets instead
of the intended SYN+ACK packets. An interesting observation was that the
intermediate host did not answer all SYN packets with an RST packet. Some
packets were dropped and not replied to. The reason for this is most likely
due to the Windows Firewall (which was not disabled on the intermediate
hosts) or that SP2 was all stacked up with TCP connections so it was forced
to drop some of them. The network utilization at the victim rarely surpassed
15% as illustrated in Figure 9.25 which was not enough for a DoS attack.
The second test was directed against an open TCP port (135). Now
the victim received the expected SYN+ACK packets but also several RST
packets. The reason behind the RST packets was probably because the firewall
rejects packets if the rate is too high. Worth mentioning is that the network
utilization landed on a modest 13%. The mean CPU utilization seemed to
increase a little bit though, but nowhere close to 100%.
To initialize an attack like this can be quite complicated so Figure 9.26
illustrates an example of how it was done in the test environment. The source
IP (”srcip”) is the IP to the victim and the destination IP (”destip”) is the
IP to an intermediate host.
Conclusion
This attack never lead to a satisfying denial of service attack. The retransmission of SYN+ACK packets were not working in the test environment since
it was not possible to configure the victim to block SYN+ACK packets. A
Linux host as a victim would be recommended since it can be configured to
Test scenario
Figure 9.25: Packet rate for each computer in the setup when exposed to
the attack.
87
88
attack
attack
attack
attack
attack
attack
attack
attack
attack
attack
attack
attack
attack
attack
attack
attack
attack
attack
attack
attack
attack
attack
attack
attack
attack
attack
attack
attack
Test scenario
type
type
type
type
type
type
type
type
type
type
type
type
type
type
type
type
type
type
type
type
type
type
type
type
type
type
type
type
tcpsyn
tcpsyn
tcpsyn
tcpsyn
tcpsyn
tcpsyn
tcpsyn
tcpsyn
tcpsyn
tcpsyn
tcpsyn
tcpsyn
tcpsyn
tcpsyn
tcpsyn
tcpsyn
tcpsyn
tcpsyn
tcpsyn
tcpsyn
tcpsyn
tcpsyn
tcpsyn
tcpsyn
tcpsyn
tcpsyn
tcpsyn
tcpsyn
srcip
srcip
srcip
srcip
srcip
srcip
srcip
srcip
srcip
srcip
srcip
srcip
srcip
srcip
srcip
srcip
srcip
srcip
srcip
srcip
srcip
srcip
srcip
srcip
srcip
srcip
srcip
srcip
130.235.5.174
130.235.5.174
130.235.5.174
130.235.5.174
130.235.5.174
130.235.5.174
130.235.5.174
130.235.5.174
130.235.5.174
130.235.5.174
130.235.5.174
130.235.5.174
130.235.5.174
130.235.5.174
130.235.5.174
130.235.5.174
130.235.5.174
130.235.5.174
130.235.5.174
130.235.5.174
130.235.5.174
130.235.5.174
130.235.5.174
130.235.5.174
130.235.5.174
130.235.5.174
130.235.5.174
130.235.5.174
port
port
port
port
port
port
port
port
port
port
port
port
port
port
port
port
port
port
port
port
port
port
port
port
port
port
port
port
135
135
135
135
135
135
135
135
135
135
135
135
135
135
135
135
135
135
135
135
135
135
135
135
135
135
135
135
destip
destip
destip
destip
destip
destip
destip
destip
destip
destip
destip
destip
destip
destip
destip
destip
destip
destip
destip
destip
destip
destip
destip
destip
destip
destip
destip
destip
130.235.5.161
130.235.5.166
130.235.5.166
130.235.5.166
130.235.5.166
130.235.5.159
130.235.5.159
130.235.5.159
130.235.5.159
130.235.5.164
130.235.5.164
130.235.5.164
130.235.5.164
130.235.5.163
130.235.5.163
130.235.5.163
130.235.5.163
130.235.5.162
130.235.5.162
130.235.5.162
130.235.5.162
130.235.5.160
130.235.5.161
130.235.5.160
130.235.5.161
130.235.5.161
130.235.5.160
130.235.5.160
datasize
datasize
datasize
datasize
datasize
datasize
datasize
datasize
datasize
datasize
datasize
datasize
datasize
datasize
datasize
datasize
datasize
datasize
datasize
datasize
datasize
datasize
datasize
datasize
datasize
datasize
datasize
datasize
1408
1408
1408
1408
1408
1408
1408
1408
1408
1408
1408
1408
1408
1408
1408
1408
1408
1408
1408
1408
1408
1408
1408
1408
1408
1408
1408
1408
zombieid
zombieid
zombieid
zombieid
zombieid
zombieid
zombieid
zombieid
zombieid
zombieid
zombieid
zombieid
zombieid
zombieid
zombieid
zombieid
zombieid
zombieid
zombieid
zombieid
zombieid
zombieid
zombieid
zombieid
zombieid
zombieid
zombieid
zombieid
27
26
25
24
23
22
21
20
19
18
17
16
15
14
13
12
11
10
9
8
7
6
5
4
3
2
1
0
Figure 9.26: An example of how to initialize a distributed reflective
TCP/SYN attack.
block certain ports without third party software. Having a computer running
Linux as the victim, the attack does not require more than 3 computers (one
as victim, one as intermediate (reflector) and one for the Zombie and Control
Center combined) to prove its concept. A high interval can be used during initialization in the Control Center so that one can use Ethereal to sniff packets
to see the packet multiplication process. It is most likely possible to conduct
the attack on a Windows XP host as well to prove the concept of the attack.
But then a third party firewall or similar must be used in order to configure
a port to block packets (no RST reply). Due to insufficient access rights this
could not be tested properly. One thing to notice is that it is of no use trying
to change the data size in the packets from the Control Center. This is of
course due to the fact that it is the intermediate hosts that sends packets to
the victim and these packets are ”independent” of what is being initialized in
the Control Center.
9.2.12 PoD2
Testing this attack proved to be very troublesome. The attack was first conducted from a Windows 2000 Professional host OS against a Windows 95
(4.00.950) guest OS running in VMware 5.0. Everything seemed ok when
sniffing the packets in Ethereal in Windows 2000 Professional but the ex-
Test scenario
89
pected outcome, a Windows 95 bluescreen, did not appear. The first thought
was that VMware had a built in protection for this attack. Lots of effort was
put into figuring out whether this was the case or not. Many packet sniffers
were installed to see if VMware just blocked the incoming packets. But none
of the installed sniffers worked in Windows 95. Today, 10 years after the
release of the first Windows 95 version, it is difficult to find any compatible
software or drivers for this OS. Finally, the hypothesis was rejected after testing the application on a Windows 2000 Server host also running in VMware
with Sygate Personal Firewall Pro 5.5 which detected a Ping of Death attack
as seen in Figure 9.27. This proved that VMware did not filter the malicious
Figure 9.27: The Sygate firewall detected a Ping of Death attack
packets before forwarding them to the guest OS.
The next thing tried was to install Windows NT 3.51 in VMware after
having read that this system was also affected by the PoD bug. But this
failed due to problems with the installation process. First, the Windows
NT 3.51 installation CD was booted from a Windows 95 boot loader that
for some reason created a ramdisk as drive A: (see Figure 9.28). This created
problems later during the installation when the installer wanted to write three
floppies which had to be inserted into drive A:. This failed because of the
ramdisk. There were never a choice to insert the disks into another drive so
the installation could not continue.
Secondly Windows NT 3.51 was tried to be installed by upgrading from a
running version of Windows 95 (not running in VMware) to see if the installation worked better than before. This did not work at all, it was not possible
to upgrade a Windows 95 host to a Windows 3.51 host from setup files.
Later the three disks needed by the installation program was found on the
installation CD and after creating these disks it was possible to boot directly
from them instead of the Windows 95A boot loader. Hence no ramdisk was
created and it was possible to use drive A:. But this did not help too much.
After a short period of time the installer wanted the installation CD in drive
D:. But the installation did not detect a CD in the drive even though it was
properly inserted. For the moment no resolution to the problem has been
90
Test scenario
Figure 9.28: The ramdisk created by the Windows 95A boot loader that
occupied drive A:
found.
Another reason for upgrading to Windows NT 3.51 in the first place was
because Windows 95 did not support the Realtek 8139 network device that
was mounted in the computer from scratch. The hopes were that Windows
NT 3.51 would support the device but when the installation failed a thoroughly search for drivers supporting the network device in Windows 95 were
conducted. Finding drivers to such an old operating system as Windows 95
proved difficult. Ater a while, drivers were found for the Realtek 8139 network device that should work in Windows 95 according to the description.
But the size of the driver were of such size that there were not enough 1.44
Mb floppies to copy the driver to the Windows 95 computer. A CD could
not be used at the particular moment since the CD burner was currently not
installed in the computer having the files. The easiest way to transfer the files
was to boot Knoppix 3.8.2 from the CD on the same computer as the one running Windows 95. Knoppix found the network device without any problems
and from here the drivers were downloaded and copied into the Windows 95
partition. Though it was still not possible to install the network device using
these drivers.
After several attempts with different device drivers the network device was
exchanged for a 3Com 3C900. But the same difficulties of finding drivers arose
with this device as well. A third attempt was made with a 3Com 3C905B
but still no luck. Finally, a really old ISA card, Realtek 8019, was mounted
in the computer. Initially this led to even more problems since it was not
compatible with the built in SCSI card so the hard drive running Windows 95
could not be used. But after having mounted an IDE hard drive and installed
Windows 95 on this drive, it was able to boot once again. Now Windows 95
finally found the card and was able to use it without any additional device
drivers.
Test scenario
91
Even though this much effort was put into having a real Windows 95 host
running with network support, the PoD attack still did not work. According
to [35], a Windows 95 host may crash itself if running the normal ping utility
with a too large packet size, say 65510 bytes. Though the packet size must
be greater than 65507 bytes for a PoD attack to work. So for instance
ping -l 65510 <ip>
may crash the Windows 95 computer when transmitted, but it did not have
this effect on the version that was just installed. But according to the same
site, it was also quite common that nothing happened to the host being exposed to the attack. What caused these different behaviors for different people
never emerged.
Another attempt to test the attack was made. This time Red Hat 5.2
within VMware 4.5.2 was tried to be installed but the installation process
was disrupted because of an ”incorrect architecture” error and had to be
abandoned.
Finally Debian 2.1 was installed within the same VMware and the kernel
was replaced from the enclosed 2.0.38 kernel to version 2.0.23 which should be
vulnerable to the PoD attack. But the Zombie application failed to crash this
OS as well. But now it was possible to crash the Linux system from Windows
95 using the ”ping -l 65510” command from the command prompt. Finally
it was proved that there was something wrong with the implementation of
the PoD attack in the Zombie. After hours of debugging the error was finally
found and corrected. The problem was that the packet length was 8 bytes too
long since the UDP header length was added to the length of the packet despite
that a header was never included in the fragment. This was really difficult to
spot since Ethereal, which was the program used to capture packets, reported
no errors. It was not until the packets were captured on the Linux host using
tcpdump icmp
that it was possible to see that it was actually a programming fault and not
because the system was invulnerable to the attack. The error response from
tcpdump was quite difficult to interpret since it said that the IP was truncated.
An extract of the error messages can be seen in Figure 9.29. When the length
problem was corrected the attack worked just as well as when sending the
malformed ping packet from the Windows host using the normal ping utility.
Note that it is not possible to send packets of a greater size than 65500
bytes with the ping utility in most modern operating systems and therefore
it cannot be used to recreate this attack in those systems. Anyway, the Linux
system crashed and VMware displayed the error seen in Figure 9.30 but this
error message may differ depending on the size of the packet. The attack did
92
Test scenario
11:15:40.662341
11:15:40.662341
11:15:40.662341
11:15:40.662341
11:15:40.662341
11:15:40.662341
mog.homenet > umaro.homenet: icmp: echo request (frag 21887:1480@0+)
mog.homenet > umaro.homenet: icmp: echo request (frag 21887:1480@0+)
truncated-ip - 8 bytes missing!mog.homenet > umaro.homenet: (frag 21887:1488@1480+)
Figure 9.29: In discordance with Ethereal, Tcpdump found that 8 bytes were
missing in the packet
*** Virtual machine kernel stack fault (hardware reset) ***
The virtual machine just suffered a stack fault in kernel mode.
On a real computer, this would amount to a reset of the
processor. It can be caused by an incorrect configuration of
the virtual machine, a bug in the operating system, or a problem
in the VMware Workstation software. Press OK to reboot virtual
machine or Cancel to shut it down.
Figure 9.30: The error message displayed in VMware 4.5.2 after the PoD
attack was executed with a packet size of 65525 bytes
however not work against the Windows 95 version that was installed, even
though it was supposed to be the first version of this OS with no patches.
The reason why it did not work could not be found.
Conclusion
It was a great difficulty to successfully test this attack. Since the Sygate
Personal Firewall Pro 5.5 logged that a Ping of Death attack was detected
when executing the attack against a Windows 2000 server host, it was first
believed that the attack did work as expected i.e. no implementation fault.
But even though the error was finally found and corrected, it was not possible
to see any artifacts in Windows 95. It is nothing wrong with the Zombie
application, rather it is the outcome of the attack that can be so versatile
that it is difficult to actually spot the attack. Our assumption of a bluescreen
or reboot in Windows 95 was not noticeable, nothing seemed to happen at all.
But according to [35] this does not mean that something has to be wrong. An
explanation to why only some Windows 95 hosts are affected have not been
found. It was however possible to successfully test this attack against an old
Linux host, which crashed upon receiving the malformed packets. The attack
did not work in the test environment.
Test scenario
93
9.2.13 Teardrop
Because of the difficulties in testing the PoD attack, not as much effort was
put into testing this attack. The Teardrop attack (also known as the UDP
Fragment Flood attack) is also a very old and well known attack that is
intended for older systems such as Windows 95 or Linux prior to 2.0.32 and
would therefore not work in this test environment [36]. The attack may of
course be used as a normal bandwidth consuming denial of service attack but
there are other attacks, such as the distributed UDP Flood, that does this
better. When initializing the attack with one Zombie using an interval of 3000
ms the information in Figure 9.31 was extracted from Ethereal.
Figure 9.31: Ethereal was used to see that the packets received were really
fragmented
During this attack it was noticed that the CPU utilization at the victim
increased to about 20% every time the victim received a packet. Therefore
a new attack was executed using 8 Zombies on 4 computers to see whether
the CPU utilization could be increased close to 100% and in that case to see
if it was because of the fragmented packets or not. With the interval option
removed, thus flooding in the maximum speed with an aggregated packet rate
of about 33000 packets per second, the CPU utilization went up to 25% with
a bit of fluctuation. In other words, the increase in CPU utilization was not
proportional with the increase of packet rate. The network utilzation was
about 15%. To see whether the CPU utilization depended on this attack
specifically, which was not very likely after the last test, a distributed UDP
Flood with the default data size of 64 bytes was conducted with equally many
Zombies on equally many computers. As expected, the CPU utilzation at the
victim increased a lot upon receiving the packets, even more than the UDP
fragment flood. The fluctuation was greater, now varying between 66% and
79%. The network utilization was much greater than the UDP fragment
94
Test scenario
Figure 9.32: A comparison between the CPU and network utilization of the
Teardrop flood (the two topmost figures) and distributed UDP
Flood (the two bottom most figures)
flood, about 63%. The aggregated packet rate of the distributed UDP flood
was about 32000 packets per second. A summary can be found in Figure 9.32.
The test was also conducted against a Windows 95 host, both under
VMware 4.5 and as a standalone installation but without any noticable artifacts occuring.
Conclusion
The Teardrop attack does not work in the way it is supposed to in the test
environment running Windows XP SP2. This attack aims for much older
systems such as Windows 95 or old versions of Linux and is not suitable in
the test environment used. The attack can never the less be initialized by the
following command:
attack type teardrop destip <dest IP>
Test scenario
95
srcip <source IP> datasize <dataSize>
9.2.14 Overall conclusion
Windows XP SP2 is not the best test environment imaginable for testing DoS
attacks due to its built-in protective mechanisms. But as seen above it was
still possible to conduct several successful attacks to and from a Windows
XP SP2 host. In a real situation, it is recommended to at least use a version of Windows 2000 and/or possibly even Linux if the DoS application is
further developed. Since a part of the thesis was to examine the possibility
of using Windows XP SP2 as the foundation for a DoS attack (as this was
the OS present in the test environment), the focus has mainly been on this
OS. And indeed Windows XP SP2 was proven to work with some exceptions.
One problem was the packet rate limit per Zombie process and the failure of
fetching ARP replies. This was resolved by starting several Zombies on the
same computer and having them communicate with IPC. Another problem
was that it was not possible to spoof the source MAC of a packet in the test
environment because the switch drops packets with unaccepted source MACs.
To see that the old attacks (such as WinNuke or PoD2) are working,
older operating systems or a Firewall capable of detecting these attack must
be installed. A good way would be to install Microsoft Virtual PC (not tested)
or VMware and use Windows 95 or an old Linux version as a guest OS in those
programs, just as in some of the test cases above. It is possible to install a
trial version of VMware that can be used for evaluation.
The outcome of some attacks were better than others. It were, in most
cases, easier to conduct bandwidth consuming DoS attacks such as ICMP
ping than attacks that used exploits such as PoD2. The reason is of course
that bandwidth consuming DoS attacks are independent of the victim’s OS
whereas exploit attacks often require a certain OS or that a particular hotfix
is not present.
In some of the test cases above, comparisons of outcome between large
and small data size were examined. A data size of 1408 bytes were frequently
used to test an attack with a large data size. The maximum value for the
data size in the application is 1470 bytes though. The reason for choosing
1408 bytes were that this was the the maximum size for a previous version
of the Zombie that had not yet been optimized. If a packet size exceeds 1500
bytes, which is the Ethernet II limit, the computer will crash upon sending
the packet. 1408 bytes proved to be a safe value when testing the attacks. It
was later calculated that the maximum data size was 1470 bytes. This value is
calculated from the maximum Ethernet II packet size − IP header size − TCP
header size = 1500−20−10 bytes = 1470 bytes. The IP and TCP header sizes
are the largest combination of header sizes that our DoS application will use.
96
Test scenario
It would be physically possible to, for instance, conduct an ICMP ping attack
with a larger data size than 1470 bytes (without fragmentation), but it would
have taken too much time to implement an attack/packet specific data size
limit. 1470 bytes is therefore used as the limit for all attacks where applicable.
Even though some the attacks were tested with a data size of 1408 and not
1470 bytes, it was enough to prove the concept of behavior when comparing
small packet sized attacks (with 64 bytes of data) to large ones.
Overall, the outcome was good. The only attack, namely the old Teardrop,
did not work. It should be possible to use this DoS application in a laboratory
experiment for some of the attacks. But since some of the attacks requires
several computers it may be difficult to gather as many computers needed for
a big laboratory group.
Chapter
10
Discussion
Overall the project has been a success. It was proven that it is possible to
use Windows XP SP2 in a test environment (even though it is not recommended). A DoS application capable of conducting several different kinds of
attacks, both distributed and distributed reflective, was implemented and the
attacks were thoroughly tested. Generally speaking it is easier to implement
bandwidth consuming attacks than system resource consuming attacks. This
is because system resource attacks make use of exploits in an OS and therefore the perpetrator needs greater knowledge about the system. On the other
hand the perpetrator must use several hacked zombie machines to successfully conduct an bandwidth attack, whereas a system resource attack often
work with only one. The DoS attack application was specifically developed
to suit a test environment. It is for instance impossible to flood a host that is
located outside the the boundaries of the local network if no special argument
is passed to the Zombie at startup (an exception is if a packet is manually
forged to reach the gateway). Another thing is that the chosen multicast address of 224.0.0.1 only broadcasts to devices in the local network. If needed,
it is possible to specify the IP address to the Control Center when starting
up a Zombie together with the ”-n” (no test environment mode) switch so
that victims, Zombies, and Control Center’s can be in separate networks.
Though this mode should be used with extreme caution since it may (if used
irresponsibly or maliciously) cause severe damage to foreign hosts.
It would have been much easier to use a completely stand alone test
environment that was not a part of a domain that automatically updates
hotfixes and patches. For a laboratory experiment it is highly recommended
to use a stand alone test environment partly because of the hotfix update
”problem” and partly so that it will be physically impossible to disturb other
networks.
As always there are room for improvements in several areas. For instance
UDP communication could have been used between the Control Center and
97
98
Discussion
the Zombies. Partly to save some bandwidth (though it would hardly make
any noticeable significance since the data flow between them are quite limited)
and partly so that the Zombies will not be terminated due to a lost communication link when network is overloaded. Another thing to improve would
be the processes of choosing a network device at the Zombie. If the Zombie
should use a different network device than the default device (which is the
second device that WinPcap discovers, the first is a generic device), this have
to be specified by the ”-d” switch and then manually chosen from a list that
appears on the screen. This would be a disaster if one has to do this for each
Zombie on every host. It would have been much better to pass the network
device as an argument to the Zombie at startup. There are of course many
more improvements that could have been made. A Linux port would be very
desirable for example. The application is written in such a way though that
it should not be too difficult to do exactly that.
Chapter
11
Abbreviations
AH
API
ARP
BGP
BSD
CD
CLI
CPU
CRC
DNS
ESP
FIB
FTP
ICMP
IDS
IKE
IP
ISA
ISP
IRC
IRQ
MAC
MSS
MTU
OOB
PoD
RAM
RPC
RPF
Authentication Header
Application Programming Interface
Address Resolution Procotol
Border Gateway Protocol
Berkeley Software Distribution
Compact Disc
Command Line Interface
Central Processing Unit
Cycle Redundancy Check
Domain Name System
Encapsulating Security Payload
Forwarding Information Base
File Transfer Protocol
Internet Control Message Protocol
Intrusion Detection System
Internet Key Exchange
Internet Protocol
Industry Standard Architecture
Internet Service Provider
Internet Relay Chat
Interrupt Request
Medium Access Control
Maximum Segment Size
Maximum Transmission Unit
Out Of Band
Ping of Death
Random Access Memory
Remote Procedure Call
Reverse Path Forwarding
99
100
RST
SA
SAD
SCSI
SMTP
SNMP
SP
SPI
STL
SSH
TCP
UDP
Abbreviations
Reset
Security Association
Security Association Database
Small Computer System Interface
Simple Mail Transfer Protocol
Simple Network Management Protocol
Service Pack
Security Parameter Index
Standard Template Library
Secure Shell
Transmission Control Protocol
User Datagram Protocol
Bibliography
[1] Fred Halsall, Data Communications, Computer Networks and Open Systems (Fourth Edition) (1995).
[2] Distributed
Reflection
Denial
http://www.grc.com/dos/drdos.htm (Feb 2002).
of
Service,
[3] Why Windows XP will be the Denial of Service Exploitation Tool of Choice for Internet Hackers Everywhere,
http://www.grc.com/dos/winxp.htm (Oct 2003).
[4] Denial-of-service attack, http://en.wikipedia.org/wiki/Ddos (Jan
2005).
[5] Manpage
to
Linux
IPv4
RAW
http://www.rt.com/man/raw.4.html (Oct 1998).
sockets,
[6] Manpage to crypt, http://www.rt.com/man/crypt.3.html (Sep 1994).
[7] Trends
in
Denial
of
Service
Attack
Technology,
http://www.cert.org/archive/pdf/DoS_trends.pdf (Okt 2001).
[8] Dissecting
Steve
Gibson
http://grcsucks.com/grcdos.htm
GRC
DoS
Page,
[9] CERT
Advisory
CA-1997-28
IP
Denial-of-Service
Attacks,
http://www.cert.org/advisories/CA-1997-28.html (Mar 1998).
[10] Prevent
hacker
probing:
Block
bad
ICMP
http://techrepublic.com.com/5100-6264-5087087.html
2003).
messages,
(Okt
[11] WinNuke lives on, and it’s coming to a system near you,
http://techrepublic.com.com/5100-6313-1054537.html
(Nov
2002).
101
102
Bibliography
[12] WinNuke on Wikipedia, http://en.wikipedia.org/wiki/Winnuke
(Jan 2005).
[13] MS02-045:
Unchecked
Buffer
in
Network
Share
Provider
May
Lead
to
Denial-of-Service,
http://support.microsoft.com/default.aspx?scid=KB;EN-US;
Q326830& (Sep 2004).
[14] Microsoft
Windows
Platforms
running
TCP/IP
Subject
to
Denial
of
Service
Attack,
http://www.windowsitpro.com/Article/ArticleID/9233/9233.html
(Jun 1997).
[15] Microsoft
fixes
”Ping
of
Death
http://www.windowsitpro.com/Article/ArticleID/17129/
17129.html (Jul 1997).
2”,
[16] JTC
019
Ping
of
Death
Detection,
http://advanced.comms.agilent.com/n2x/docs/journal/
JTC_019.html (2004).
[17] THE LATEST IN DENIAL OF SERVICE ATTACKS: ”SMURFING”
DESCRIPTION AND INFORMATION TO MINIMIZE EFFECTS,
http://www.pentics.net/denial-of-service/white-papers/
smurf.cgi (Feb 2000).
[18] Defining Strategies to Protect Against UDP Diagnostic Port Denialof-Service Attacks, http://cio.cisco.com/warp/public/707/3.html
(Feb 2004).
[19] Denial of Service FAQ Basic, http://www.securitydocs.com/library/
2774 (Dec 2004).
[20] Zombie
trick
expected
to
send
spam
sky-high,
http://news.com.com/Experts+Zombie+trick+set+to+send+spam+
sky-high/2100-7349_3-5560664.html?tag=nefd.top (Feb 2004).
[21] CERT Advisory CA-1996-21 TCP SYN Flooding and IP Spoofing
Attacks, http://www.cert.org/advisories/CA-1996-21.html (Nov
2000).
[22] SYN cookies, http://cr.yp.to/syncookies.html (Nov 2000).
[23] Global Incident Analysis Center: Special Notice - Egress Filtering,
http://www.sans.org/y2k/egress.htm (Feb 2000).
[24] ICMP Traceback (iTrace), http://www.ietf.org/html.charters/
itrace-charter.html (Mar 2002).
Bibliography
103
[25] Intention-Driven iTrace, http://www.ietf.org/proceedings/01mar/
slides/itrace-1/sld001.htm (Mar 2001).
[26] Intention-Driven ICMP Trace-Back, http://whitepapers.zdnet.co.uk
/0,39025945,60028074p-39000424q,00.htm (Feb 2001).
[27] An
evaluation
of
different
IP
traceback
approaches,
http://www.sm.luth.se/csee/csn/publications/ip_traceback.pdf
(Oct 2002).
[28] On Network-Layer Packet Traceback:
Tracing Denial-ofService (DoS) and Distributed Denial-of-Service (DDoS) attacks,
http://www.lib.ncsu.edu/theses/available/etd-01062004-093357
/unrestricted/etd.pdf (2003).
[29] Address
Allocation
for
Private
http://www.ietf.org/rfc/rfc1918.txt (Feb 1996).
Internets,
[30] Network
Ingress
Filtering:
Defeating
Denial
vice Attacks which employ IP Source Address
http://www.ietf.org/rfc/rfc2827.txt (May 2000).
of
SerSpoofing,
[31] Ingress
Filtering
for
Multihomed
http://www.ietf.org/rfc/rfc3704.txt (Mar 2004).
Networks,
[32] Searchsecurity.com Egress Filtering,
http://searchsecurity.techtarget.com/tip/
1,289483,sid14_gci883409,00.html (Mar 2003).
[33] Changes to Functionality in Microsoft Windows XP Service Pack 2 Part 2:
Network Protection Technologies,
http://www.microsoft.com/downloads/info.aspx?na=46&p=3&
SrcDisplayLang=en&SrcCategoryId=&SrcFamilyId=7bd948d7b791-40b6-8364-685b84158c78&genscs=&u=http%3a%2f%2f
download.microsoft.com%2fdownload%2f8%2f7%2f9%2f879a7b46
-5ddb-4a82-b64d-64e791b3c9ae%2f02_CIF_Network_Protection.DOC
(Sep 2004).
[34] Gibson’s
ENcryption-Enhanced
Spoofing
Immunity
http://grc.com/r&d/nomoredos.htm (Oct 2003).
System,
[35] Ping of Death,
http://www.insecure.org/sploits/ping-o-death.html.
[36] Teardrop DoS,
http://attrition.org/security/denial/w/teardrop.dos.html
(Nov 1997).
104
Bibliography
[37] Network Intruder Location Using Markov Decision Processes,
http://www.ee.umd.edu/~shayman/papers.d/raid_2000.ps
(Apr
2000).
[38] Towards Tracing Hidden Attackers on Untrusted IP Networks,
http://www.cs.ucdavis.edu/~wu/publications/Decid_im2001.ps.
[39] IPsec:
How
it
works
and
why
we
need
it,
http://www.computerworld.com/securitytopics/security/story/
0,10801,91312,00.html (Mar 2004).
[40] Requirements for Internet Hosts – Communication Layers,
http://www.ietf.org/rfc/rfc1122.txt?number=1122 (Oct 1989).
[41] The DoS Project’s ”trinoo” distributed denial of service attack tool,
http://staff.washington.edu/dittrich/misc/trinoo.analysis
(Oct 1999)
[42] The ”Tribe Flood Network” distributed denial of service attack
tool, http://staff.washington.edu/dittrich/misc/tfn.analysis
(Oct 1999)
[43] The
”stacheldraht”
distributed
denial
of
service
attack
tool,
http://staff.washington.edu/dittrich/misc/
stacheldraht.analysis (Dec 1999)
[44] Multifunctioal
ICMP
Messages
for
e-Commerce,
http://www1.cs.columbia.edu/~bowang/PublishedPapers/
MultifunctionalICMPMessagesForE-Commerce.pdf (2003)
[45] A
DoS-Resistant
IP
Traceback
http://www.nyman-workshop.org/2003/papers/
A%20Denial-of-Service-Resistant%20IP%20Traceback
%20Approach_Bao-Tung%20Wang.pdf (2003)
Approach,
[46] Boost C++ Libraries, http://www.boost.org/ (Oct 2004)
[47] Intel Endianness White Paper,
ftp://download.intel.com/design/intarch/papers/endian.pdf
(Nov 2004)
[48] Internet Protocol Multicast,
http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/
ipmulti.pdf
[49] WinPcap:
the Free Packet Capture
http://www.winpcap.org/ (Jun 2005).
Library
for
Windows,
Appendix
A
EthernetII Packet
EthernetII packet:
Destination address
6 bytes
Source address Ethertype
6 bytes
2 bytes
Data
46 - 1500 bytes
CRC
4 bytes
If data is less than 46 bytes it is padded with zeros.
105
106
EthernetII Packet
Appendix
B
ARP packet
ARP packet:
Hardware type
16 bits
Hardware address length Protocol address length
8 bits
8 bits
Source hardware address
Variable length
Source protocol address
Variable length
Destination hardware address
Variable length
Destination protocol address
Variable length
107
Protocol type
16 bits
Opcode
16 bits
108
ARP packet
Appendix
C
IP datagram
IP datagram:
20-65535 bytes
Header
Data
20-60 bytes 0-65515 bytes
IP header:
VER HLEN Service type
Total length
4 bits 4 bits
8 bits
16 bits
Identification
Flags Fragmentaion offset
16 bits
3 bits
13 bits
Time to live
Protocol
Header checksum
8 bits
8 bits
16 bits
Source IP address
32 bits
Destination IP address
32 bits
Option
0-40 bytes
109
110
IP datagram
Appendix
D
ICMP packet
ICMP packet:
8-65515 bytes
Header
Data
8 bytes 0-65507 bytes
ICMP header:
Type Code
Checksum
8 bits 8 bits
16 bits
Identifier
Sequence number
16 bits
16 bits
111
112
ICMP packet
Appendix
E
UDP datagram
UDP datagram:
8-65515 bytes
Header
Data
8 bytes 0-65507 bytes
UDP header:
Source port address
16 bits
Total length
16 bits
Destination port address
16 bits
Checksum
16 bits
113
114
UDP datagram
Appendix
F
TCP segment
TCP segment:
20-65515 bytes
Header
Data
20-64
0-65495 bytes
TCP header:
Source port address
Destination port address
16 bits
16 bits
Sequence number
32 bits
Acknowledgement number
32 bits
HLEN Reserved U A P R S F
Window size
4 bits
6 bits
R C S S Y I
16 bits
G K H T N N
Checksum
Urgent pointer
16 bits
16 bits
Options & padding
0-44 bytes
115
116
TCP segment
Appendix
G
Manual for the Control Center and
Zombie application
G.1 Control Center
The Control Center is the application that is used to control the Zombies. By
using the Control Center it is possible to send commands to the connected
Zombies. For instance it is possible to start or stop an attack or gather status
for each Zombie. There are a few arguments that may be passed to the
Control Center in the startup sequence as seen in Figure G.1. The server uses
multicast to sends its IP to the Zombies by default.
ControlCenter.exe [-p port] [-n] [-h] [-r file]
-r –readfile
Specify a file to read initialization commands from.
-p –port
Specify the port number to listen on.
-n –nomulticast Don’t use multicast mode (default address).
-h –help
Show this help.
Figure G.1: Control Center startup arguments
When the Control Center starts up it will display a message if multicast
mode is used followed by the IP address and port number that will be used for
communication with the Zombies. The prompt (”¿”) will then be displayed
and the Control Center will wait for instructions from the user. The available
commands are shown below:
help: Shows a list of available commands.
117
118
Manual for the Control Center and Zombie application
attack: Used to initialize an attack. More details are available below.
attack start zombieID: Starts a previously initialized attack for Zombie
zombieID. If the zombieID argument is excluded, all initialized Zombies
will start their attack session.
attack stop zombieID: Stops a running attack for Zombie zombieID. If the
zombieID argument is excluded, all initialized Zombies will stop their
attack session.
status: Send a query to each Zombie to get their current status. The replies
are shown on the screen. This command may be used to retrive Zombie
ids.
readfile file: Read initialization commands from file (the file syntax is the
same as a normal attack initialization and several commands may be
entered in the same file with one command per line).
kill zombieID: If no argument is used all Zombies will be disconnected from
the Control Center otherwise only the specified Zombie will be disconnected.
quit: Disconnects all Zombies and exits the application.
exit: Same as quit.
help attack: Displays more comprehensive information about the attack
command.
As seen earlier it is possible to get more information about the attack initialization by issuing the ”help attack” command. The available initialization
arguments for the ”attack” command are:
type a: Set the attack to be issued. See Figure G.2 for a list of available
attack types.
mac m: Set both the source and destination MAC address to m. The format
can be either AABBCCDDEEFF or AA:BB:CC:DD:EE:FF.
srcmac m: Set the source MAC address to m.
destmac m: Set the destination MAC address to m.
ip i: Set both the source and destination IP address to i.
srcip i: Set the source IP address to i.
destip i: Set the destination IP address to i.
port p: Set both the source and destination port to p.
119
srcport p: Set source port to p.
destport p: Set destination port to p.
datasize d: Set the data size of the packets to d bytes. The maximum data
size is 1470 bytes. Note that if the data size is too small it is possible
that the packet will be padded to fit the specifications.
interval i: Set the delay between the transmission of two packets to i milliseconds. Default value is zero.
zombieid i: Initialize Zombie i with these attack parameters. If this argument is not used, all Zombies will be initialized. The ”i” value is an
integer value representing a unique Zombie. It is shown by the ”status”
command.
All arguments above are optional except ”type”. The different attacks use
different default values for each argument. For details refer to Figure G.2.
It does not matter in what order the arguments are entered. The exception
is if two or more arguments contradicts each other then the last one entered
is chosen. For instance if both ”ip 1.2.3.4” and ”destip 1.2.3.5” are entered,
1.2.3.5 will be chosen as the destination IP address since it was entered last.
An example of how to initialize Zombie 0 to attack the host of 130.235.5.
174 with an ICMP ping attack (using a spoofed source IP address of 127.0.0.1,
spoofed source MAC address of 11:22:33:44:55:66, a data size of 1200 bytes,
and an interval of 40 milliseconds between each ICMP packet) is seen below:
attack type icmpping zombieid 0 srcip 127.0.0.1
destip 130.235.5.174 srcmac 11:22:33:44:55:66
datasize 1200 interval 40
To start the attack at Zombie 0 type:
attack start 0
G.2 Zombie
The Zombie is controlled by a Control Center and once started it is not
possible to alter its behavior. There are a couple of arguments that can be
passed to the Zombie in the startup sequence as seen in Figure G.3. The
server address is fetched by using multicast lookup if no IP is specified.
When the Zombie is started (with no arguments) it first displays what
date and time the main Zombie file (zombie.cpp) was compiled on. It then
displays some local network information such as network device (rpcap), IP,
120
Attack
type
fraggle
icmpping
land
pepsi
pod2
srcmac
0x0
0x0
0x0
0x0
0x0
destmac
0xffffffffffff
0xffffffffffff
0xffffffffffff
0xffffffffffff
0xffffffffffff
Default values
srcip
destip
srcport
0.0.0.0
0.0.0.0
random
0.0.0.0
0.0.0.0
−
0.0.0.0
0.0.0.0
0
0.0.0.0
0.0.0.0
random
0.0.0.0
0.0.0.0
−
smurf
tcpsyn
teardrop
0x0
0x0
0x0
0xffffffffffff
0xffffffffffff
0xffffffffffff
0.0.0.0
0.0.0.0
0.0.0.0
0.0.0.0
0.0.0.0
0.0.0.0
udpflood
winnuke
0x0
0x0
0xffffffffffff
0xffffffffffff
0.0.0.0
0.0.0.0
0.0.0.0
0.0.0.0
−
random
random
random
random
random
destport
7
−
0
161
−
−
0
0
0
0
139
datasize
64
64
0
44
1472
1480
403
64
64
0xAC
0xA9
64
1460
Figure G.2: Default attack parameter values. The values that are not interchangeable are underlined. The ”−” indicates that the attack
is discarding that particular option.
Zombie.exe [-i ip] [-p port] [-n] [-h] [-d]
-i –ip –hostip
IP to server (no multicast).
-p –port
Port to server.
-n –notestenvironment Enable use of gateway to access foreign networks.
-d –device
Choose a non default network
device to attack from.
-h –help
Show this help.
Figure G.3: Zombie startup arguments
121
and MAC address. The Zombie then connects to the multicast address of
224.0.0.1 and fetches the IP address and port to the Control Center. It then
disconnects from the multicast address and connects to the Control Center
with the fetched IP address and port and then wait for instructions. Figure G.4 shows an example of a Zombie that has been initialized with an
ICMP ping attack.
Figure G.4: Zombie initialized with an ICMP ping attack
When choosing to use a non default network device (-d switch) a list of
possible network devices will be displayed on the screen. Here the user must
choose which network device to use by entering an integer number.
122
Appendix
H
Class Diagrams
This chapter displays the class diagrams for the Control Center and Zombie
applications.
H.1 Control Center Class Diagram
123
H.2 Zombie Class Diagram
124
Class Diagrams

Background Reading - Electrical and Information Technology

Transcription

Similar documents

Lecture 1 Introduction

$34 99 - Six Flags

Next Generation Wifi VoIP Phones: How to reduce the packet rate of

Slaves, cannibals, and infected Hyper-Whites: the

Computer Communication Review

borsa i̇stanbul itch protocol specification rules of

The Living Dead 2

Improving network mobility in HAP networks

hakin9

Fatality Report - 2003 - Pennsylvania Coalition Against Domestic

TIIM: Technology-Independent Interference Mitigation for Low

MobileMAN Presentation

lone tree city council

Minutes Packet - St. Croix County Board

American Zombie Gothic

Here - Every Mind Matters

Table of Contents - HP Enterprise Group

fiction/non-fiction - BMI Educational Services

Network Primer and Programming Tutorial for the Model 2701 Ethernet

NETWORK MANAGEMENT APPROACH FOR THE TSAT NETWORK

Four Steps to Application Performance Across the Network

IEEE Communications Society