Computer Security 2014 – Ymir Vigfusson Some slides borrowed from Amir Masoumzadeh’s INFSCI 1075, Dan

2  The Internet is a series of tubes  Dark clouds are Autonomous Systems (AS)  Backbone routers use the BGP protocol  Messages are exchanged using TCP/IP Backbone ISP

3 What we care about the most in the course

4  The end-to-end principle  No need to understand application logic in a network except at end hosts. Cleaner design. Application Transport Network Link Application protocol TCP protocol IP protocol Data Link IP Network Access IP protocol Data Link Application Transport Network Link

5  Implementation of different layers Application Transport (TCP, UDP) Network (IP) Link Layer Application message - data TCPdataTCPdataTCPdata TCP Header dataTCPIP IP Header dataTCPIPETHETF Link (Ethernet) Header Link (Ethernet) Trailer segment packet frame message

6 protocol software client LAN1 adapter Host A data (1) dataPHETH1 (4) dataPHETH2 (6) data (8) dataPHETH2 (5) LAN2 frame protocol software LAN1 adapter LAN2 adapter Router dataPH (3) ETH1 dataPHETH1 (2) internet packet LAN1 frame (7) dataPHETH2 protocol software server LAN2 adapter Host B PH: Internet packet header (IP + TCP) FH: LAN frame header

7  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

8  What could possibly go wrong?  After a response, contents ARP reply is temporarily cached by those who heard it ▪ Even if nobody requested it (fixed in some OSes)

9  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

10 Source PortDest port SEQ Number ACK Number Other stuff URGURG PSRPSR ACKACK PSHPSH SYNSYN FINFIN TCP Header

11  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

12  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)

13  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

14  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

15  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)

16  “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!

17  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

18 Credit: Amir Masoumzadeh

19  Customers don‘t remember  Customers certainly won‘t remember „ “  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“)

20  DNS servers are given authority for subtrees

21  So how does a client actually use DNS? 1. Program calls gethostbyname(„syndis.is“) 2. gethostbyname parses /etc/resolv.conf 3. A packet is sent to asking about the domain

22  [UDP Src ]  [UDP Dst ]  Yo, what‘s „syndis.is“ ? DNS Client Local DNS  [UDP Src ]  [UDP Dst ]  Hey, it‘s [Transaction ID 64153]

23  [UDP Src ]  [UDP Dst ]  Yo, what‘s „syndis.is“ ? DNS Client Local DNS  [UDP Src ]  [UDP Dst ]  Hey, it‘s  [UDP Src ]  [UDP Dst ]  Hey, it‘s Upstream DNS [Transaction ID 64153]  [UDP Src ]  [UDP Dst ]  Yo, what‘s „syndis.is“ ?

24 Hax0r t1me 10:54: > :21345 [1au]A? (42) (DF) 10:54: > :53735 [1au] A? (43) (DF) 10:54: > :19315 [1au] A? (45) (DF) 10:54: > :43129 [1au] A? (42) (DF)  What‘s wrong? Local DNS

25 [UDP Src ] [UDP Dst ] Yo, what‘s „syndis.is“ ? Hax0r t1me DNS Client [UDP Src ] [UDP Dst ] Yo, what‘s „syndis.is“ ? [UDP Src ] [UDP Dst ] Yo, what‘s „syndis.is“ ? Local DNS [UDP Src ][ID 64153] [UDP Dst ] Yo, what‘s „syndis.is“ ? [UDP Src ][ID 23172] [UDP Dst ] Yo, what‘s „syndis.is“ ? [UDP Src ][ID 59774] [UDP Dst ] Yo, what‘s „syndis.is“ ? [UDP Src ][ID 12345] [UDP Dst ] Hey, it‘s [UDP Src ][ID 12346] [UDP Dst ] Hey, it‘s [UDP Src ][ID 12347] [UDP Dst ] Hey, it‘s Can we guess the right transaction ID?

26  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?

27  23 people in a room  How likely that two people share the same birthday? Roughly: Answer: 50.7%!

28

29  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!

30  Helgi and Pétur have prepared a demo of an attack  Goal: Show how a hacker can steal passwords  A key tool being used:

31