1
Network Attacks, Part 1
CS 161: Computer Security
- Prof. Vern Paxson
TAs: Devdatta Akhawe, Mobin Javed & Matthias Vallentin
http://inst.eecs.berkeley.edu/~cs161/
February 3, 2011
Network Attacks, Part 1 CS 161: Computer Security Prof. Vern Paxson - - PowerPoint PPT Presentation
Network Attacks, Part 1 CS 161: Computer Security Prof. Vern Paxson TAs: Devdatta Akhawe, Mobin Javed & Matthias Vallentin http://inst.eecs.berkeley.edu/~cs161/ February 3, 2011 1 Announcements / Game Plan Homework #1 out now, due
1
February 3, 2011
2
3
Application Transport (Inter)Network Link Physical 7 4 3 2 1
4
5
6
7
8
9
10
Application Transport (Inter)Network Link Physical 7 4 3 2 1
4-bit Version 4-bit Header Length 8-bit Type of Service (TOS)
16-bit Total Length (Bytes) 16-bit Identification
3-bit Flags
13-bit Fragment Offset
8-bit Time to Live (TTL)
8-bit Protocol 16-bit Header Checksum 32-bit Source IP Address 32-bit Destination IP Address Payload
IP = Internet Protocol
11
(FYI; don’t worry about unless later explicitly covered)
12
13
Application Transport (Inter)Network Link Physical 7 4 3 2 1
Source port Destination port Sequence number Acknowledgment Advertised window HdrLen Flags Checksum Urgent pointer Options (variable)
14
Application Transport (Inter)Network Link Physical 7 4 3 2 1 Source port Destination port Sequence number Acknowledgment Advertised window HdrLen Flags Checksum Urgent pointer Options (variable)
These plus IP addresses define a given connection
15
Application Transport (Inter)Network Link Physical 7 4 3 2 1 Source port Destination port Sequence number Acknowledgment Advertised window HdrLen Flags Checksum Urgent pointer Options (variable)
Defines where this packet fits within the sender’s bytestream
16
17
Source port Destination port Sequence number Acknowledgment Advertised window HdrLen Flags Checksum Urgent pointer Options (variable)
18
Source port Destination port Sequence number Acknowledgment Advertised window HdrLen
RST
Checksum Urgent pointer Options (variable)
19
– E.g., because app. process on A crashed
expects, That’s It: – B’s user-level process receives: ECONNRESET
– No further communication on connection is possible
SYN SYN ACK ACK D a t a RST ACK
time
20
21
– Again, all that’s required is attacker knows correct ports, seq. numbers – Receiver B is none the wiser!
– General means to take over an already-established connection!
– Because then they immediately know the port & sequence numbers
SYN SYN ACK ACK D a t a ACK
time
N a s t y D a t a N a s t y D a t a 2
22
23
Client (1.2.3.4) Server (5.6.7.8) S Y N , S e q N u m = x SYN + ACK, SeqNum = y, Ack = x + 1 A C K , A c k = y + 1 Each host tells its Initial Sequence Number (ISN) to the other host.
(Spec says to pick based on local clock)
24
Client? (1.2.3.4) Server (5.6.7.8) S Y N , S e q N u m = x SYN + ACK, SeqNum = y, Ack = x + 1 A C K , A c k = y + 1 Each host tells its Initial Sequence Number (ISN) to the other host.
(Spec says to pick based on local clock) Attacker can spoof this But can’t see this So how do they know what to put here? Hmm, any way for the attacker to know this? Sure - make a non-spoofed connection first, and see what server used for ISN y then! How Do We Fix This? Use A Random ISN
Attacker