Rail is a system that uses record and replay techniques to precisely identify data items that were disclosed after a vulnerability is fixed in a web application. It records the execution of the application along with dependencies between actions and shared objects. During replay, it replays actions and compares the outputs to determine if any additional data items were disclosed. Rail provides APIs for developers to integrate object versioning and tracking of data sent to clients. An evaluation shows Rail can precisely identify disclosed data with low performance overhead and requiring few changes from developers.

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