CS162 Section

1. CS162 Section Lecture 12

2. Digital Certificates • How do you know is Alice’s public key? • Main idea: trusted authority signing binding between Alice and its private key {Alice, } Certificate Authority (offline) identity verification Digital certificate E({ , Alice}, Kverisign_private) Alice Bob D(E({ , Alice}, Kverisign_private), Kverisign_public) = {Alice, }

3. Passwords • Password check: SHA(password-entered) and check against stored SHA(true-password). Password not stored in plaintext. If obtain password-hash file, can try to crack password. SHA: given SHA(true-password), very hard to find x such that SHA(x)=SHA(true-password) • Dictionary attack: 10^4 words in dictionary, 10^8 guesses/second  All two-word combinations (case insensitive) in one second • Salt: Precompute SHA(dictionary) for faster search. Related: SHA(apple) matches *any* user with “apple” password. Salt  Instead of storing SHA(password), store 1234:SHA(1234password). Rainbow table size prohibitively large, so back to online hashing: Have to try “apple” for every user individually.

4. Example: Normal Execution void get_cookie(char *packet) { . . . (200 bytes of local vars) . . . munch(packet); . . . } void munch(char *packet) { int n; char cookie[512]; . . . code here computes offset of cookie in packet, stores it in n strcpy(cookie, &packet[n]); . . . } Stack X + 200 get_cookie()’s stack frame X return address backto get_cookie() X - 4 n X - 8 cookie X - 520 return address backto munch() X - 524 strcpy()’s stack …

5. Example: Buffer Overflow void get_cookie(char *packet) { . . . (200 bytes of local vars) . . . munch(packet); . . . } void munch(char *packet) { int n; char cookie[512]; . . . code here computes offset of cookie in packet, stores it in n strcpy(cookie, &packet[n]); . . . } Stack X + 200 cookie value read from packet get_cookie()’s stack frame X return address backto get_cookie() X - 4 n X - 8 X - 520 return address backto munch() X - 524

6. Potential Solutions • Don’t write buggy software • Program defensively – validate all user-provided inputs • Use code checkers (slow, incomplete coverage) • Use Type-safe Languages (Java, Perl, Python, …) • Eliminate unrestricted memory access of C/C++ • Use HW support for no-execute regions (stack, heap) • Leverage OS architecture features • Address space randomization • Compartmentalize programs • E.g., DNS server doesn’t need total system access • Add network firewalls

7. Firewall • Security device whose goal is to prevent computers from outside to gain control to inside machines • Hardware or software Attacker Firewall Internet

8. No safety in numbers • Today: estimated that a single worm could compromise 10M hosts in < 5 min using a zero-day exploit • Unpatched stock Win7 machine lasts less than 10 mins before compromise (without firewall). Not even enough time to download patches.  Download in advance and patch offline.

9. (D)DOS • $ motive: extortion. Threaten to disable flowers.com on Mother’s Day. • If attack centralized, can filter IP block. IP source spoofing. Egress filtering. Botnets legitimately have a lot of IP addresses • Largest botnets in 1-5 million range. Even if have techniques to stop flooding hosts… Consider a site with 10k users each clicking a link every 60 seconds. Now have 5 million machines each acting like a normal user – can’t distinguish good from bad.

10. SYN, SeqNum = x SYN and ACK, SeqNum = y and Ack = x + 1 ACK, Ack = y + 1 SYN Attack(Recap: 3-Way Handshaking) • Goal: agree on a set of parameters: the start sequence number for each side • Starting sequence numbers are random. Server Client (initiator)

11. SYN Attack • Attacker: send at max rate TCP SYN with random spoofed source address to victim • Spoofing: use a different source IP address than own • Random spoofing allows one host to pretend to be many • Victim receives many SYN packets • Send SYN+ACK back to spoofed IP addresses • Holds some memory until 3-way handshake completes • Usually never, so victim times out after long period (e.g., 3 minutes)

12. Solution: SYN Cookies • Server: send SYN-ACK with sequence number y, where • y = H(client_IP_addr, client_port) • H(): one-way hash function • Client: send ACK containing y+1 • Sever: • verify if y = H(client_IP_addr, client_port) • If verification passes, allocate memory

13. Miscellaneous • Input sanitation: SQL injection, Cross-site scripting (XSS) • Cookie/session hijacking over open wifi • Some MITM attacks leverage temporary DOS attack to disable legit site and then pose as the legit site. • Example MITM: become default gateway and rewrite URLs from “https” to “http”; users don’t notice not secured.

14. Napster: centralized directory of files on all machines. Single point of failure. • Gnutella: no centralized directory. Broadcast with TTL; not scalable. • Gnutella v2 (Kazaa): Special peers (fast network connection and CPU) become local directories. No single point of failure. • DHT (Chord, CAN) m3 m7 m2 m4 B B B D D m8 m1 B: m7 D: m8 B: m2, m3 … D: m4 … Ultrapeer nodes C: m10, m11 … C m10 A: m15 C: m13 C: m17 … … C C m11 m17 A Leaf nodes C m15 m13

15. Content Addressable Network (CAN) • Associate to each node and item a unique id in an d-dimensional space, e.g., torus • Properties • Routing table size O(d), i.e., each node needs to know about O(d) • Guarantees that a file is found in at most d*n1/d steps, where n is the total number of nodes

16. CAN Example: Two Dimensional Space • Nodes: n1:(1, 2); n2:(4,2); n3:(3, 5); n4:(5,5);n5:(6,6) • Items: f1:(2,3); f2:(5,0); f3:(2,1); f4:(7,5); 7 6 n5 n4 n3 f4 5 4 f1 3 n1 n2 2 f3 1 f2 0 0 2 3 4 6 7 5 1

17. CAN: Query Example • Each node knows its neighbors in the d-space • Forward query to the neighbor that is closest to the query id • Example: assume n1 queries f4 7 6 n5 n4 n3 f4 5 4 f1 3 n1 n2 2 f3 1 f2 0 0 2 3 4 6 7 5 1

18. Content Addressable Network (CAN) • Properties • Routing table size O(d), i.e., each node needs to know about O(d) neighbors • Guarantees that a file is found in at most d*n1/d steps, where n is the total number of nodes • Example: grid with n node (d = 2)

19. BitTorrent (2001) • Allow fast downloads even when sources have low up-link capacity • How does it work? • Seed (origin) – site storing the file to be downloaded • Tracker – server maintaining the list of peers in system • Split each file into pieces (~ 256 KB each), and each piece into sub-pieces (~ 16 KB each) • The loader loads one piece at a time • Within one piece, the loader can load up to five sub-pieces in parallel

20. BitTorrent: Download Algorithm • Download consists of three phases: • Start: get a piece as soon as possible • Select a random piece • Middle: spread all pieces as soon as possible • Select rarest piece next • End: avoid getting stuck with a slow source, when downloading the last sub-pieces • Request in parallel the same sub-piece • Cancel slowest downloads once a sub-piece has been received (For details see: http://bittorrent.org/bittorrentecon.pdf)

21. Bittorrent: Handling Freeriders • Free riders: peers that use the network without contributing (with the upstream bandwidth) • When a peer's upload bandwidth is saturated, it exchanges upload bandwidth for download bandwidth • If peer U downloads from peer C and doesn’t upload in return, C chokes download to U C C choke U U