Non-cryptographic

Protocol Vulnerabilities

Once we know our weaknesses, they cease
to do us any harm
- Georg Christoph Lichtenberg
* Protocol Vulnerabilities
In protocols across all layers
Ethernet, 802.11, ARP
IP, ICMP
TCP, UDP
DNS, etc.

The vulnerability may be in the protocol itself
or it may be in the implementation of the
protocol
* Types of DoS
Syn Floods

UDP-based

Smurf Attack
* SYN Flood
An attacker sends thousands of TCP packets to the
victim with the SYN flag set.

The victim thinks that these are legitimate requests
for TCP connection establishment (the first message
of the 3-way handshake).

In response to each request, the victim reserves
buffer space. Eventually, the victims communication
link and/or memory are exhausted.
* TCP 3-way Handshake

* SYN Flood on Victim

* UDP-related attack

An attacker sends a large number of UDP
packets to non-listening ports on the victim.
This causes the victim to respond with an
ICMP Host Unreachable message for each
packet that it receives.
* Smurf Attack

An attacker sends a very large number of ICMP Echo
Request messages to the victims network.

The destination IP address of these packets is the special
broadcast address of the network while the source IP
address is the address of the victim.

This causes the victim to be inundated with Echo Reply
messages from each host on its network.
* DDoS

* DoS/DDoS
SYN Flooding is an example of DoS caused by
vulnerability in TCP (possible abuse of the 3-way
handshake)

Attacker floods victim with SYN requests
Source IP address typically spoofed
Multiple attack sources
Victim reserves buffer for the connection request
Memory and bandwidth exhaustion, also computational
resources consumed
* OS-specific parameters, etc.
L communication bandwidth of the victims
link
b maximum number of buffers reserved for
TCP connections
T maximum amount of time that a buffer
can be reserved for a half-open TCP
connection
* Attack Packet-related parameters

r aggregate rate at which the victim
receives SYN attack packets from the attack
sources

p SYN attack packet size in bits
* Conditions for:

Link Saturation
r * p l


Memory Exhaustion
r * T b
* Advances/Challenges in handling
DoS/DDoS
Prevention
(Can DDoS, in all its manifestations, always be
prevented? )
Detection
(how? )
Response to attack
(how effective are these? )
Traceback
(Packet Marking, Packet Logging, Hybrid)

Details in Chapter 22 of text

* ARP spoofing
Exploits certain features in the ARP (Address
Resolution Protocol)

ARP cache poisoning

May result in MiM attacks, session hijacking,
etc.
* ARP in a slide
Used to resolve an IP address to a MAC address.

If station A needs to send a packet to B, it is not
sufficient that A knows the IP address of B.
A should also know Bs MAC address.

For this purpose, A broadcasts an ARP query
containing Bs IP address. A station that has or knows
Bs MAC address responds directly to A.
* ARP in a slide or two
IP address-MAC address translations are cached by
each station in its ARP cache.

ARP cache entries have a lifetime, so stations
periodically send out ARP requests to update their
cache entries.

Any node X may send an unsolicited reply to a node,
A, regarding the MAC address of an arbitrary node, B.
This feature of ARP, referred to as gratuitous ARP, is
a serious vulnerability.
* Exploiting Gratuitous ARP
Consider an attacker, X, with IP address X, and MAC address, x.

X sends an unsolicited ARP response message to A stating that
Bs MAC address is x.

X also sends an unsolicited ARP response message to B stating
that As MAC address is x.

The unsolicited responses of X have created fake entries in
the ARP caches of A and B.

We say that their ARP caches of A and B have been poisoned.
* Exploiting Gratuitous ARP (contd.)
If A wishes to communicate with B, it will create a frame with
destination MAC address = x.

The LAN switch will forward this frame to X. X may read and
modify all such frames and then send them to B.

Because, Bs cache has also been poisoned, X will be able to
intercept all frames from B to A.

In effect, X is able to launch a man-in-the-middle attack on
the communications between A and B.
* MiM Attack due to ARP cache poisoning
Possible solutions to ARP spoofing
Disallow gratuitous ARP replies

Allow only authenticated ARP replies (this may require PKI or
Kerberos support)

Use static ARP caches which ignore updates sent by random
machines

Use intelligent switches
Which learn which MAC addresses and IP addresses are mapped to
which switch port
Monitor IP address/MAC address pairings in Ethernet frames and in
ARP replies and check for inconsistency with what has been learned by
the switch
Attacks on DNS
Attacks on DNS are similar to attacks on ARP.

DNS cache poisoning analogous to ARP cache
poisoning one cause is gratuitous DNS
replies

The next slide summarizes how a DNS query is
processed
DNS Query Processing
Pharming Attack
A bank called TrueBank has an internet presence. TrueBank
customers may perform banking transactions by logging on to
its web site www.Truebank.com.

On one occasion, a banks customer enters the URL of
TrueBank, www.Truebank.com, on his browser.

The web page that is downloaded has the look and feel of the
authentic one but it is a site owned by an attacker. The
customer is unaware that the web site belongs to an attacker.
He proceeds to enter his login name and password which are
then captured by the attacker.

This attack seems similar to a phishing attack but is instead an
example of a pharming attack.
Possible Attack Vectors
The name server who provided the IP address of TrueBank
could have been a rogue server under the attackers control.

The response to the DNS query regarding TrueBanks IP
address could have been tampered with on its journey to
one of the caching DNS servers.

Even if the response were obtained from an authoritative
name server, the entries in the server (A records) may have
been polluted. This kind of an attack is known as DNS cache
poisoning.

DNSSec
Many of the attacks on DNS stem from the lack of data origin
authentication and data integrity in DNS query responses.

The basic idea in DNSSec is to have the name server sign each
DNS response using its private key

New resource records are introduced in DNS RRSIG record
(which contains a signature), DNSKEY (which contains an
entitys public key), etc.
* Vulnerabilities in LANs
In Ethernet and 802.11 LANs, there are well
defined rules governing when a node should
talk, how nodes should handle collisions, etc.

The smooth functioning of these networks
depends on the stations on the LAN strictly
obeying the MAC rules.
* Vulnerabilities in LANs (contd.)
There are rules governing when a node may transmit after
sensing a collision or rules related to inter-frame spacing. If
these rules are violated, stations on the LAN will see garbled
messages.

Frames may also be spoofed leading to, for example,
premature disconnection of communicating parties on an
802.11 LAN

See Section 17.4 of text for examples of attacks on 802.11
LANs