Download Denial of Service Attacks

Denial of Service Attacks
Lesson 12
Email Flooding/bombing
 A form of denial of service attack.
 From the CERT web page:
Email "bombing" is characterized by abusers repeatedly sending an identical email
message to a particular address.
Email "spamming" is a variant of bombing; it refers to sending email to hundreds
or thousands of users (or to lists that expand to that many users). Email
spamming can be made worse if recipients reply to the email, causing all the
original addressees to receive the reply. It may also occur innocently, as a result
of sending a message to mailing lists and not realizing that the list explodes to
thousands of users, or as a result of an incorrectly set-up responder message
(such as vacation(1)).
Email bombing/spamming may be combined with email "spoofing" (which alters
the identity of the account sending the email), making it more difficult to determine
who the email is actually coming from.
Email Flooding
Attacker sends 100’s or
1000’s of emails to target
Attacker
Attacker
Target user’s box fills or
target system can go
down.
Effectiveness as means to attack a system depends on the
relative size of the systems and the “pipes”.
Email Flooding
Systems return email to system that
appears to have sent emails.
Target system goes
down under load of
too many emails.
Attacker sends spoofed email
with error to 100’s of systems
Attacker
Attacker
Email Bombing example
Email Flooding
What can you do?

From the CERT web page:
A.Detection
– If your system suddenly appears sluggish (email is slow or doesn't appear to be sent or
received), the reason may be that your mailer is trying to process a large number of
messages.
B.Reaction
– Identify the source of the email bomb/spam and configure your router (or have your
Network Service Provider configure the router) to prevent incoming packets from that
address. Review email headers to determine the true origin of the email. Review the
information related to the email bomb/spam following relevant policies and procedures
of your organization.
– Follow up with the site(s) you identified in your review to alert them to the activity.
Contact them to alert them to the activity. NOTE: When contacting these sites, keep in
mind that the abuser may be trying to hide their identity.
– Ensure you are up to date with the most current version of email delivery daemon
(sendmail, for example) and increase logging capabilities as necessary to detect or
alert you to such activity.
Denial of Service Attacks
Denial of Service Attacks
Denial of Service (DoS)


Attacks that deny legitimate users service and access to information
resources.
Different ways to categorize them
Bandwidth Consumption
– attackers will consume all available bandwidth to a particular network
Resource Starvation
– focuses on consuming system resources rather than network resources (e.g. CPU
utilization, memory, file-system quotas)
Programming Flaws
– failures of an application, or operating system to handle exceptional conditions (normally
result when a user sends unintended data to the vulnerable element)
Routing and DNS attacks
– involves attackers manipulating routing table entries to deny service to legitimate
systems or networks.
Denial of Service (DoS)

Different ways to categorize them
Nature of attack
– Poisoned traffic
 malformed or invalid data that can’t be properly handled
– Brute-force resource
 simply use up all available capacity
– Stateful resource
 take advantage of client/server relationship in protocols
“target” of attack
– Operating system attacks
 target flaws in specific operating systems
– Networking attacks
 exploit inherent limitations of networking
Sources of the Attack
 Can come from many (any) places in the network
 An attacker can hide the source of an attack
through IP spoofing
 Attackers can also hide their identity by enslaving
unwitting victims.
“owned” or “zombie” agents
 When an attacker uses many zombie agents
together simultaneously the result is a Distributed
Denial of Service (DDoS) attack
IIS Attack
 Internet Information Services:
a MS web server
 Operating System/Poisoned Traffic attack
 Worked against NT 4.0 running Microsoft’s Internet
Information Server version 3.0
 All that was required was for the user to request a
document with a very long name from the server to
halt it.
e.g. http://victim.com/?something=xxxxxx…
 A patch for this bug was issued by MS
Ping of Death (POD)

Normal Ping utility used to determine whether another
machine on the network is up.
Accomplished by sending an Internet Control Message
Protocol (ICMP) “echo” or “ping” packet to the target.
The target replies if it is operating

POD accomplished by sending packet > 64K
Buffer overflow ensues causing reboot or crash

Patches issued to address this attack
ICMP Packet
 Considered part of IP layer
 Communicates error messages and other conditions
that require attention.
 ICMP messages are usually acted on by either the IP
layer or the higher layer protocol.
 ICMP messages are transmitted within IP datagrams
