Computer Security 2014 –Ymir Vigfusson
Some slides borrowed from Amir Masoumzadeh’s INFSCI 1075, Dan Boneh@Stanford, CSAPP@CMU

The Internet is a series of tubes
ISP
Backbone
ISP

Dark clouds are Autonomous Systems (AS)

Backbone routers use the BGP protocol

Messages are exchanged using TCP/IP
2
What we care
about the most
in the course
3

The end-to-end principle
 No need to understand application logic in a network
except at end hosts. Cleaner design.
Application protocol
Application
Application
TCP protocol
Transport
Transport
Network
IP protocol
IP
IP protocol
Network
Link
Data
Link
Network
Access
Data
Link
Link
4

Implementation of different layers
TCP Header
Application
message
Transport (TCP, UDP)
segment
Network (IP)
packet
Link Layer
frame
IP Header
Application message - data
TCP
data
TCP
data
IP TCP
data
ETH IP TCP
data
Link (Ethernet)
Header
TCP
data
ETF
Link (Ethernet)
Trailer
5
(1)
client
server
protocol
software
data
data
LAN1
adapter
PH ETH1
(8)
data
(7)
data
PH ETH2
(6)
data
PH ETH2
protocol
software
PH ETH1
LAN1 frame
(3)
Host B
data
internet packet
(2)
Host A
LAN2
adapter
Router
LAN1
adapter
LAN2
adapter
LAN2 frame
(4)
data
PH: Internet packet header (IP + TCP)
FH: LAN frame header
PH ETH1
data
PH ETH2 (5)
protocol
software
6
 Link layer (Layer 2) uses MAC addresses for naming
 Network layer (Layer 3) uses IP addresses instead


How do we translate between these on a LAN?
Answer: ARP is a simple protocol for precisely that
7

What could possibly go wrong?
 After a response, contents of ARP reply is temporarily
cached by those who heard it
▪ Even if nobody requested it (fixed in some OSes)
8


ARP has no authentication, fully trusting
Hackers exploit it to:
 Snoop on traffic (“sniff“) to learn about passwords
 Pretend to be someone else (“spoof“) to get more access
 Redirect traffic (“man-in-the-middle“) to hijack sessions
9
Source Port
Dest port
SEQ Number
ACK Number
U A P P S F
R C S S Y I
G K H R N N
TCP Header
Other stuff
10

A regular TCP 3-way handshake
 Client sends SYN packet with random client seq. number
 Server responds with SYNACK and both server and client
seq. number (the latter incremented by one)
 Client sends ACK
Credit: Amir Masoumzadeh
11

Can forge TCP packets as appearing to have been
sent from another IP address
 Can open up a connection, but need to guess seq. numb

Blinded: Attacker does not see responses
 Victim may send RST packets on spurious connection
 Limited damage attackers can do here, especially if a
connection is required

Unblinded: You can snoop packets coming back
 NSA has (had?) unique capabilities to do this

Status today
 Backbones have some protections: they filter packets
that definitely are in the wrong place (ingress/egress
filtering)
12

TCP is stateful
 For every incoming SYN, we send SYNACK and maintain
partial connection state while we wait for ACK

What if an attacker send tons of SYN packets?

How can we defend ourselves?

Idea: SYN Cookies (DJ Bernstein)
 Encode state in server seq. number
 timestamp | MSS | hash(IPs,ports)
 Server can both verify that cookie was
created by it earlier, and recover state
13

Hackers want to know what ports are open
 Possibly compromise services running on ports (e.g.
Apache running on port 80)

Complete TCP handshake for all common ports

Accurate, but not stealthy
 Appears in all logs
Credit: Amir Masoumzadeh
14

Can set various flags in the packet for stealth
 URG, ACK, PSH, RST, SYN, FIN
 X-Mas scan: set all the flags! RST means port is closed
 Null scan: set no flags. RST means port is closed
 TCP ACK: An RST packet back means port is open
 Window scan: Send ACK. 0 window iff closed (some OSes)
15

“Idle scan“ – covert scanning!
 Spoofs packets from a zombie to the target
 Checks if the IP ID counter has increased in follow-up
packets to zombie
▪ If increased, port must be open on target!
16

Different OSes implement underspecified parts in
TCP/IP stack differently
 E.g. Linux differs from BSD (now in OS X and Windows)

Can prod machines, infer what vendor and OS
version is running on a given IP address
 Can be more passive by observing regular traffic
▪ TCP SYN cookies, time-to-live values, TCP window sizes, OOB,...

Important once you have access inside an
organization
 Therefore IDS/IPS software tend to recognize attempts
17

Customers don‘t remember 1-800-432-1000

