TCP/IP: TCP Network Security Lecture 7 Eike Ritter Network - - PowerPoint PPT Presentation

TCP/IP: TCP

Network Security Lecture 7

Eike Ritter 1 Network Security - Lecture 7

TCP spoofing

• Steps

– M kills B (e.g., flooding) – M sends SYN segment to A with source IP address set to B’s IP address – A sends a SYN/ACK to B, with its initial sequence number IA – M completes the 3-way handshake, with ACK set to IA + 1

• M eavesdrops A’s response containing IA [we know how to do this]
• M guesses the correct IA value (“blind spoofing”) [we will focus on this]
• Alice trusts Bob (e.g., logins on Alice are allowed with

no password if TCP connection comes from host Bob)

• Mallory wants to impersonate Bob when opening a

TCP connection to Alice

Eike Ritter 2 Network Security - Lecture 7

TCP spoofing

• Described in R. T. Morris, A Weakness in the 4.2BSD UNIX TCP/IP

Software

• Used by Kevin Mitnick attack in his attack against the San Diego

Supercomputer Center

• Addressed by S. Bellovin, RFC 1984, Defending Against Sequence

Number Attacks

– Set initial sequence number to the timer prescribed originally + the value of a cryptographic hash function of each connection:

ISN = M + F(localhost, localport, remotehost, remoteport)

– It is vital that F not be computable from the outside, so it is keyed with with some secret data

• True random number
• Per-host secret and boot time of the machine

– Thus, each connection is given a separate sequence number space

• That’s the theory, at least

Eike Ritter 3 Network Security - Lecture 7

Initial sequence number revisited

• How about the actual implementations?

– Are the different OSes correctly implementing initial sequence number generators? – How do you test it?

• Michal Zalewski looks at this problem in Strange Attractors and TCP/IP Sequence

Number Analysis and the follow-up study One Year Later

• Derive properties of ISN generators by observing the generated ISNs (instead of,

say, looking at their implementation)

• For example: 4293832719, 3994503850, 4294386178, 134819, 4294768138

191541, 4294445483, 4294608504, 4288751770, 88040492, ...

• Phase space analysis to visualize hidden dependencies

– Represent a sequence of ISNs in a 3-d space: x[t] = seq[t] - seq[t-1] y[t] = seq[t-1] - seq[t-2] z[t] = seq[t-2] - seq[t-3] – Look for unexpected regularities in this space (“attractors”) – Use attractor to build “Spoofing Sets”, i.e., likely values for the next ISN

Eike Ritter 4 Network Security - Lecture 7

Linux 2.2

Eike Ritter 5 Network Security - Lecture 7

Windows 2000

Eike Ritter 6 Network Security - Lecture 7

Windows 98

Eike Ritter 7 Network Security - Lecture 7

Cisco IOS - before

Eike Ritter 8 Network Security - Lecture 7

Cisco IOS - after

Eike Ritter 9 Network Security - Lecture 7

TCP hijacking

• We saw: TCP spoofing + address-based authentication = attacker wins

– What if authentication is performed by other means, e.g., password-based? – Attacker needs a more powerful attack

• Attacker waits for TCP connection to be established and then creates a

desynchronized state on both ends of the connection

– Two points cannot communicate

• Then creates acceptable packets for both ends

– At this point, attacker completely controls the connection

• Performed by using spoofed TCP segments to

– Insert data in the streams – Reset an existing connection (denial of service)

• First described in
• L. Joncheray, “Simple Active Attack Against TCP”

Eike Ritter 10 Network Security - Lecture 7

TCP hijacking

• Scenario: attacker wants to inject data into existing TCP

connection between two hosts

– Think of telnet connection between A and B – M wants to hijack connection to inject commands that will be executed on B

• Attacker waits until the connection to hijack is “quiet”

– All the sent data has been acknowledged

• Attacker injects data into the stream (“desynchronization”)

– echo “+ +” > ~/.rhosts – Source IP is spoofed to A’s IP address – SEG.SEQ = last ACK from the server – SEG.ACK = last SEQ from the server

• Datagram is acceptable and will be processed by the server

