Vigilante: End-to-End Containment of Internet Worms Manuel Costa, Jon Crowcroft, Miguel Castro, Antony Rowstron, Lidong Zhou, Lintao Zhang and Paul Barham SOSP 2005 Presented by Elias P. Papadopoulos 1

Worm Standalone malware that replicates itself in order to spread to other computers Spread too fast for humans to respond - Slammer worm infected 90% of vulnerable hosts in only 10 minutes 2

Worm Containment Analyze network traffic Generate signatures and block matching traffic Block hosts with abnormal behavior Network-level techniques have not information about the vulnerablities exploited 3

Vigilante’s Architecture Host-based detection - Instrument software to analyze infection attempts Cooperative detection without trust - Detectors generate self-certifying alerts (SCA) - Detectors broadcast SCAs Vulnerable hosts generate filters to block infection Contains fast spreading worms: no false positives, deployable today 4

Self Certifying Alerts ●Verifiable proofs of vulnerability - Identify the application and a type of vulnerability - Contain the exact steps to compromise the host - Contain verification information ●Enable hosts to replay the infection ●Verification has no false positives 5

Vigilante’s Architecture 6

Alert Types 1/2 1.Arbitrary Execution Control (AEC) - Identify vulnerabilities that allow worms to redirect execution to arbitrary existing code in a service’s address space 2.Arbitrary Code Execution (ACE) - Code-injection vulnerability - Specifies how to execute an arbitrary piece of code supplied in a message 7

Alert Types 2/2 3. Arbitrary Function Argument (AFA) - Identify data-injection vulnerability - Specifies how to invoke a specific critical function with an argument supplied in a message 8

SCA Example Address of code to execute is contained at this offset within the message 9

Alert Verification Properties:  Fast  Simple and generic  No false positives sandbox 10

Alert Generation Log messages Remove old messages and messages in generated SCAs If the engine detects an infection attempt, search the log and generate candidate SCAs SCAs that get verified are distributed to the vulnerable hosts Two Detection Engines: 1. Non-executable pages 2. Dynamic DataFlow Analysis 11

Non-Executable Pages Use NX protection on stack and heap pages to detect code-injection attacks Search messages for the address or the code that caused the exception Use a message as SCA Keep adding messages until the SCA is verified 12

Dynamic Dataflow Analysis Track the flow of data received in certain newtwork/input operations This data is marked dirty If dirty data is about to be loaded into the program counter, signal an attempt for Arbitrary Execution Control 13

Dynamic Dataflow Analysis If dirty data is about to be executed, signal an attempt for Arbitrary Code Execution If an argument to a critical function is dirty signal an Arbitrary Function Argument alert 14

Alert Distribution Pastry overlay to broadcast SCAs - Detectors flood SCAs over overlay links DoS Protection - Per-link rate limits - Per-hop filtering and verification - Controlled disclosure of overlay membership 15

Automatic Filter Generation Generate filters by analyzing the execution path followed when the messages in the SCA are replayed Apply dynamic data and control flow analysis to determine the execution path that exploits the vulnerability 16

Evaluation Three real worms: - Slammer (SQL server) ~ infected - Blaster (RPC service) ~ infected - CodeRed (IIS server) ~ infected Measurements of prototype implementation - SCA generation and verification - filter generation - filtering overhead Simulations of SCA propagation with attacks 17

SCA Generation Time - The Number of instructions executed in CodeRed is larger and the engine has to dynamically translate a number of libraries loaded during the worm attack - Detectors generate arbitrary execution control alert for Slammer and Blaster and arbitrary code execution alert for CodeRed. - Both detectors generate SCAs fast. - NX detector performs best: Instrumentation is less intrusive and less general. 18

SCA Sizes Size of SCAs is small and mostly determined by the size of the worm probe messages 19

SCA Verification Time Verification time when VM is already running  Is fast The verification VM has low overhead (<1% CPU) 20

Filter Generation Time Filter generation for CodeRed is more expensive, because of the number of instructions analyzed is larger 21

Worm Containment Simulation - Infective epidemic model - Total population of hosts - S of the hosts are vulnerable to the attack - A fraction p of the S hosts are detectors DoS attacks - Infected hosts generate fake SCAs - Verification increases linearly with number of SCAs 22

Worm Containment S = S = S =

Filter Overhead 24

End-to-End Experiment Five Machines ( ) - 1 is the detector - 2,3,4 are intermediate overlay nodes - 5 is the vulnerable host SCA has to reach vulnerable host number 5 Time from worm probe reaching 1 till 5 verifies the SCA -Slamer: 79ms -Blaster: 305ms -CodeRed: 3044ms 25

Conclusion Analyzing network traffic is not fast or accurate enough to contain a worm attack Vigilante can contain worms automatically - Requires no prior knowledge of vulnerabilities - Fast - No false positives - Low False negatives -SCA enables cooperation across hosts that do not trust each other 26