1. Networks Worms Research and Engineering Challenges Stefan Savage Department of Computer Science and Engineering University of California, San Diego Joint work (in part or full) with David Moore (UCSD/CAIDA), Colleen Shannon (CAIDA), Geoff Voelker (UCSD), Vern Paxson (ICIR/LBL), Stuart Staniford (Silicon Defense), Nick Weaver (UC Berkeley), Sumeet Singh (UCSD), Cristian Estan (UCSD), George Varghese (UCSD)

2. University California, San Diego – Department of Computer Science UCSD CSE What is a Network Worm? Self-propagating self-replicating network program –Exploits some vulnerability to infect remote machines No human intervention necessary –Infected machines continue propagating infection

3. University California, San Diego – Department of Computer Science UCSD CSE A Brief History… Brunner describes “tapeworm” program in novel “Shockwave Rider” (1972) [I’ve been told there is an earlier sci-fi reference] Shoch&Hupp co-opt idea; coin term “worm” (1982) –Key idea: programs that self-propagate through network to accomplish some task –Benign; didn’t replicate Fred Cohen demonstrates power and threat of self- replicating viruses (1984) Morris worm exploits buffer overflow vulnerabilities & infects a few thousand hosts (1988) Hiatus for 13 years…

4. University California, San Diego – Department of Computer Science UCSD CSE Recent Events CodeRed worm released in Summer 2001 –Exploited buffer overflow in IIS –Uniform random target selection (after fixed bug in CRv1) –Infects 360,000 hosts in 10 hours (CRv2) –Still going… Starts renaissance in worm development –CodeRed II –Nimda –Scalper, etc. Culminating in Sapphire/Slammer worm (Winter 2003)

5. University California, San Diego – Department of Computer Science UCSD CSE Inside the Sapphire/Slammer Worm Worm fit in a single UDP packet (404 bytes total) Code structure –Cleanup from buffer overflow –Get API pointers Code borrowed from published exploit –Create socket & packet –Seed PRNG with getTickCount() –While (TRUE) Increment PRNG –Mildly buggy Send packet to PRNG address Key insight: decouple scanning from target behavior (easy to adapt to TCP-based worms) Header Oflow API Socket Seed PRNG Sendto

6. University California, San Diego – Department of Computer Science UCSD CSE First ~1min behaves like classic random scanning worm –Doubling time of ~8.5 seconds –Code Red doubled every 40mins >1min worm starts to saturate access bandwidth –Some hosts issue >20,000 scans/sec –Self-interfering (no congestion control) Peaks at ~3min –55million IP scans/sec 90% of Internet scanned in <10mins Infected ~100k hosts (conservative due to PRNG errors) Sapphire growth

7. University California, San Diego – Department of Computer Science UCSD CSE Eye Candy

8. University California, San Diego – Department of Computer Science UCSD CSE Motivation (Gloom and Doom) Possibly controversial statement: worms are the most potent network security threat today –Many millions of susceptible hosts –Easy to write worms Worm payload separate from vulnerability exploit Significant code reuse in practice –Possible to cause major damage Lucky so far; existing worms have benign payload Wipe disk; flash bios; modify data; reveal data; Internet DoS We have no operational defense –Good evidence that humans don’t react fast enough –Defensive technology is nascent at best

9. University California, San Diego – Department of Computer Science UCSD CSE Agenda for today How to think about the worm problem Reactive defense –Containment: what we’re doing –Treatment: the next talk Proactive defense –Prevention: an appeal to the software research community

10. University California, San Diego – Department of Computer Science UCSD CSE Modeling network worms Network worms are well modeled as infectious epidemics –Simplest version: Homogeneous random contacts Classic SI model N: population size S(t): susceptible hosts at time t I(t): infected hosts at time t ß: contact rate i(t): I(t)/N, s(t): S(t)/N courtesy Paxson, Staniford, Weaver

11. University California, San Diego – Department of Computer Science UCSD CSE What’s important? How likely is it that an infection attempt is successful? –Target selection (random, biased, hitlist, etc) –Vulnerability distribution (e.g. density – S(0)/N) How frequently are infections attempted? –ß: Contact rate That’s it… with current technology death/recovery is irrelevant on timescales of interest

12. University California, San Diego – Department of Computer Science UCSD CSE What can be done? Reduce the number of infected hosts –Treatment, reduce I(t) while I(t) is still small Reduce the contact rate –Containment, reduce ß while I(t) is still small Reduce the number of susceptible hosts –Prevention, reduce S(0) Reactive Proactive

13. University California, San Diego – Department of Computer Science UCSD CSE Treatment Reduce # of infected hosts Disinfect infected hosts –Detect infection in real-time –Develop specialized “vaccine” in real-time (next talk) –Distribute “patch” more quickly than worm can spread Anti-worm? (CRClean written) Bandwidth interference…

14. University California, San Diego – Department of Computer Science UCSD CSE Containment Reduce contact rate Oblivious defense – Consume limited worm resources [Liston01] – Throttle traffic to slow spread [Williamson02] – Possibly important capability, but worm still spreads… Targeted defense – Detect and block worm [Moore et al 03]

15. University California, San Diego – Department of Computer Science UCSD CSE Design Issues for Reactive Defense [Moore et al 03] Any reactive defense is defined by: –Reaction time – how long to detect, propagate information, and activate response –Containment strategy – how malicious behavior is identified and stopped –Deployment scenario - who participates in the system We evaluate the requirements for these parameters to build any effective system.

