CSE 451

1. CSE 451 Section March 2 Distributed Systems & Security 1

2. Overview • Project feedback • Questions on project 3 • Distributed systems • System Security 2

3. Project 2 feedback • Need to bullet proof OS • Can’t assume resources won’t run out: file IDs, address space IDs • Shouldn’t use any parameter without validation • Including buffer sizes • Need to test corner cases: • Running out of file Ids • Running out of physical memory • Loading programs too large for physical memory • Writeups: generally good • Add introduction/conclusion • Add hints for next quarter 3

4. Questions on project 3 • I need to meet with every group this week 4

5. Distributed Systems • People have talked about it since the 70s – why aren’t there more? • The web • File / print servers • Databases • Clusters • It’s really hard… • Machines fail • Messages get lost • Machines get corrupted 5

6. Distributed System Impossibilities • Attacking Generals Problem: • Deciding to attack – if both attack, win, if one attacks, lose. Can only send messengers that may be killed or subverted 6

7. Attacking Generals • It is impossible with a fixed maximum # of messages • You can never tell if your acknowledgement was heard • Suppose you had a protocol that took no more than 12 messages, but messages could get lost. • The last message could get lost • Ergo, you didn’t need the last message • If messages always get delivered, but one general is faulty (may die during decision making), you still can’t do it • This is important: consider transactions 7

8. Byzantine Generals Problem • Have multiple general trying to decide to attack. One or more may be traitors. Can they agree to attack? 8

9. Transactions • Distributed transactions use “two phase commit” • First phase: ask participants to vote • If all vote “commit”, send out commit message. If any vote “abort”, send abort message. • After vote to commit, participant changes must survive crashes • To continue after failure, reboot and ask what the vote was, or ask other participants to vote on what the decision was. • It is impossible to survive partitions (machines disconnected from other participants) and not “block” 9

10. Distributed systems • These kinds of results make things hard • Message get lost, and you don’t know where (on a request or reply) • Messages get delivered out of order • Messages can take a long time to get delivered • A very slow machine may appear dead • Failures occur in a distributed system that don’t occur on a single machine, so distribution isn’t invisible 10

11. Security • Security is also hard in a distributed system • How do you prove who you are? • How do you determine what someone is allowed to do? • How do you secure your system against attackers? 11

12. Proving who you are • This is Authentication • On a single computer, just store passwords in a file • On a distributed system, you don’t want to send passwords over the network: they could be “sniffed” • Three general approaches: • Secret key encryption • Public key encryption • Hardware 12

13. Secret Key Authentication • Each person has a key that is secret but known to the service. • Challenge response style: • S->A: random number • A->S {random number}Ka • Kerberos style: use “tickets” 13

14. Kerberos • Keys are only shared with a key distribution center. • To authenticate: • A ->KDC: A,B,time • KDC->A {B,time,k}Ka, {A,time,k}Kb • A->B {A,time,k}kb, {time}k • B->A {time}k • A->B 14

15. Public Key Encryption • Public keys: (asymmetric encryption) • One key encrypts, one key decrypts • One key kept private, the other key is public • To “sign” a message: encrypt with private key • To “seal” a message: encrypt with public key of recipient 15

16. Public Key Authentication • Uses certificates: • A->KDC: A,B • KDC->A: (PKB,B) skdc : a certificate • A->B: (na, A)PKB • B->KDC: B, A • KDC->B: (PKA,A)skdc • B->A: (na, nb)pka • A->B: (nb) pkb 16

17. What are you allowed to do? • Two approaches: • ACLs: have a list on each object of who is allowed access, and how much • Capabilities: get a ticket from someone that gives you access, and present the ticket • Both are used: • In NT: ACLs stored on all objects, used to grant a Handle to the object • The Handle is a capability: the ACL isn’t checked during access (e.g. read/write) 17

18. What are the common methods of attack? • Local exploits • Network Exploits • Root Kits 18

19. Intrusion Tools • Port Scanners (SATAN) • Remotely scan a range of addresses • Report on available services • NFS, NIS, Sendmail, TFTP, RSH, X, FTP • Report any known security holes • Can be detected (Courtney, Gabriel) • Monitor traffic with TCPDUMP 19

20. Intrusion Tools (2) • Host-based scanners (Cops, Tiger)) • Checks for known local problems • Insecure configurations (ACLs, Passwords) • Known bugs in services • Signs of intrusion (modified binaries) 20

21. Remote Exploits • Used to penetrate a machine with no local access (no existing account) • Drives deployment of firewalls • Services that perform operations based on unsecured user requests present vulnerabilities • Examples: • Sendmail • IP spoofing (for authentication by IP address only) 21

22. Local Exploits • Goal: gain unauthorized privileges for an existing account • Getting an account: • Social engineering (asking people for passwords) • Trading passwords • Sniffing traffic • Exploits derived from bugs that execution of hostile commands at a privileged level • Eg. Scripts running with SUID • Cracking passwords 22

23. Physical Exploits • Attach machine to network & sniff • Reboot machine with floppy • Remove hard drive • Walk up to logged-on machine • Modifying hardware, or convincing others to modify hardware 23

24. What are the exploits? • Domain errors – exposing data (e.g. passwords in pagefile) • Validation errors – not validating parameters (e.g. finger exploit) • Serialization – checking access asynchronously (e.g. allowing object to change after access check) • Authentication / Authorization errors – e.g SUID bit • Boundary condition violation – exhausting a resource (e.g. subst DOS) • Exploitable logic errors 24

25. Attack Process • Reconnaissance • DNS zone transfer – copies DNS database • Search newsgroups for email addresses – learn patterns • Probe • Port scan using SATAN – often logged • Distributed port scan – many clients scan same host • Check services for known vulnerabilities 25

26. Attack Process (2) • Attack the vulnerability • Attack code can be executed on the host in untrusted account • Find local exploit with COPS / TIGER • Become root 26

27. Attack Process (3) • Stealth • Modify logs to hide signs of attack • Replace binary files with modified versions that don’t report attack • Eg. modify PS, netstat to not report process & connections • Ensure future unlogged access • Listening • Sniffers - monitor local network traffic • Snoopers - monitor local I/o (keystrokes, etc.) to learn more accounts & passwords • Spread attack to related hosts 27

28. What next • Machines are used for future attacks: • Tribe Flood Network • Trin00 • Hackers remotely control a large network of computers, use them to coordinate attacks • Port scanning • Denial of service 28