TCP/IP Vulnerabilities
1
Contents




Vulnerabilities in IP protocol
ICMP attacks
Routing attacks
TCP attacks



Sequence number prediction
TCP SYN flooding
Congestion control with a misbehaving
receiver
Historical perspectives




TCP/IP and their associated protocols were
designed without any security consideration in
mind.
“Security problems in the TCP/IP Protocol Suite”
by S. M. Bellovin
This paper was written in 1989. It gave the
security perspective on TCP/IP protocols in the
early days.
It acted as a wakeup call for network
researchers, listing many security vulnerabilities.
Vulnerabilities in IP protocol



Fundamental flaw in IP protocol is to use
IP address as authentication.
IP source address can be easily spoofed.
It is easy for attackers to impersonate
another host in the same network.
Basic attacks
2.0.0.0
2.1.1.1
Internet
C
A
1.1.1.1
B
1.1.1.2
1.0.0.0
1.1.1.3 Server




How can the server know that the packet is originated
from A?
Can B overhear?
Can B impersonate A to the server?
Can C impersonate A to the server?
IP fragmentation attack



In the regular IP layer operations, a host
stores fragmented packets until entire
packets arrive.
Attack: send only one fragmented packet.
Then the host will wait indefinitely,
wasting memory to store them.
Countermeasure?
Smurf attack



Send a packet with a broadcast address to
a network with source address as a
victim’s address.
All hosts on the network will send reply
packets to the victim.
This is called a reflector attack. In this
case the reflector also performs traffic
amplification.
ICMP attacks



ICMP is the basic network management tool of
the TCP/IP protocol suite.
It poses potential threats for abuse.
ICMP redirect message


ICMP destination unreachable


Attacker sends false ICMP redirect message to a host
to redirect traffic for a destination through another
gateway.
DoS attack
ICMP TTL exceed

DoS attack
Routing Attacks

Source routing attack


Routing information protocol attack



Not possible today’s networks
An attacker sends bogus routing information
to a target router to impersonate a particular
router.
It is necessary to authenticate every routing
information packets.
BGP routing attacks
TCP attacks:
Sequence number prediction

Normal TCP precedure






C → S:
S → C:
C → S:
C → S:
S → C:
SYN(ISNc)
SYN(ISNs). ACK(ISNc)
ACK(ISNs)
data and/or
data
If an intruder X can predict ISNs, X can
impersonate T:




X→
S→
X→
X→
S: SYN(ISNx). SRC=T
T: SYN(ISNs). ACK(ISNx)
S: ACK(ISNs), SRC=T
S: ACK(ISNs), SRC=T, nasty-data
How to decide ISN?

Are these good choices for next TCP ISN?




Always start at the same ISN
After each connection, increment ISN
ISN = (c1+c2*(current time)) mod 232
Better choice for ISN?



ISN = rand() function of C library?
Current ISN = H(prev ISN)?
ISN = DESK(counter++)?
TCP hijacking and poisoning

TCP hijacking


If TCP sequence number is known, attacker
can inject malicious message into TCP stream.
TCP poisoning


Inject random data into TCP stream to shut
down TCP connection
Does sequence number need to be known?
TCP SYN Flooding

Normal TCP precedure






C → S:
S → C:
C → S:
C → S:
S → C:
SYN(ISNc)
SYN(ISNs). ACK(ISNc)
ACK(ISNs)
data and/or
data
SYN flooding



The server S needs to keep state after receiving initial
SYN packet.
Attacker floods server with SYN packets, but does not
follow up with ACK packets to complete TCP
handshake.
The server keeps state waiting for ACK, consequently
exhausting resources.
SYN Flooding Dos Attack

It was the first serious DoS attack, single
attacker could tie up server resources to
prevent other clients from connecting to
server.
SYN Flood Details

Why does server exhaust resources?



Memory is cheap, why not store all requests?


Need to store requests for 511 seconds
Server has finite-size queue for incomplete connections, usually
1024 entries
With 160 bytes for syncache data structure, still consumes a lot
of memory (736 bytes previously)
Why store any information at all?



If SYN ACK dropped by network, server re-sends SYN ACK until
timeout or client sends ACK, otherwise legitimate clients will wait
In some cases TCP options (performance enhancements) need
to be stored.
Attacker could simply send ACK only if no information stored,
hope server will allocate resources for connection
Solution: TCP SYN Cookie

Server computes ISN based on the client’s
addresses, which is called SYN cookie, and avoid
to keep the client’s state.




Server does not remember the cookie or any other
state info corresponding to the SYN.
Client sends ACK.
Server verifies ISN. If correct, it allocates
connection state.
How to compute SYN cookie?

Cookie=H(SIP, CIP, Sport, Cport, skey), skey is a
secrete number only known to the server.


“Defining Strategies to Protect Against
TCP SYN Denial of Service Attacks,”
http://www.cisco.com/en/US/tech/tk828/t
echnologies_tech_note09186a00800f67d5.
shtml
“SYN Cookies,” D. Bernstein,
http://cr.yp.to/syncookies.html
Questions:


What if SYN segment has some relevant
information to the client state such as TCP
option?
What if attackers return valid ACK for each
SYN ACK? This will cause the server to
establish fully open TCP connections.

This “completed handshake attack” can be
more difficult to defend than the classical SYN
flooding attack.
Congestion control with a
misbehaving receiver

“TCP congestion control with a
misbehaving receiver”, Savage, Cardwell,
Wetherall, and Anderson
Slow Start

Control parameters


Awnd (advertised window by receiver)
Cwnd (congestion window)


Determine how many segments can be sent
without receiving ACKs..
Slow Start
Initialize: cwnd = 1 MSS (max. segment size);
Every time each ACK arrives:
cwnd = cwnd + 1 MSS until min(cwnd, awnd)
ACK Division Attack

Upon receiving a segment, a receiver divides an
ACK into multiple ACKs. Then the sender increases
the congestion window by SMSS (Sender Max
Segment Size) for each ACK received

Fast retransmission

If 4 consecutive ACKs(3 dupacks) are received
before timeout, then TCP does not wait for
timeout and retransmit the segment
immediately.

Fast recovery algorithm (avoiding initial slow start phase)
1. When the third duplicate ACK is received,
Set ssthresh = cwnd / 2;
Retransmit the missing segment;
cwnd = ssthresh + 3 segment size ;
2. Each time another duplicate ACK arrives,
Increment cwnd by the segment size;
Transmit a new segment (if allowed by the new cwnd value);
3. When the next ACK arrives that acknowledges the new data,
cwnd = ssthresh ;
cwnd = cwnd + 1 every roundtrip time ;
Duplicate ACK Spoofing




Fast retransmit and fast recovery should mitigate the
effect of packet loss that is not due to congestion, but
an attacker can exploit it to get more data
Send extra duplicate ACKs
Sender sends 1 packet for
each duplicate ACK
Preserves reliability
Optimistic ACKing Attack


Receiver can send ACKs for data not yet
received, or even not yet sent
Does not provide reliability
Countermeasures: