Final Review Session

1. Spring 2006 CS 155 Final Review Session Collin Jackson

2. Final Details • Open book, open notes, closed laptop • Main final (recommended) • 7-10 PM on Tuesday, June 13 • Gates B01 • Alternate final • 3:30-6:30 PM on Monday, June 12 • Gates B03 • Study suggestions: • Previous finals available on course webpage • Reading, slides, lectures, homework • Email cs155ta@cs.stanford.edu with questions

3. Some Topics • Project 2 recap • SQL injection • Access control • TPM

4. Project 2 Recap Part 1 Part 2 Grading

5. Attack A: Cookie Theft Attack C: Login Snooping Most common issues were race conditions or attack differs from specification in some detail Mostly full credit given for attacks where idea was there. Attack B: Silent Transfer Attack D: Profile Worm Part 1: Attacks form link email zoobar.org zoobar.org badguy.com redirect stanford.edu form badguy.com email zoobar.org zoobar.org

6. Attack A: Cookie Theft Attack D: Profile Worm Part 2: Defenses Everybody fixed these.

7. Attack C: Login Snooping Attack B: Request Forgery Part 2: Defenses Ok: authentication cookie Easy to circumvent: userid or hash(userid) Ok: Add quotes around value Easy to circumvent: Blacklist dangerous strings

8. Part 2: More XSS Tests • index.php • Profile </textarea><script>…</script> • Exploitable? Depends on (optional) login CSRF defense • users.php • Profile <img onload=…> • User </script><script>…<script> • transfer.php • Recipient <script>…</script> • Exploitable? Depends on transfer CSRF defense

9. Part 2: Grading • Key ideas: • Preferred approach is escaping • Alternate approach is whitelisting • Blacklisting is easy to get wrong • Grades released sometime this weekend • If you feel your project was misgraded • Contact TAs • Reserve right to regrade entire project

10. SQL Injection Problem Overview Good defenses Bad defenses

11. SQL Syntax • Four basic commands (plus many others) • INSERT INTO [table] ([column], …) VALUES ([value], …) • SELECT [column], … FROM [table] WHERE [condition] • UPDATE [table] SET [column]=[value], … WHERE [condition] • DELETE FROM [table] WHERE [condition] • Strings delimited with ' • Statements separated with ; • Comments start with --

12. Attack Characteristics • Victim site builds query using concatenation • User data not validated • String may appear where integer expected "SELECT * FROM UserTable WHERE id=" + $_POST["userid"] • Breaks out of quoted string “SELECT Password FROM UserTable WHERE Username='" + $_POST["username"] + "'";

13. Crafting an attack • Spider site and look for input fields • Put ' in each field and look for errors • Try to determine the structure of the query • Guess and observe results • Error messages can be helpful • Construct malicious attack query, e.g. • Return sensitive data from other rows or tables • Modify passwords file to give attacker access

14. Example Question • Site form allows lookup by integer id: <input name=id><input type=submit> • Fix this query: "SELECT * FROM UserTable WHERE id=“ + Request["id"]; • Best: Parameterized SQL cmd.CommandText = "SELECT * FROM UserTable WHERE id=@id"; cmd.Parameters.Add("@id",Request["id"]); cmd.ExecuteReader(); • Okay: Escaping functions provided by language • Must always use right one, compose in right order • Okay: Casting to numerical data type

15. Bad Defense: Manual Blacklist • Check input for dangerous characters • Replace with harmless equivalents, or • Die without executing query • Hard to get right • Easy to forget unusual corner cases • Alternate character encodings • Escape handling may depend on db server software • May not match developer expectation • If server software changes, code is vulnerable

16. Bad Defense: Authentication • Developer says: “Only administrators can view the vulnerable page and the admin already has full database access. Therefore, SQL injection is not a problem.” • Is this exploitable? • Problem: Malicious content elsewhere can exploit site’s trust in the user to allow access to vulnerable page <img src="/admin/lookupuser.php?id='; UPDATE Person SET Password='x' WHERE username='admin">

