IN THIS CHAPTER

Disrupting normal operations

Sending a flood attack to a host

Digging into the details of DoS and DDoS

Exploring specific DoS attacks

The series of attacks I cover in this chapter revolves around overwhelming targets. In previous chapters, you learn how to use specific tools to knock on the front door (or try the back door) and see if you could gain access. In this chapter, I show you how to kick in the front door.

In these scenarios, the attacker is focused on literally overwhelming the target to cause it to either crash, not accept real connections for service, clog up the pipes, incapacitate the system by using up all its resources, and just plain disrupt everything to cause a denial of service. I talk specifically about Denial of Service (DoS) attacks, which are unfortunately common.

I also show you how attackers (and pen testers) handle the disruption of resources through attacks such as a DoS, DDoS (distributed form of a DoS), buffer overflow attacks, and more. I discuss what tools you use to identify both whether you’re experiencing a DoS attack and whether your systems are vulnerable to experiencing them. This is another fundamental of vulnerability testing and when you scan for weakness how to view them as a risk to remediate.

You can potentially crash the systems you’re testing and potentially corrupt them. Make sure that you run these tests on a test environment that duplicates the actual production environment to see not only the anticipated outcomes, but also what can’t be anticipated. For example, you might send traffic to a server resource to test it only to cause it to freeze, blue screen, crash, or lock up. You might be forced to hard boot the system (or it will do it on its own), which can cause you to lose data, corrupt system files, or render the system in need of an image repair. Run these tests with great caution.

In this chapter, I show you the biggest vectors are outside and inside your network. External attacks are more prevalent in this arena, but many viruses (malware) can be circulated within your network to accomplish the same attack. The threat can be worse when you have malware in your organization that turns your own workstations into zombies (computers taken over by hackers) and therefore into the source of an attack.

As a pen tester, you won’t launch DDoS attacks against networks. However, black hats use this technique as a way to find a vulnerability to exploit. Be cautious if you want to use this tactic because it can cause severe outages on your production network.

Toolkit Fundamentals

For overwhelm and disrupt attacks, tools such as Nmap, Kali, and even network console tools from your workstation can be used to launch an attack. You want to run all these as part of your vulnerability scanning so that you can assess whether you have weaknesses in these areas.

Make no mistake, just about every company connected to the public Internet is exposed to overwhelm and disrupt attacks.

First you use many of the tools in your toolkit, including some from Kali, Nessus, Wireshark (all of which I introduce in Chapter 3), and others to identify these attacks. What makes this particular attack extra vicious, however, is that it can be hard to identify without looking at your firewalls and routers in the network to see inbound and outbound traffic patterns.

Kali

Kali (see Chapter 3 for an overview) is useful to overwhelm and disrupt normal traffic patterns, overwhelm healthy resources, and send traffic to resources in a way that disrupts normal operation. Open Kali and navigate to the Stress Testing tools and select the Network Stress Testing menu. Over a dozen tools can help you find these vulnerabilities.

You can use a Kali tool called Inundator to run stress tests in your environment to see how your systems respond. In Figure 6-1, Inundator is sending massive amounts of traffic to hosts. The Inundator tool is a multi-threaded, queue-driven, anonymous, intrusion detection tool that generates false positives with support for multiple targets. It sends traffic to cause alerts to appear and inundate (overwhelm and disrupt normal operations) your security infrastructure, such as firewalls, routers, intrusion detection tools, and prevention gear. The inundation fills your logs and over-utilizes your resources.

If you’re running websites from your company and you host them in your environment behind your firewall, your firewall might be intelligent enough to identify when this type of attack is taking place and either alert you or block it. Regardless, the example shows how the larger landscape is exposed.

If a hacker uses a tool such as Inundator to overwhelm your firewalls and other devices you rely on to detect attacks as they occur, you can see the pattern of a larger scale attack. A larger scale attack should be very concerning. Part of mitigating the issue is to patch your systems accordingly, remove unneeded services or open ports, and/or block these types of attacks from being able to reach your intended hosts.

Figure 6-2 shows how a hacker (or you as an ethical hacker) can launch an attack from outside of the network. In this example, I am showing a very simple design where the attacker probes your visible address space (maybe the hosted server resources via your firewall) of any and all associated devices available to scan.

Running tools such as Nessus can do this very easily. Once I have something to work with (an address or hostname), I can then begin to send traffic to it in hopes of overwhelming it. Note that the attack can originate either from a spoofed address or from a zombie installed by malware. In any case, the attacker sends traffic to whatever external identity they can find for your network.

They can attack in so many ways. For example, part of information-gathering attacks is to map the network. In Chapter 3, I introduce Nmap and the importance of seeing how easily it is to map your internal and external networks. If you host services from your company, your public IP address space is known — which means you must protect it and monitor it for attacks.

This exact example is also how pen testers would test their internal and external network and system resources. To do the internal vulnerability assessment, simply perform the same attacks from inside (instead of outside) your network.

Inside threats are more worrisome than outside threats. Usually, inside threats come from within your organization when trusted users, resources, and access are not fully protected. Watch this attack vector very closely.

