1 / 38

Final Review Session

Spring 2006. CS 155. Final Review Session. Collin Jackson. 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:

oliver
Download Presentation

Final Review Session

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

  34. Malware Example question

  35. 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.

  36. 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.

More Related