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

Shimin ChenLBA 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 SCA3. If this is not verified, add more messages

until the log is empty4. (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: 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

Conclusion

Automatic worm containment is important

SCA enables cooperation across many hosts that do not trust each other