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

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

Outline  Self-certifying alerts  Local countermeasures  Evaluation  Related work  Conclusion

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

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

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

Example

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

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

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)

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

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

Outline  Self-certifying alerts  Local countermeasures  Evaluation  Related work  Conclusion

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

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)

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

SCA Sizes

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

Alert Distribution (Network Simulation)

End-to-End Experiments  5 machines: 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

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