Stamping out worms and other Internet pests

1. Stamping out worms and other Internet pests Miguel Castro Microsoft Research

2. The challenge • worms are bad • worms can infect many machines • attacker gains control of infected machines • worm propagation disrupts Internet traffic • it is crucial to prevent these attacks • not a new challenge but no solution yet • the problem is as serious as ever Choffnes EECS, Northwestern University

3. Preventing worm infections • techniques to prevent bugs are important • type safe languages, static analysis, … • but unlikely to remove all bugs from services • need research on worm containment • worms spread too fast for human response • worm containment must be automatic Choffnes EECS, Northwestern University

4. Automatic worm containment • previous solutions are network centric • they analyze network traffic • block suspect packets • no vulnerability information at network level • false negatives: worm traffic appears normal • false positives: good traffic misclassified • fundamental problem false positives are a barrier to automation Choffnes EECS, Northwestern University

5. End-to-end worm containment • host-based cooperativedetection • detector runs instrumented software • analyzes infection attempt to generate an alert • distributes alert to other hosts • host-based protection • hosts analyze exploit described by alert • generate protection mechanism automatically • for example, a filter to block worm packets • first steps: Vigilante [Costa et al, SOSP 2005] Choffnes EECS, Northwestern University

6. Better host-based detectors • existing detectors are not sufficient • easily bypassed (e.g., stack canaries, NX) • high overhead (e.g., program shepherding) • poor coverage of some attack classes • better instrumentation to detect more worms • low false positives and false negatives • widely applicable (ideally to any binary) • low overhead (no alerts if negligible overhead) Choffnes EECS, Northwestern University

7. Better host-based protection • robust automatic protection • block all polymorphic variants of detected worms • no false positives • fast inoculation: • fast alert distribution, fast deployment of protection • efficient protection • provide good performance for legitimate requests • existing high coverage detectors are too expensive • recovery after detection is also expensive Choffnes EECS, Northwestern University

8. Better survivability • worm containment will not be perfect • must survive compromised hosts • without disruptions to critical services • without loss of critical data • better Byzantine fault tolerant replication • keep faults below threshold with high probability Choffnes EECS, Northwestern University

9. Conclusion • worms and viruses must be stopped • need more research to stop them • proposed a new research focus • requires research spanning • operating systems, networking, programming languages, and distributed systems Choffnes EECS, Northwestern University

10. Vigilante’s components • Detection • SCA generation • SCA distribution • SCA verification • Protection Choffnes EECS, Northwestern University

11. Outline • self-certifying alerts • detection and generation of self-certifying alerts • generation of vulnerability filters • evaluation • next steps Choffnes EECS, Northwestern University

12. Self-certifying alerts • identify an application vulnerability • describe how to exploit a vulnerability • contain a log of events, verification information • enable hosts to verify if they are vulnerable • hosts modify events to signal verification success • hosts replay events in sandboxed application • there are no false positives enable cooperative worm containment without trust Choffnes EECS, Northwestern University

13. SCA types • arbitrary execution control (AEC) • attacker can load a value in message into the PC • arbitrary code execution (ACE) • attacker can execute code in message • arbitrary function argument (AFA) • attacker can call function with arbitrary argument Choffnes EECS, Northwestern University

14. Verifying an AEC alert • SCA: • message log • verification information 0x44444444 ReceiveMessage() verified 0x111111111114444444411111 normal code vulnerable process proves that external interfaces allow arbitrary control of the execution Choffnes EECS, Northwestern University

15. SCA generation • log events • generate SCA when worm is detected • compute verification information • search log for relevant events • generate tentative version of SCA • repeat until verification succeeds • detectors may guide search • dynamic dataflow analysis is one such detector Choffnes EECS, Northwestern University

16. Dynamic dataflow analysis id 400 stack • high coverage and low false positive rate • allows direct extraction of verification information pointer return address return address stack buffer buffer id 100 id 400 id 400 msg msg id 100 id 100 ( a ) Memory before ( b ) Memory after vulnerable code vulnerable code Choffnes EECS, Northwestern University

17. Cooperative worm containment • SCA enables cooperative containment • any host can be a detector • hosts can run high-overhead detection engines • hosts can run different detection engines • NX, … • small TCB for SCA verification cooperation enables low false negative rate Choffnes EECS, Northwestern University

18. SCA broadcast • uses secure Pastry • hosts join overlay • detectors flood alerts over overlay links • denial-of-service prevention • per-link rate limiting • per-hop filtering and verification can reach vulnerable hosts with high probability Choffnes EECS, Northwestern University

19. Protection • hosts generate filter from SCA • dynamic data and control flow analysis • run vulnerable application in a sandbox • track control and data flow from input messages • compute conditions that determine execution path • filter blocks messages that satisfy conditions • filters can block polymorphic worms • no false positives by design Choffnes EECS, Northwestern University

20. Vulnerability filter generation mov al,[netbuf] mov cl,0x31 cmp al,cl jne out xor eax,eax loop: mov [esp+eax+4],cl mov cl,[eax+netbuf+1] inc eax test cl,cl jne loop out: netbuf 0x31 0x24 0x67 0x42 0x0 Conditions: netbuf[0] == 0x31 netbuf[1] != 0 netbuf[2] != 0 Choffnes EECS, Northwestern University

21. Evaluation • three real worms: • Slammer (SQL server), Blaster (RPC), CodeRed (IIS) • measurements of prototype implementation • SCA generation and verification • filter generation • filtering overhead • simulations of SCA propagation with attacks Choffnes EECS, Northwestern University

22. Time to generate SCAs Choffnes EECS, Northwestern University

23. Time to verify SCAs Choffnes EECS, Northwestern University

24. Time to generate filters Choffnes EECS, Northwestern University

25. Filtering overhead Choffnes EECS, Northwestern University

26. Containing Slammer Choffnes EECS, Northwestern University

27. Increasing infection rate ß is Slammer’s infection rate(the rate at which a host infects new hosts) Choffnes EECS, Northwestern University

28. Increasing verification time Choffnes EECS, Northwestern University

29. Increasing seed hosts Choffnes EECS, Northwestern University

30. Conclusion • Vigilante can contain worms automatically • requires no prior knowledge of vulnerabilities • no false positives • low false negatives Choffnes EECS, Northwestern University