as shown:
IP Header
20 bytes
ICMP Message
ICMP packet
8-bit type
8-bit code
16-bit checksum
(contents depends on type and code)
ICMP Messages
Type
0
3
4
5
8
13
code
0
0
1
2
3
0
0
1
0
0
Description
echo reply
destination unreachable
network unreachable
host unreachable
protocol unreachable
port unreachable
source quench (flow control)
redirect
redirect for network
redirect for host
echo request
timestamp request
Query Error
x
x
x
x
x
x
x
x
x
x
Smurf/ping flooding/ICMP storm


Another attack that exploits the ping utility
Attacker sends a large stream of spoofed ping packets to a
broadcast address (an IP address that services a network of
computers)
All of the packets have as their source address the target’s IP address.





Broadcast is “heard” (relayed) by all hosts on network.
Hosts reply to the victim
Amount of data sent to victim is multiplied by a factor of the
number of hosts in network
If multiple requests sent to broadcast host, target will be
overloaded with replies
A Network/Brute-force attack
ICMP Flooding
Multiple Ping replies
Multiple Ping requests
System or network
becomes overloaded
Broadcast request
Attacker
Ping
Broadcast request
DNS Cache poisoning
Microsoft’s
DNS server
1. Client PC requests to go
to Microsoft web site,
browser tries to resolve the
name
2. DNS server’s cache
has been poisoned by
attacker, returns
address of attacker’s
web server
But what if we send
folks for a high
volume site to a
target system
instead?
Internet
Client’s PC
Web Server
www.microsoft.com
3. Attacker’s system
now fraudulently poses
as www.microsoft.com
Attacker’s web
server
From: Hacking Exposed 2ed
SYN flooding




Exploits the synchronization protocol used to initiate connections
Normal process is:
Initiator sends synchronization (SYN) packet
Target replies with a SYN/ACK (acknowledgement)
Initiator sends ACK, two machines are now ready
In SYN flooding, attacker sends SYN packets with phony source
address
target replies with SYN/ACK but it goes nowhere
target waits for ACK, eventually gives up but…
– if enough SYN’s received, space will fill up
Network/Stateful Resource attack
SYN Flooding
SYN Attacks
 Syn_Flooder an example of SYN Flooding attack
 Land is a specialized version of SYN attack
From CERT Advisory CA-97.28 - Teardrop_Land
– Some implementations of TCP/IP are vulnerable to packets that are crafted
in a particular way (a SYN packet in which the source address and port are
the same as the destination--i.e., spoofed). Land is a widely available attack
tool that exploits this vulnerability. Any remote user that can send spoofed
packets to a host can crash or "hang" that host.
Operating System/Poisoned traffic attack
A patch to fix this problem is available from vendors
Resource Starvation attack
 One method utilizes two UDP services
Echo: the server returns whatever the client sends
Chargen: The server sends a datagram containing a
random number of characters each time the client
sends a datagram.
 Now, an intruder will spoof a packet and
connects the Echo service on one machine to
the chargen service on another.
Other DoS Attacks - Teardrop

Teardrop
From CERT Advisory CA-97.28 - Teardrop_Land
– Some implementations of the TCP/IP IP fragmentation re-assembly
code do not properly handle overlapping IP fragments. Teardrop is a
widely available attack tool that exploits this vulnerability. Any remote
user can crash a vulnerable machine.
– Operating System/Poisoned traffic
– Patch to prevent is available from vendors
Normal reassembled IP Packets
Bytes 1-1500
Bytes 1501-3000
Abnormally reassembled IP Packets
Bytes 1-1500
Bytes 1200-3200
Bytes 3001-4500
Bytes 3001-4500
Other DoS Attacks - Bonk
 A variant of Teardrop aimed at W95 and NT
From www.attrition.org/security/denial/w/bonk.dos.html
– Based On: teardrop.c by route|daemon9 & klepto
Crashes *patched* win95/(NT?) machines. Basically, we set
the frag offset > header length (teardrop reversed). There are
many theories as to why this works, however i do not have
the resources to perform extensive testing.
– Operating System/Poisoned traffic
– Patch to prevent is available from vendors
 For fun, check out
http://www.attrition.org/security/denial/
Other DoS Attacks - WinNuke
Affects Windows 95/3.1/NT
 Causes “Blue Screen of Death”

Computer recovers but Internet connection hosed, requires
reboot

