Background Reading - Electrical and Information Technology

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

System resource consuming Denial of Service Attacks

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

System resource consuming Denial of Service Attacks

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

System resource consuming Denial of Service Attacks

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

System resource consuming Denial of Service Attacks

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

Bandwidth consuming denial of Service Attacks

Figure 4.1: DDoS attack using zombies

Bandwidth consuming denial of Service Attacks

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

Bandwidth consuming denial of Service Attacks

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].

Bandwidth consuming denial of Service Attacks

Figure 4.3: Smurf attack

21

22

Bandwidth consuming denial of Service Attacks

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

Defending against Denial of Service Attacks

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].

Defending against Denial of Service Attacks

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

Defending against Denial of Service Attacks

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.

Defending against Denial of Service Attacks

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

Defending against Denial of Service Attacks

Chapter

6

Tracing Denial of Service Attacks

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

Tracing Denial of Service Attacks

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

Tracing Denial of Service Attacks

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

Tracing Denial of Service Attacks

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.

Tracing Denial of Service Attacks

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

Tracing Denial of Service Attacks

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.

Tracing Denial of Service Attacks

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

Tracing Denial of Service Attacks

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

Tracing Denial of Service Attacks

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

Tracing Denial of Service Attacks

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

Tracing Denial of Service Attacks

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

Tracing Denial of Service Attacks

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

Denial of Service applications

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

Denial of Service applications

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

Denial of Service applications

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

Denial of Service applications

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

Denial of Service applications

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

Denial of Service applications

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

Our Denial of Service application

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.

Our Denial of Service application

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

Our Denial of Service application

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.

Our Denial of Service application

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

Our Denial of Service application

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 srcip srcmac 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 srcip datasize

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 interval 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 srcip 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 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 srcip destip 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 time=1ms TTL=128

bytes=32 time=1ms TTL=128 bytes=32 time=1ms TTL=128 bytes=32 time=1ms TTL=128 bytes=32 time=1ms TTL=128 bytes=32 time=1ms TTL=128 bytes=32 time=1ms TTL=128 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 destip datasize attack type icmpping zombieid destip datasize

srcip 1408 srcip 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 64 bytes from cyan.net (192.168.15.43): icmp_seq=0 ttl=128 64 bytes from cyan.net (192.168.15.43): icmp_seq=0 ttl=128 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 0 knoppix.it.lth.se:ssh fox-15.it.lth.se:32022 tcp 0 0 knoppix.it.lth.se:ssh fox-15.it.lth.se:31941 tcp 0 0 knoppix.it.lth.se:ssh fox-15.it.lth.se:31910 tcp 0 0 knoppix.it.lth.se:ssh fox-15.it.lth.se:32288 tcp 0 0 knoppix.it.lth.se:ssh fox-15.it.lth.se:32261 tcp 0 0 knoppix.it.lth.se:ssh fox-15.it.lth.se:32084

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 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+) truncated-ip - 8 bytes missing!mog.homenet > umaro.homenet: (frag 21887:1488@1480+) truncated-ip - 8 bytes missing!mog.homenet > umaro.homenet: (frag 21887:1488@1480+) 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

Test scenario

95

srcip 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.

Manual for the Control Center and Zombie application

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

Manual for the Control Center and Zombie application

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

Manual for the Control Center and Zombie application

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

Manual for the Control Center and Zombie application

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