Kali T50 Mixed Packet Injector tool

The Kali T50 Mixed Packet Injector tool is another weapon in your arsenal against overwhelm and disrupt attacks. Figure 6-3 shows the T50 tool being used by the hacker to send a flood attack to a host.

I am showing you how to overwhelm your systems with tools, but you must then examine those systems to identify whether they are in fact being overwhelmed. In Figure 6-4, I show you how to do just that.

When you run T50 to stress your host or hosts, you can then go to the host individually and look at the system resources:

• Windows users can look at the Windows Task Manager tool to view CPU and other system processes and start/stop them as needed.
• The Linux console provides the same information with the use of ps tools and the top command.

Here, I ran the T50 tool (you can see it running as the top-most intensive process using 94% of the CPU). Once I terminated the pen test, the CPU dropped to a normal percentage.

Understanding Denial of Service (DoS) Attacks

Denial of Service (DoS) attacks are quite simply the launch of any attack that stops legitimate services from being provided. This can be anything from the websites you host, the printers in a print room, or a wireless access point (WAP). The larger scale version of this type of attack is the DDoS, or distributed denial of service. While a DoS attack typically uses just one computer and one Internet connection to flood a targeted system or resource, the DDoS uses multiple computers and Internet connections to flood the target.

DoS is the best way to ruin not only a company's reputation, but it can also be very costly. If a good DoS attack is launched systematically against a high-level resource target (for example, a key backbone Internet router), the payload of that attack could take down half the Internet until it’s resolved.

Figure 6-5 shows the attack vector and how it’s conducted. In this classic case of a DDoS attack, the hacker has successfully turned zombies (workstations they’ve taken control of) into attack machines. This is usually done by distributing a virus (normally a downloadable Trojan horse) that turns systems unknowingly into traffic generators. The hacker can then backdoor (usually via rootkit) control these systems so that they can then launch attacks (much like flood) at anything the hacker desires.

When overwhelming hosts, the most common outcome from this type of attack is denial of legitimate use of the system by others. I have said for many years that information technology resources are available to be used. If you can’t use them, you shouldn’t have them. That said, DoS attacks are the most common because they’re easiest to conduct (especially by script kiddies).

They’re also the hardest to track if the overwhelming of resources is done with infected zombies. Even the best forensic teams who do incident response on these types of attacks are commonly left scratching their heads as to what could have caused them.

Regardless, you have ways to identify when this attack is taking place, which depends on which components you’re viewing:

• If you run antivirus software packages in your enterprise, you can scan, identify, and find these types of malware tools on your hosts and have them removed.
• You can also see on your outbound firewalls and routers flood-type traffic that should cause your device to raise an alert that a large amount of traffic is going through it or unusual traffic patterns are taking place.
• Similarly, you can look at the exact same thing on your firewalls and routers or at the processing on the victim machines being flooded with traffic for very high utilization.

Buffer Overflow Attacks

The buffer overflow attack is a very common exhaustion of memory on any device in your enterprise that has a buffer (which is pretty much all of them). A buffer is an available memory space on a device that allows for incoming traffic to queue so that the system architecture can take it and process it accordingly. This is a very common design that allows your systems (and the hardware everything runs on) to operate correctly.

Figure 6-6 shows the most common use of a buffer overflow attack to overwhelm a network router (externally facing) to overfill the memory so it can’t take in any legitimate requests. Legitimate requests would be other incoming connections looking to use resources such as a web page you may host from a server behind a network firewall.

In this attack, I am showing you the most vulnerable aspect of the device to interrupt use based on needed functionality for it to operate correctly. A router must be able to take data and process it to make decisions on where to router traffic. In Figure 6-6, the buffer may be normally at 60% and that’s a very busy router. If I as an ethical hacker flood it with traffic to overwhelm it (bring it to 100% utilization), I can then watch as legitimate requests drop which is the normal and intended functionality of the routing device.

Although this is hard to identify unless you have a device such as a firewall before your outside router (usually an ISP router that is monitored for this type of attack), you won’t know unless you identify disruption of service and trace it back to the router that’s being attacked. You could look at the router itself and see packets dropping from being queued.

For example, if this is a Cisco router, you can use the show buffers command to view the output in the queues to see whether packets are flooding in or whether they’re being dropped:

test-router#show buffers

Buffer elements:
500 in free list (500 max allowed)
2370 hits, 72 misses, 0 created

Public buffer pools:
Small buffers, 104 bytes (total 16, permanent 10):
11 in free list (0 min, 10 max allowed)
1770 hits, 33 misses, 22 trims, 28 created
9 failures (0 no memory)
Middle buffers, 600 bytes (total 90, permanent 90):
89 in free list (10 min, 200 max allowed)
590 hits, 0 misses, 0 trims, 0 created
0 failures (0 no memory)
Big buffers, 1524 bytes (total 90, permanent 90):
90 in free list (5 min, 300 max allowed)
126 hits, 0 misses, 0 trims, 0 created
0 failures (0 no memory)
Very Big buffers, 4520 bytes (total 10, permanent 10):
10 in free list (0 min, 300 max allowed)
50 hits, 0 misses, 0 trims, 0 created
0 failures (0 no memory)
Large buffers, 5024 bytes (total 10, permanent 10):
10 in free list (0 min, 30 max allowed)
0 hits, 0 misses, 0 trims, 0 created
0 failures (0 no memory)
Huge buffers, 18024 bytes (total 2, permanent 0):
0 in free list (0 min, 13 max allowed)
2 hits, 2 misses, 0 trims, 2 created
0 failures (0 no memory)