17. Access Control ACL version CL Bell-La Padula Biba SetUID

18. Access Control Example • Alice can read and write the file x,read the file y, andan execute the file z • Bob can read x, read and write y, and cannot access z • Write a ACL and capability list

19. ACL • File x • Alice: read, write • Bob: read • File y • Alice: read • Bob: read, write • File z • Alice: execute

20. Capability list • Alice: • File x: read, write • File y: read • File z: execute • Bob: • File x: read • File y: read, write

21. Comparison • Q: Which access control mechanism is better at containing a Trojan horse virus? • Capability model allows capability owner to reduce capability inherited by process • Trojan horse process can be run without write access to file y (for example) • Can this stop all Trojans?

22. Bell-La Padula Model TOPSECRET > SECRET > CONFIDENTIAL A ≠ B ≠ C

23. Bell-La Padula Model TOPSECRET > SECRET > CONFIDENTIAL A ≠ B ≠ C

24. Bell-La Padula Model TOPSECRET > SECRET > CONFIDENTIAL A ≠ B ≠ C

25. Bell-La Padula Model TOPSECRET > SECRET > CONFIDENTIAL A ≠ B ≠ C

26. Bell-La Padula Model TOPSECRET > SECRET > CONFIDENTIAL A ≠ B ≠ C

27. Biba Policy • How would a virus spread if: • The virus were places in the system at system low (the compartment which all other compartments dominate) Could only infect lowest compartment • The virus were places in the system at system high (the compartment which dominates all other compartments) Could infect all other compartments

28. Effective user id (EUID) • Each process has three Ids (+ more under Linux) • Real user ID (RUID) • same as the user ID of parent (unless changed) • used to determine which user started the process • Effective user ID (EUID) • from set user ID bit on the file being executed, or sys call • determines the permissions for process • file access and port binding • Saved user ID (SUID) • So previous EUID can be restored • Real group ID, effective group ID, used similarly

29. Example Program B Owner 33 Program C Owner 18 SetUID RUID 25 EUID 25 SUID 25 User 25 RUID 25 EUID 18 SUID 25 …; …; i=getruid() setuid(i); …; …; …; fork( ); exec( ); RUID 25 EUID 25 SUID 18 If program C was owner 0 (root), could change ids to anything…

30. TPM Functions Keys

31. TPM Functions • Updating PCR • TPM_Extend(n,D): PCR[n]  SHA-1 ( PCR[n] || D ) • TPM_PcrRead(n): returns value(PCR(n)) • TPM_SaveState and TPM_Startup(ST_STATE) • Encrypted storage • TPM_TakeOwnership( OwnerPassword, … ) • TPM_CreateWrapKey • TPM_Seal(keyhandle, KeyAuth, PcrValues, data) • TPM_Unseal only when PCR matches blob PCR

32. TPM Functions • Attestation: TPM_Quote (some)Arguments: • keyhandle: which AIK key to sign with • KeyAuth: Password for using key `keyhandle’ • PCR List: Which PCRs to sign. • Challenge: 20-byte challenge from remote server • Prevents replay of old signatures. • Userdata: additional data to include in sig. • Returns signed data and signature.

33. TPM Keys • Data encrypted by TPM_Seal (usually AES key) • Only key not hidden inside TPM • Storage Root Key (SRK): certifies wrap keys • Created by TPM_TakeOwnership • Wrap keys: encrypts data with TPM_Seal • Created by TPM_CreateWrapKey • Attestation Identity Key (AIK) for use with TPM_Quote • Creation details “not important” • Endorsement key (EK) for endorsing AIK • Certificate issued once for TPM by vendor

35. Malware Example question

36. Example Question • The Earlybird worm signature generation system only finds worm signatures that consist of a consecutive sequence of characters. • Give an example of a vulnerability that a worm can exploit that cannot be detected using such signatures.

37. Follow up • Suppose Earlybird was able to generate signatures that contain wild cards (for example, "script/*.cgi"). • Give an example of a vulnerability that a worm can exploit that cannot be detected using such signatures.