Group meeting: Identifying Information Disclosure in Web Applications with Retroactive Auditing

Paper (OSDI '14): https://www.usenix.org/node/186211

Transcript

1. Identifying Information Disclosure in Web Applications with Retroactive Auditing Haogang Chen, Taesoo Kim, Xi Wang, Nickolai Zeldovich, and M. Frans Kaashoek MIT CSAIL Computer Systems Security Group Parallel & Distributed Operating Systems Group
2. Outline • Introduction • Related Work • Using Rail • System Overview • Replay • Evaluation • Conclusion
3. Introduction
5. What to do about it? • Before data breach: prevention techniques • privilege separation • encryption • information flow control • After data breach: damage control
6. Damage control is costly • Notify the victims • Data Breach Notification Laws (40/50 states) • Pay for credit monitoring & fraud protection
7. University of Maryland paid for 5 years of credit monitoring for 309,079 potentially affected users
8. Opportunity: Some data might not be leaked • The vulnerability might not have been exploited yet • Attackers might not steal all data that they can • Goal: precisely identify breached data items • Target damage control at real victims only
9. State of the art • Log all accesses to sensitive data • Inspect logs after an intrusion • Problems • Need to know what is sensitive data beforehand • Hard to tell legal vs. illegal accesses • May take a long time
10. Solution: Rail • Goal: precisely identify previously breached data after a vulnerability is fixed
11. Solution: Rail • Goal: precisely identify previously breached data after a vulnerability is fixed
12. Solution: Rail • Goal: precisely identify previously breached data after a vulnerability is fixed
13. Solution: Rail • Goal: precisely identify previously breached data after a vulnerability is fixed
14. Solution: Rail • Goal: precisely identify previously breached data after a vulnerability is fixed
15. Solution: Rail • Goal: precisely identify previously breached data after a vulnerability is fixed
16. Solution: Rail • Goal: precisely identify previously breached data after a vulnerability is fixed • Contribution: apply record and replay to identify improper disclosures • State during replay can diverge from the original execution • Prior systems use record and replay for integrity • Rail focuses on confidentiality • Provide APIs for application developers • For precision, Rail must match up state and minimize state divergence between the two executions
17. Related Work
18. Related Work • Focus on logging all accesses to confidential data • Keypad [EuroSys ’11], Pasture [OSDI ’12] • Information flow control and taint tracking • TaintDroid [OSDI ’10], TightLip [NSDI ’07] • Record and replay • MIT CSAIL (see next slide)
19. Undo Computing • Intrusion Recovery Using Selective Re-execution [OSDI ’10] • Intrusion Recovery for Database-backed Web Applications [SOSP ’11] • Efficient patch-based auditing for web application vulnerabilities [OSDI ’12] • Asynchronous intrusion recovery for interconnected web services [SOSP ’13] • Identifying information disclosure in web applications with retroactive auditing [OSDI ’14’]
20. Ideas • Action history graph and selective replay • Retro [OSDI ’10] • Comparison of normal execution and replay • Rad [APSys ’11], Poirot [OSDI ’12] • Prior replay systems were focused on restoring integrity
21. Using Rail
22. real world mistake Rail will reproduce the same date and random number from the context
23. Basic approach • Record and replay the web application • Compare the outputs of two executions
24. Basic approach • Record and replay the web application • Compare the outputs of two executions
25. Basic approach • Record and replay the web application • Compare the outputs of two executions
26. Basic approach • Record and replay the web application • Compare the outputs of two executions
27. System Overview
28. Assumptions • Focus on web applications • prototype is based on, but not limited to, Meteor • Trusts the software stack below the web application • Requests do not change during replay, except for fixes • Deal only with data leaked through the web application, and assume mistakes lead to disclosures
30. Action APIs • Actions are the unit of dependency tracking • event (RPC request) -> action -> handler • Each action has a timestamp
31. Object APIs • Developer must wrap all global objects in the app using Rail’s object API • Most wrappers can be done once in the framework
32. Object APIs • For each shared object, Rail maintains • A set of dependencies between actions and objects • Multiple versions of the object’s state at different points in time
34. Tracking data items in output • Rail maintains a view object for every session • tracks all data items sent to the client • During replay, Rail reruns actions and re-compute the view objects for every session • if old_view − new_view ≠ ∅ ➜ Breach!
35. AHG: action history graph
36. Logs and dependency graph • Rail assumes that actions are atomic • the web framework provides serializability • Rail stores AHG in a persistent log • Objects that do not store actual state (i.e. just a placeholder) in the Rail’s shared object must maintain their own versioning outside of Rail’s log • time-travel database [SOSP ’11]
37. Replay
38. Selective re-execution • Inspired by Retro [OSDI ’10] • Rail replays each action sequentially in the time order • Replays an action if any of its inputs or outputs are changed • Replay is guaranteed to terminate
39. monotonically increase due to rollback, input changed => rerun reconstruct output patched code, args optimization for future actions consider Cin rollback to “right before”
40. Context matching • application stability: assign context identifiers
41. Evaluation
42. Developer effort • Most of the changes are related to non-deterministic inputs • Framework wrappers (422 lines in Meteor) offload most burdens from the application developer
43. Benchmarks
44. Auditing precision
45. Technique effectiveness Changed code is on the critical path of all login requests
46. Performance and overhead • Performance • 5% for an under-loaded server • 22% for an over-loaded server • Storage • ~ 0.5KB / request
47. Conclusion • Rail can precisely identify breached data items after a disclosure in web applications • Provide developers with APIs that help to identify data items, track dependencies, and match up states • Requires few changes to applications • Precise, efficient, and practical