Although devices on the market allow for the monitoring of these types of issues and reporting on them from the network hardware vendors, this book only touches on the topic to alert you that, as a pen tester, your toolkit will start to evolve as you look at each and every attack, every vector, and every situation. Here without looking at the device logs and or internals, you may miss what it being attacked and how to prevent it. Similarly, you will want to conduct the same exact ethical attack to ensure that you’re not subject to being manipulated by it or at risk.

One of the hardest things to understand about how DoS attacks occur is that sometimes the attack cannot be prevented due to how the underlying technology is designed to be used. Back in the original deployment of the TCP/IP suite, for example, the protocols used were designed to be helpful to facilitate interconnectivity, communication, and sharing of resources. As a pen tester your initial response to finding these issues would be to turn off the service or remove the risk. There will be times that you must assume the risk and monitor it because there might not be a way to prevent it at the time.

Fragmentation Attacks

A fragmentation attack (also known as an IP fragmentation attack or frag attack) is where IP fragmentation of packets cause a DoS attack. By exploiting the natural design of TCP/IP, a hacker or ethical hacker can send pieces of data to a destination from a source device in hopes that it either causes the DoS, or as a pen tester, shows you that you have a vulnerability to assess.

Frag attacks use the actual protocols as manipulation points instead of the hardware resource available like the buffer.

You can use tools such as Kali’s fragroute and fragmentation6 to conduct tests to identify whether you’re vulnerable to these types of attacks, as shown in Figure 6-7.

By using fragtest (as shown in Figure 6-8), the Kali toolset allows you to send the malformed packets to hosts to see how they respond. You might need to assess the hosts themselves while conducting these specific tests to identify whether the systems crash, become overwhelmed, or are disrupted.

Smurf Attacks

When running tests for a smurf attack vulnerability assessment don’t believe for a minute little blue people will show up and wreak havoc on your systems. Havoc will be created by the actual DDoS attack where ping sweeping is done from spoofed IP addresses to a legitimate host resource in hopes to deny it from functioning correctly. This has nothing to do with the fictional characters and everything to do with real characters trying to create a denial of service attack.

Similar to when a large amount of data causes the DoS that ultimately causes the disruption, with a smurf attack, the actual data used to create the overwhelming amount of interrupts of legitimate service comes in the way of the Internet Control Message Protocol (ICMP). This protocol is commonly used in tools such as ping and traceroute (or tracert for Windows). Smurf attacks can be conducted from any device that sends ping sweeps, which is nearly every tool covered in this book (Nessus, Metasploit, Nmap, Kali’s tools) but also from any console where ping can be manipulated.

Figure 6-9 shows Linux’s ping tool that can be configured to change the time to live (TTL), the size of the ping packet, the volume of packets, and so on that allows for the packets that are changed to create disruption to the network interfaces that will receive it.

Smurf attacks (and tiny packet and Xmas tree attacks, too) take the technology as it was intended to be used and manipulates it in a way that creates a DoS attack.

Tiny Packet Attacks

Another easily manipulated technology that can be used for harm is the tiny packet attack. Tiny packets are packets that, similar to IP fragmentation attacks, can be further shrunk down to overwhelm the computer buffers receiving them. This DoS attack is part buffer overflow, part fragmentation attack.

This type of attack changes the data packet size, which is normally sized very specifically (as per the standard maximum transmission unit [MTU] size) that routers and other devices expect to see in their buffers. For example, the mid-range (or normal) size of an Ethernet packet is 1,500 bytes. If a hacker starts to send packets that are smaller than 1,500 bytes, the system will have a hard time receiving and processing them, which creates more overhead on the device to process incoming data. In other words, it has to work twice as hard to process that data.

Wireshark is the tool you want to use to identify tiny packets in use on your network. Figure 6-10 shows the Wireshark Packet Lengths menu that shows packets that step outside the 1,500 size norm and the volume in which they appear.

Xmas Tree Attacks

The Xmas tree attack is nothing more than an attack using a Xmas tree packet, a packet that is lit up with all options turned on — much like a real Christmas tree set up with lights, ornaments, and tinsel is lit up.

The main reason for this is because the Xmas tree attack is normally used in a stealth mission or reconnaissance for information gathering. It can also be used as a DoS attack: A large number of these packets sent to devices simultaneously can be overwhelming because Xmas tree packets with all options are more process intensive. A large number of them can be twice as intensive and therefore disrupt and overwhelm devices that are performing regular operations.