Advisory location:
http://www.jakoblell.com/blog/2013/08/13/quick-blind-tcp-connection-spoofing-with-syn-cookies/
Quick Blind TCP Connection Spoofing with SYN Cookies
Abstract:
TCP uses 32 bit Seq/Ack numbers in order to make sure that both sides of
a connection can actually receive packets from each other. Additionally,
these numbers make it relatively hard to spoof the source address
because successful spoofing requires guessing the correct initial
sequence number (ISN) which is generated by the server in a
non-guessable way. It is commonly known that a 32 bit number can be
brute forced in a couple of hours given a fast (gigabit) network
connection. This article shows that the effort required for guessing a
valid ISN can be reduced from hours to minutes if the server uses TCP
SYN Cookies (a widely used defense mechanism against SYN-Flooding DOS
Attacks), which are enabled by default for various Linux distributions
including Ubuntu and Debian.
I. Repetition of TCP Basics
A TCP Connection is initiated with a three-way handshake:
SYN: The Client sends a SYN packet to the server in order to initiate a
connection. The SYN packet contains an initial sequence number (ISN)
generated by the client.
SYN-ACK: The server acknowledges the connection request by the client.
The SYN-ACK Packet contains an ISN generated by the server. It also
confirms the ISN from the client in the ack field of the TCP header so
that the client can verify that the SYN-ACK packet actually comes from
the server and isn't spoofed.
ACK: In the final ACK packet of the three-way handshake the client
confirms that it has received the ISN generated by the server. That way
the server knows that the client has actually received the SYN-ACK
packet from the server and thus the connection request isn't spoofed.
After this three-way handshake, the TCP connection is established and
both sides can send data to each other. The initial sequence numbers
make sure that the other side can actually receive the packets and thus
prevent IP spoofing given that the attacker can't receive packets sent
to the spoofed IP address.
Since the initial sequence numbers are only 32-bit values, it is not
impossible to blindly spoof a connection by brute-forcing the ISN. If we
need to send 3 packets to the server (one SYN packet to initiate the
connection, one ACK packet to finish the three-way handshake and one
payload packet), we will have to send 3*2^32 packets per successfully
spoofed connection at an average. Given a packet rate of 300,000 packets
per second (which can easily be achieved with a gigabit connection),
sending this packets requires some 12 hours.
One long-known weakness of the original TCP protocol design is that an
attacker can spoof a high number of SYN packets to a server. The server
then has to send (and maybe even retransmit) a SYN-ACK packet to each of
the spoofed IP addresses and keep track the half-open connection so that
it can handle an ACK packet. Remembering a high number of bogus
half-open connections can lead to resource exhaustion and make the
server unresponsive to legitimate clients. This attack is called SYN
Flooding and it can lead to DOS even if the attacker only uses a
fraction of the network bandwidth available to the server.
II. Description of the SYN Cookie approach
In order to protect servers against SYN-Flooding attacks, Daniel J.
Bernstein suggested the technique of TCP Syn Cookies in 1996. The main
idea of the approach is not to keep track of incoming SYN packets and
instead encode the required information in the ISN generated by the
server. Once the server receives an ACK packet, he can check whether the
Ack number from the client actually matches the server-generated ISN,
which can easily be recalculated when receiving the ACK-packet. This
allows processing the ACK packet without remembering anything about the
initial SYN request issued by the client.
Since the server doesn't keep track of half-open connections, it can't
remember any detail of the SYN packet sent by the client. Since the
initial SYN packet contains the maximum segment size (MSS) of the
client, the server encodes the MSS using 3 bits (via a table with 8
hard-coded MSS values). In order to make sure that half-open connections
expire after a certain time, the server also encodes a
slowly-incrementing (typically about once a minute) counter to the ISN.
Other options of the initial SYN packet are typically ignored (although
recent Linux kernels do support some options by encoding them via TCP
Timestamps [1]). When receiving an ACK packet, the kernel extracts the
counter value from the SYN Cookie and checks whether it is one of the
last 4 valid values.
The original approach of Bernstein [2] only encodes the counter and the
MSS value in the first 8 bits of the ISN thus leaving only 24 bits for
the cryptographically generated (non-guessable) value which needs to be
guessed for spoofing