16. University California, San Diego – Department of Computer Science UCSD CSE Methodology Simulate spread of worm across Internet topology: –infected hosts attempt to spread at a fixed rate (probes/sec) –target selection is uniformly random over IPv4 space Simulation of defense: –system detects infection within reaction time –subset of network nodes employ a containment strategy Evaluation metric: –% of vulnerable hosts infected in 24 hours –100 runs of each set of parameters (95 th percentile taken) Systems must plan for reasonable situations, not the average case Source data: –vulnerable hosts: 359,000 IP addresses of CodeRed v2 victims –Internet topology: AS routing topology derived from RouteViews

17. University California, San Diego – Department of Computer Science UCSD CSE Initial Approach: Universal Deployment Assume every host employs the containment strategy Two containment strategies we tested: –Address blacklisting: block traffic from malicious source IP addresses reaction time is relative to each infected host –Content filtering: block traffic based on signature of content reaction time is from first infection How quickly does each strategy need to react? How sensitive is reaction time to worm probe rate?

18. University California, San Diego – Department of Computer Science UCSD CSE To contain worms to 10% of vulnerable hosts after 24 hours of spreading at 10 probes/sec (CodeRed): –Address blacklisting: reaction time must be < 25 minutes. –Content filtering: reaction time must be < 3 hours How quickly does each strategy need to react? Address Blacklisting: Reaction time (minutes) % Infected (95 th perc.) Reaction time (hours) % Infected (95 th perc.) Content Filtering:

19. University California, San Diego – Department of Computer Science UCSD CSE Reaction times must be fast when probe rates get high: –10 probes/sec: reaction time must be < 3 hours –1000 probes/sec: reaction time must be < 2 minutes How sensitive is reaction time to worm probe rate? Content Filtering: probes/second reaction time

20. University California, San Diego – Department of Computer Science UCSD CSE Limited Network Deployment Depending on every host to implement containment is not feasible: –installation and administration costs –system communication overhead A more realistic scenario is limited deployment in the network: –Customer Network: firewall-like inbound filtering of traffic –ISP Network: traffic through border routers of large transit ISPs How effective are the deployment scenarios? How sensitive is reaction time to worm probe rate under limited network deployment?

21. University California, San Diego – Department of Computer Science UCSD CSE How effective are the deployment scenarios? % Infected at 24 hours (95 th perc.) Top 100 CodeRed-like Worm: 25%50%75% 100% Top 10Top 20Top 30Top 40 All

22. University California, San Diego – Department of Computer Science UCSD CSE How sensitive is reaction time to worm probe rate? Above 60 probes/sec, containment to 10% hosts within 24 hours is impossible even with instantaneous reaction. reaction time probes/second Top 100 ISPs

23. University California, San Diego – Department of Computer Science UCSD CSE Summary for reactive defense Reaction time: –required reaction times are a couple minutes or less (far less for BW-limited scanners) Containment strategy: –content filtering is more effective than address blacklisting Deployment scenarios: –need nearly all customer networks to provide containment –need at least top 40 ISPs provide containment We’re currently trying to build a system that could surpass these requirements (another talk)

24. University California, San Diego – Department of Computer Science UCSD CSE Proactive Defense: Prevention Reduce # of susceptible hosts Software quality: eliminate vulnerability –Static/dynamic testing [e.g. work of Cowan, Wagner, Engler, etc] –Software process, code review, etc… –Active research community –Traditional problems: soundness, completeness, usability Software updating: reduce window of vulnerability –Most worms exploit known vulnerability (10 days -> 3 months) –Relatively little activity; yet critical problem Software heterogeneity: reduce impact of vulnerability –Exploit existing heterogeneity [e.g. Junqueria’s Phoenix, HotOS 03] –Artificial heterogeneity [e.g. Forrest97]

25. University California, San Diego – Department of Computer Science UCSD CSE Artificial Heterogeneity: A Call to Arms for the Software Research Community Key idea: automatically give each instance of a program a unique implementation Low-level –Environment/Run-time heterogeneity Variable stack sizes, dynamic import tables –Representation heterogeneity Activation record format; randomize function prolog Register assignment, spilling order; Heap vs stack assignment –Control flow heterogeneity Re-order basic blocks Isomorphic CFGs High-level –Source-translation -> functional equivalents –Translation into design-level equivalents (its ok to have different semantics for property p if property p isn’t defined in interface spec)

26. University California, San Diego – Department of Computer Science UCSD CSE Why this is a good/dumb idea Yes but, –Simple code randomization was tried for buffer overflows and it didn’t help much –Software maintenance becomes more expensive –This is just code obfuscation and we know that doesn’t work Yes and, –This might also help debug programs and eliminate the use of undefined “quasi-invariants” –This is something the software community could do besides repeating the “write correct code” mantra –We’re desperate enough that it might be worth giving this some serious thought

27. University California, San Diego – Department of Computer Science UCSD CSE Summary Worms are a humongous potential problem There are a limited # of things you can do Reactive defense –Very challenging engineering requirements –But a number of us are having a shot at it Proactive defense –Some obvious things (better software, better patch distribution) –Large potential impact from attacking homogeneity –Open research question: can we programmatically create sufficient software diversity to provide protection?