uses Out of Band (OOB) data sent to an established
connection.
Windows doesn’t handle OOB well and goes into a panic.

Operating System/Poisoned traffic attack
DDoS Attack
tribal flood network (TFN) DDoS
TFN is made up of client and daemon programs, which
implement a distributed network denial of service tool capable of
waging ICMP flood, SYN flood, UDP flood, and Smurf style
attacks.
 Remote control of a TFN is accomplished via command line
execution of the client program, using any of a number of
connection methods (e.g., remote shell bound to a TCP port,
UDP based client/server remote shells, ICMP based client/server
shells, or normal "telnet" TCP terminal sessions.
 Communication from the TFN client to daemons is accomplished
via ICMP_ECHOREPLY (why?) packets. There is no TCP or
UDP based communication between the client and daemons at
all.

trinoo DDoS
A trinoo network of at least 227 systems was used on Aug 17, 1999 to
flood a single system at the University of Minnesota.
 The attacker(s) control one or more “master”servers, each of which can
control many daemons.
 Remote control of the master is accomplished via a TCP connection to
port 27665, after which the user must authenticate with a password.
 Communication between the master to daemons is via UDP packects
on port 27444.
 When the daemon starts, it initially sends a “hello” message to the
master which maintains a list of active daemons it controls.
 The daemons send UDP packets to random (0-64K) UDP ports on the
target for a period of time (120 seconds default)

Stacheldraht (barbed wire) DDoS
Combines features of the trinoo and the original TFN
and adds encryption of communication between
attacker and masters and automated updating of
agents.
 Can do ICMP flood, SYN flood, UDP flood, and smurf
style attacks.
 There is a limit of 1000 agents for each master
 Used TCP and ICMP for communication between
master and agents (trinoo used UDP, TFN used ICMP)

Code Red

Three phases
Propagation phase: day 1-19 of the month
– Scan systems on TCP port 80 and send special HTTP GET request that
exploited an overflow in IIS. If successful, worm ran in RAM and spawned 99
threads to attack a relatively random set of IP addresses. If web site was in
English, then also left defaced message up for 10 hours.
Flood phase: days 20-28 of the month. Between 8:00 and 11:59
pm send 100KB packets to IP address for what was
www.whitehouse.gov.
Termination Phase: days 28-31 of the month. The worm became
dormant.
To remove, reboot system (to eliminate from RAM) and
install patch from Microsoft to prevent reinfection.
 Not all systems on network are computers, if Code Red sent
packet to HP JetDirect devices or Cisco 600 DSL router they
would crash.

Blaster
 Targeted Windows 2000 and Windows XP
 Downloads and runs “msblast.exe”
 Attempted to infect other machines
40% of time generated IP address A.B.C.* where A.B.C.
was the same as the infected machine
60% of time generated completely random address
 If month was Sept-Dec, or date was 16- 31 of Jan-
Aug, attempted to perform DoS attack on Windows
Update site to keep folks from being able to
download fix.
Protection from DoS and DDoS

Best way would seem to be to stop the attack before it
happens
Detect and Remove Trojans/zombies from servers, use file-integrity
checking programs

Block “marching orders”
e.g. one method to send the “attack” order is to send an unsolicited
ICMP ping response -- firewalls should be set to block this.
Broadcasts should not send ping requests. Limit ability to spoof.

Block the attack at the source
Block DoS attacks at source
Mitigating the Effects of DoS
 Acknowledges that we can’t stop DoS
 Harden the network
 Avoid putting “all of your eggs in one basket”
 Use Load balancers
can employ “delayed binds” which drop sessions
can also drop “Silent” TCP sessions
 Adjust state limits (e.g. wait time)
Methods to keep from becoming a zombie
Keep abreast of vulnerabilities for your HW & SW
 Use a firewall
 Monitor system & test for vulnerabilities (to ensure they are
patched), check what TCP/UDP ports are open.
 Monitor logs and check for suspicious activity
 Audit system files to make sure no changes have been made
 Don’t run SW if you can’t trust it/don’t know where it came from
 Follow recommendations and guidelines from CERT, SANS…

IOW, do those things you should be doing to avoid intrusions, because
that’s how you become a zombie.
Summary
 What is the Importance and Significance of this
material?
 How does this topic fit into the subject of “Voice
and Data Security”?