1. Vigilante: End-to-End Containment of Internet Worms M. 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 sandbox Load a library & binary rewrite critical functions (e.g., exec)

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: 1. Search messages for the address or the code of the faulting instruction 2. Use a single message as a candidate SCA 3. If this is not verified, add more messages until the log is empty 4. (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