Vigilante: End-to-End Containment of Internet Worms M. Costa et al. (MSR) SOSP 2005

1. Vigilante: End-to-End Containment of Internet WormsM. Costa et al. (MSR) SOSP 2005 Shimin Chen LBA Reading Group

2. Overview: Automatic Worm Containment • Vigilante: a person who ignores due process of law and enacts his or her own form of justice when they deem the response of the authorities to be insufficient. • Self-certifying alert (SCA): machine-verifiable proof of a vulnerability Can be honeypot

3. Outline • Self-certifying alerts • Local countermeasures • Evaluation • Related work • Conclusion

4. What is an SCA? • A sequence of messages, when received by the vulnerable service, cause it to reach a disallowed state • Verification: send messages + check • Detection: message logging + detector

5. SCA Types • Arbitrary Execution Control • Jump to arbitrary existing code in a service’s address space • Specifies how to jump to an address supplied in a message • Arbitrary Code Execution • Code-injection vulnerability • Specifies how to execute an arbitrary piece of code supplied in a message • Arbitrary Function Argument • Data-injection vulnerability • Specifies how to invoke a specific critical function with an argument supplied by a message

6. SCA Format: • Vulnerable service • Alert type • Verification information: • Where in the message to put the supplied address/code/function argument • Sequence of messages

7. Example

8. Alert Verification Load a library& binary rewrite critical functions (e.g., exec) sandbox

9. Alert Generation • Log message and network endpoints • Remove old messages (e.g., an hour old) • Remove messages in generated SCAs • Log is small in a honeypot system • Any detection methods: (in this paper) • Non-executable pages • Dynamic dataflow analysis • Upon detection, search the log to generate candidate SCAs and verify them

10. Non-executable pages • Low overhead • Upon catching an exception: • Search messages for the address or the code of the faulting instruction • Use a single message as a candidate SCA • If this is not verified, add more messages until the log is empty • (On a honeypot, at step 3, add the entire log if the log is less than 5 messages long)

11. Dynamic dataflow analysis • A flavor of taintcheck • Metadata: • One bit per 4K page: if a page is entirely clean • For dirty pages, keep one identifier per memory location: • Identifier: an integer – represents the input message and message offset • A separate list mapping identifiers to messages • Propagate for only data movement instructions: MOV, MOVS, PUSH, POP

12. Alert Distribution • Assume some kind of secure overlay • Flooding: each host sends the SCA to all its overlay neighbors • Problems discussed in paper • Compromised hosts may flood the overlay with bad/old SCAs • Must prevent worms to use the overlay for propagation

13. Outline • Self-certifying alerts • Local countermeasures • Evaluation • Related work • Conclusion

14. Automatic filter generation • Basically, Bouncer is the improvement of the proposal here.

15. Evaluation • Prototype: x86 + Windows • Dell Precision workstations with 3GHz Pentium 4, 2GB RAM, 100Mbps Ethernet • Real worms: • Slammer: MS SQL Server • CodeRed: MS IIS Server • Blaster: RPC service (2 message attack)

16. Alert Generation • The moment the last worm message is received till the detector generates an SCA • No verification • Only worm messages in the log

17. SCA Sizes

18. Alert Verification • Verification time when VM is already running • The verification VM has low overhead normally: • Less than 1% of CPU cost • About 84 MB memory

19. Alert Distribution (Network Simulation)

21. End-to-End Experiments • 5 machines: • 1-2-3-4-5 • 1 is the detector • 5 is the vulnerable host • 2,3,4 are intermediate overlay nodes • Time from worm probe reaching 1 till 5 verifies SCA • Slammer: 79ms • Blaster: 305ms • CodeRed: 3044ms

22. Conclusion • Automatic worm containment is important • SCA enables cooperation across many hosts that do not trust each other