Vigilante EndtoEnd Containment of Internet Worms Manuel Costa

Vigilante: End-to-End Containment of Internet Worms Manuel Costa, Jon Crowcroft, Miguel Castro, Antony Rowstron, Lidong Zhou, Lintao Zhang, Paul Barham Presented by Mahesh Balakrishnan

Worms l The Morris Worm… 1988 l l l l Zotob – Aug 2005, Windows Plug-and-Play Sasser – May 2004, Windows LSASS Mydoom – Jan 2004, email So. Big, Aug 2003, email Blaster – Aug 2003, Windows RPC Slammer – Jan 2003, SQL Nimda – Sep 2001, email + IE Code. Red – July 2001, IIS

The Anatomy of a Worm l Replicate, replicate, replicate… exponential growth l Exploit Vulnerability in Network-facing Software l Worm Defense involves Detection – of what? l Response l

Existing Work l Network l Level Approaches … Polymorphic? Slow worms? l Host-based Approaches: Instrument code extensively. Slow (? )… l Do it elsewhere: Honeypots… honeyfarms l Worm Defense now has three components: Detection, Propagation, Response

Vigilante l Automates worm defense l ‘Collaborative Infrastructure’ to detect worms l Required: Negligible rate of false positives l Network-level approaches do not have access to vulnerability specifics

Solution Overview Run heavily instrumented versions of software on honeypot or detector machines l Broadcast exploit descriptions to regular machines l Generate message filters at regular machines to block worm traffic l Requires separate detection infrastructure for each particular service: is this a problem? l

SCA: Self-Certifying Alert l Allows exploits to be described, shipped, and reproduced l Self-Certifying: to verify authenticity, just execute within sandbox l Expressiveness: Concise or Inadequate? l Worms defined as ‘exploiters of vulnerability’ rather than ‘generators of traffic’

Types of Vulnerabilities Arbitrary Execution Control: message contains address of code to execute l Arbitrary Code Execution: message contains code to execute l Arbitrary Function Argument: changing arguments to ‘critical’ functions. e. g exec l Is this list comprehensive? l l l C/C++ based vulnerabilities… what about email-based worms – So. Big, Mydoom, Nimda?

Example SCA: Slammer Address of code to execute is contained at this offset within message Execution Control SCA

Alert Generation l Many existing approaches l Non-executable pages: faster, does not catch function argument exploit l Dynamic Data-flow Analysis: track dirty data l Basic Idea: Do not allow incoming messages to execute or cause arbitrary execution

Alert Verification l Hosts run same software with identical configuration within sandbox l Insert call to Verified instead of: Address in execution control alerts l Code in code execution alerts l l Insert a reference argument value instead of argument in arbitrary function argument alert

Alert Verification is fast, simple and generic, and has no false positives l Assumes that address/code/argument is supplied verbatim in messages l l l Works for C/C++ buffer overflows, but what about more complex interactions within the service? Assumes that message replay is sufficient for exploit reproduction l l Scheduling policies, etc? Randomization?

Alert Distribution l Flooding over secure Pastry overlay l What about DOS? Don’t forward already seen or blocked SCAs l Forward only after Verification l Rate-limit SCAs from each neighbor l l Secure l Pastry? Infrastructural solution… super-peers

Distribution – out-crawling the worm l l l Worm has scanning inefficiencies; Slammer doubled every 8. 5 seconds. The myth of the anti-worm… We have perfect topology: around the world in seconds! What if the worm discovers our topology? Infrastructural support required – wormresistant super-peers! Is this sterile medium of transport deployable?

Local Response l Verify SCA l Data and Control Flow Analysis l Generate filters – conjunctions of conditions on single messages l Two levels : general filter with false positives + specific filter with no false positives

Evaluation l Target l Slammer – 75, 000 SQL servers, 8. 5 seconds to double l l Execution Control Alert Code Red – 360, 000 IIS servers, 37 minutes to double l l Worms Code Execution Alert Blaster – 500, 000 Windows boxes, doubling time similar to Code. Red l Execution Control Alert

Evaluation: Alert Generation SCA Generation Time SCA Sizes

Evaluation: Alert Verification l Verification is fast - Sandbox VM constantly running … Verification Time Filter Generation

Simulation Setup l Transit Stub Topology: 500, 000 hosts l Worm propagation using epidemic model l 1000 super-peers that are neither detectors nor susceptible! l Includes modeling of worm-induced congestion

Number of Detectors… l ~0. 001 detectors sufficient… 500 nodes

Real Numbers l 5 -host network: 1 detector + 3 superpeers + 1 susceptible on a LAN l Time between detector probe to SCA verification on susceptible host: Slammer: 79 ms l Blaster: 305 ms l Code. Red: 3044 ms l

The Worm Turns l Outwitting Vigilante One interesting idea, courtesy Saikat: Detect instrumented honeypots via timing differences. Does this work? l Layered exploits: one for the super-peer topology, another for the hosts l Ideas? l

Conclusion l End-to-end solution for stopping worms l Pros: No false positives l Per-vulnerability reaction, not per-variant: handles polymorphism, slow worms l l Concerns: Limited to C/C++ buffer overflow worms l Infrastructural solution – scope of deployment? l