Customers certainly won‘t remember
„213.167.142.130“
 Same goes for IPs of all websites

DNS was invented in 1984 to allow names to be
associated with IP addresses
 Names given hierarchically („domains“)
19

DNS servers are given authority for subtrees
20

So how does a client actually use DNS?
Program calls gethostbyname(„syndis.is“)
2. gethostbyname parses /etc/resolv.conf
1.
3.
A packet is sent to 130.2.34.50 asking about the domain
21



[UDP Src 130.2.13.37]
[UDP Dst 130.2.34.50]
Yo, what‘s „syndis.is“ ?



[Transaction ID 64153]
[UDP Src 130.2.34.50]
[UDP Dst 130.2.13.37]
Hey, it‘s 4.3.2.1.
130.2.34.50
Local DNS
DNS Client
130.2.13.37
22



[Transaction ID 64153]
[UDP Src 130.2.13.37]
130.2.34.50]
[UDP Dst 130.2.34.50]
8.8.8.8]
Yo, what‘s „syndis.is“ ?
8.8.8.8
Upstream DNS
130.2.34.50
Local DNS
DNS Client
130.2.13.37



[UDP Src 8.8.8.8]
[UDP Dst 130.2.34.50]
Hey, it‘s 4.3.2.1.



[UDP Src 130.2.34.50]
[UDP Dst 130.2.13.37]
Hey, it‘s 4.3.2.1.
23
10:54:12.423228 130.2.34.50.33748 > 66.218.71.63.53:21345 [1au]A?
www.syndis.is. (42) (DF)
10:54:21.313293 130.2.34.50.33748 > 216.239.38.10.53:53735 [1au] A?
www.google.com. (43) (DF)
10:54:27.182852 130.2.34.50.33748 > 149.174.213.7.53:19315 [1au] A?
www.ru.is. (45) (DF)
10:54:43.252461 130.2.34.50.33748> 66.35.250.11.53:43129 [1au] A?
www.9gag.com. (42) (DF)
130.2.34.50
Local DNS

What‘s wrong?
Hax0r t1me
24
[UDP Src 130.2.34.50][ID 64153]
[UDP Dst 8.8.8.8]
Yo, what‘s „syndis.is“ ?
[UDP Src 130.2.34.50][ID 23172]
[UDP Dst 8.8.8.8]
Yo, what‘s „syndis.is“ ?
[UDP Src 130.2.34.50][ID 59774]
[UDP Dst 8.8.8.8]
Yo, what‘s „syndis.is“ ?
[UDP Src 8.8.8.8][ID 12345]
[UDP Dst 130.2.34.50]
Hey, it‘s 66.66.66.66...
[UDP Src 31.3.3.7]
[UDP Dst 130.2.34.50]
Yo, what‘s „syndis.is“ ?
[UDP Src 8.8.8.8][ID 12346]
[UDP Dst 130.2.34.50]
Hey, it‘s 66.66.66.66...
[UDP Src 8.8.8.8][ID 12347]
[UDP Dst 130.2.34.50]
Hey, it‘s 66.66.66.66...
[UDP Src 31.3.3.7]
[UDP Dst 130.2.34.50]
Yo, what‘s „syndis.is“ ?
[UDP Src 31.3.3.7]
[UDP Dst 130.2.34.50]
Yo, what‘s „syndis.is“ ?
Can we guess the right
transaction ID?
130.2.34.50
Local DNS
31.3.3.7
DNS Client
130.2.13.37
Hax0r t1me
25

Transaction IDs are 16 bits

We trigger N recursive queries at local DNS
 Each query has a random transaction ID

We spoof N responses back to local DNS
 Each response has a random transaction ID

We succeed if some response matches some query

How likely is this to happen?
26


23 people in a room
How likely that two people
share the same birthday?
For 𝑚 people and 𝑛 days, the
probability is about 1 − 𝑒
𝑚2
−
2𝑛
Roughly:
Answer: 50.7%!
27

Transaction IDs are 16 bits

We trigger N recursive queries at local DNS
 Each query has a random transaction ID

We spoof N responses back to local DNS
 Each response has a random transaction ID

We succeed if some response matches some query

𝑚2
− 2𝑛
The probability is 1 − 𝑒
=1−𝑒
𝑁2
−
2×216
 Over 50% with only 300 packets!
28

DNS Cache is poisoned
 DNS Clients may be redirected to malicious sites.
▪ I can haz your credit card

Several fixes available
 TTL
▪ The DNS Kaminsky attack in 2008 showed how this didn‘t work
 Randomize UDP source ports as well (like in djbdns)
 DNSSec
 DNSCurve ala djbdns
 DNS 0x20

Birthday attacks happen in other crypto!
29