Eike Ritter 11 Network Security - Lecture 7

TCP hijacking

• What happens next?
• Server sends ACK to A

– Remember: attacker is spoofing A’s address – SRV.ACK = M

• Client receives segment, notices it is out of order, and

sends ACK with the “right” sequence number

– CLN.ACK = N (N < M)

• Server receives segment, notices it is out of order, and

sends ACK with the “right” sequence number

– SRV.ACK = M

• . . .
• “Ack storm”

Eike Ritter Network Security - Lecture 7 12

ACK storm

Eike Ritter 13 Network Security - Lecture 7

172.16.48.2.1026 > 172.16.48.1.23: P 1015112:1015133(21) ack 4056578923 172.16.48.1.23 > 172.16.48.2.1026: . seq 4056578923 ack 1015133 172.16.48.2.1026 > 172.16.48.1.23: . seq 1015112 ack 4056578923 172.16.48.1.23 > 172.16.48.2.1026: . seq 4056578923 ack 1015133 172.16.48.2.1026 > 172.16.48.1.23: . seq 1015112 ack 4056578923 172.16.48.1.23 > 172.16.48.2.1026: . seq 4056578923 ack 1015133 172.16.48.2.1026 > 172.16.48.1.23: . seq 1015112 ack 4056578923 172.16.48.1.23 > 172.16.48.2.1026: . seq 4056578923 ack 1015133 172.16.48.2.1026 > 172.16.48.1.23: . seq 1015112 ack 4056578923 172.16.48.1.23 > 172.16.48.2.1026: . seq 4056578923 ack 1015133 172.16.48.2.1026 > 172.16.48.1.23: . seq 1015112 ack 4056578923 172.16.48.1.23 > 172.16.48.2.1026: . seq 4056578923 ack 1015133 172.16.48.2.1026 > 172.16.48.1.23: . seq 1015112 ack 4056578923 172.16.48.1.23 > 172.16.48.2.1026: . seq 4056578923 ack 1015133 172.16.48.2.1026 > 172.16.48.1.23: . seq 1015112 ack 4056578923 172.16.48.1.23 > 172.16.48.2.1026: . seq 4056578923 ack 1015133 172.16.48.2.1026 > 172.16.48.1.23: . seq 1015112 ack 4056578923

Fixing the ACK storm

• How to prevent/stop?
• Disable the client so that it does not reply to server’s ACKs
• Resynchronize

– Send “null data” to client so that it resyncs with the server – In telnet, NOP commands

• Just wait

– ACKs that carry no data are not retransmitted if lost – ACK storm will congest the network – So eventually, ACKs will be lost

• ARP spoofing

– Spoofs client so that server ACKs only reach the attacker

Eike Ritter Network Security - Lecture 7 14

SYN flooding

• Denial of service attack
• Attacker sends a SYN packet
• Victim replies with SYN/ACK segment

– Internally, the victim allocates resources to keep track of the half-open connection – “Transmission Control Block” (TCB) – In practice, some memory

• Attacker does not send ACK
• The victim has limited number of available TCBs to keep

track of the half-open connection

– When limit is reached, it will not accept any other connection

• Can the attacker easily hide (spoof) its source address?

Eike Ritter 15 Network Security - Lecture 7

SYN flooding defenses

• How would you protect from this attack?
• Filtering

– To block spoofed packets

• Increase the length of the queue storing half-open

connections

• Recycle existing half-open connections when the limit is

reached and new connections arrive

• Reduce the SYN-RECEIVED timeout

– Time waited between receiving a SYN and recycling the resources allocated to this connection

• Do not allocate any state at all for a received SYN

– SYN cookie

Eike Ritter 16 Network Security - Lecture 7

SYN cookie

• Encode the connection state in the initial sequence number

and/or other fields (e.g., the Timestamp option)

• Set ISN to t | m | s

– t: timestamp – m: MSS – s: result of crypto function on server address and port, client address and port, t

• When ACK is received

– Recover the ISN (ACK – 1) – Check t against current timestamp and check that it is close enough – Recompute s and check that it is valid – Decode m

Eike Ritter 17 Network Security - Lecture 7