Vigilante: - PowerPoint Presentation

Slide1

Vigilante: End-to-End Containment of Internet Worms

Manuel Costa, Jon Crowcroft, Miguel Castro, Antony Rowstron, Lidong Zhou, Lintao Zhang and Paul BarhamSOSP 2005

Presented by Elias P. Papadopoulos

1Slide2

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 minutes2Slide3

Worm Containment

Analyze network traffic

Generate signatures and block matching trafficBlock hosts with abnormal behaviorNetwork-level techniques have not information about the vulnerablities exploited3Slide4

Vigilante’s Architecture

Host-based detection- Instrument software to analyze infection attempts

Cooperative detection without trust- Detectors generate self-certifying alerts (SCA)- Detectors broadcast SCAsVulnerable hosts generate filters to block infectionContains fast spreading worms: no false positives, deployable today4Slide5

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 informationEnable hosts to replay the infectionVerification has no false positives5Slide6

Vigilante’s Architecture

6Slide7

Alert Types 1/2

Arbitrary Execution Control (AEC) - Identify vulnerabilities that allow worms to redirect execution to arbitrary existing code in a service’s address space

Arbitrary Code Execution (ACE)- Code-injection vulnerability- Specifies how to execute an arbitrary piece of code supplied in a message7Slide8

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 message8Slide9

SCA Example

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

9Slide10

Alert Verification

Properties:

FastSimple and genericNo false positives

sandbox

10Slide11

Alert Generation

Log messagesRemove old messages and messages in generated SCAs

If the engine detects an infection attempt, search the log and generate candidate SCAsSCAs that get verified are distributed to the vulnerable hostsTwo Detection Engines: 1. Non-executable pages 2. Dynamic DataFlow Analysis11Slide12

Non-Executable Pages

Use NX protection on stack and heap pages to detect code-injection attacksSearch messages for the address or the code that caused the exception

Use a message as SCAKeep adding messages until the SCA is verified12Slide13

Dynamic Dataflow Analysis

Track the flow of data received in certain newtwork/input operations

This data is marked dirtyIf dirty data is about to be loaded into the program counter, signal an attempt for Arbitrary Execution Control13Slide14

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 alert14Slide15

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 membership15Slide16

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 vulnerability16Slide17

EvaluationThree

real worms: - Slammer (SQL server) ~ 75.000 infected - Blaster (RPC service) ~ 500.000 infected - CodeRed (IIS server) ~ 360.000 infected

Measurements of prototype implementation - SCA generation and verification - filter generation - filtering overheadSimulations of SCA propagation with attacks17Slide18

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.18Slide19

SCA Sizes

Size of SCAs is

smalland mostly determined by the size of the worm probe messages19Slide20

SCA Verification Time

Verification time when VM is already running 

Is fastThe verification VM has low overhead (<1% CPU)20Slide21

Filter Generation Time

Filter generation for CodeRed is more

expensive, because of the number of instructions analyzed is larger21Slide22

Worm Containment

Simulation - Infective epidemic model - Total

population of 500.000 hosts - S of the hosts are vulnerable to the attack - A fraction p of the S hosts are detectorsDoS attacks - Infected hosts generate fake SCAs - Verification increases linearly with number of SCAs22Slide23

Worm Containment

S = 75.000 S = 360.000 S

= 500.00023Slide24

Filter Overhead

24Slide25

End-to-End Experiment

Five Machines (1-2-3-4-5) - 1 is the detector - 2,3,4 are intermediate overlay nodes

- 5 is the vulnerable hostSCA has to reach vulnerable host number 5Time from worm probe reaching 1 till 5 verifies the SCA- Slamer: 79ms- Blaster: 305ms- CodeRed: 3044ms25Slide26

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 other26