Self-Stopping Worms

1. Self-Stopping Worms Justin Ma, Geoffrey M. Voelker, Stefan Savage Collaborative Center for Internet Epidemiology and Defenses (CCIED) Department of Computer Science and Engineering University of California, San Diego

2. Worm Epidemic Aftermath • Belief: identifying infected hosts easy • Expectation: infection activity continues long after the fact • Self-stopping worms can evade existing worm treatment techniques

3. State of Affairs Zotob: 1 week Witty: 1 day

4. State of Affairs • Opportunity to prevent/contain is short • Real-world responses focus on treatment Zotob: 1 week Witty: 1 day Slammer: 10 minutes Staniford et al.: a few seconds

5. State of Affairs From: acs@ucsd.edu To: hapless@ucsd.edu Dear Hapless, 123.2.53.101 (hapless.ucsd.edu, 00:0f:ca:c0:e6:64, HAPLESS_WIN2K) appears to be infected with a worm and is scanning external networks on port 445 in violation of University policy. The machine has been blocked at the campus border until it can be cleaned up, secured, and made fully compliant with the Minimum Network Security Standards (see http://www-no.ucsd.edu/security/minstds/index.html ). Pursuant to UCSD policy concerning compliance with California State Bill 1386 (http://www-act.ucsd.edu/actonly/security/privatedataprocedures.pdf), if "personal identity information" exists on this machine, that fact must be reported to ucsd-cirt@ucsd.edu. Sincerely, Academic Computing Services / Network Security • Opportunity to prevent/contain is short • Real-world responses focus on treatment

6. State of Affairs • Opportunity to prevent/contain is short • Real-world responses focus on treatment Why spew? Just need to know when all hosts infected ?

7. State of Affairs • Opportunity to prevent/contain is short • Real-world responses focus on treatment • Self-stopgives malware many advantages Just need to know when all hosts infected ! Self-stop

8. Difficulty of Self-Stop • How hard with random scanning worms? • Gossip-style communication • Opportunistic contact • Conform to probe traffic pattern • Without a priori knowledge • E.g., no need to know vulnerability density • Perform as well as strategies with a priori knowledge

9. Self-Stopping Worm Design • Primary Goal:stop after infecting x% vulnerables • Infect as many as possible • Accuracy:ability to meet Primary Goal • At least >= 85% vulnerables • Speed:time to reach x% vulnerables • Spread as quickly as possible (beat containment) • Duration:time until last host deactivates • Stop as quickly as possible (minimize containment window) • Scan traffic • Not focusing on stealthy (tradeoff w/ speed/duration) • Ease of implementation/parameterization • Piggy-back over uniform random scanning • No a priori knowledge of vulnerable population

10. Dynamic Estimation • Do individual nodes need a priori knowledge? • Size of vulnerable population N • Infected count over time I(t) • Worm has an oracle • Know N and I (stop when I(t)/N reaches goal) • Increasingly practical • Know N (locally estimate I(t) knowing N) • Sum-Count (locally estimate N) • Sum-Count-X (collaborate to estimate N)

11. Simulation Methodology • Modify random scanning worms • 32-bit address space • 130,000 vulnerables (we tried other values too) • Each host, 4000 scans per timestep • Slammer: >= 75,000 vulnerable, ~4000 scans/s • [Moore et al., “Inside the Slammer Worm”, 2003] • Universal reachability • No network latency or congestion • Start w/ one infected host • Scan in rounds

12. Know-NI Perfect knowledge lets worms stop on a dime

13. Estimating I(t) from N • Directly observing I(t) is difficult • Restricted to only knowing N? • Observe through netcraft.com, port scanning • I(t) = f(N, r, t) • Based on analytic model for epidemics • r is per-host scan rate • See paper for details

14. Estimating I(t) from N Only knowing N, worms can still stop quickly

15. Local Estimation • Estimate N on-the-fly • General-purpose self-stop • No need to gather a priori intelligence • Scanning = Sampling w/ Replacement • Hits on Vulnerables = Successes • Total Scans = Trials • Nest = 232 * (Hits / Scans)

16. Sum-Count • Estimate N through local estimation Hits: 0 Scans: 1 Hits: 0 Scans: 0 Hits: 1 Scans: 2 Hits: 1 Scans: 3 33% hosts vulnerable

17. Sum-Count More than 2x longer to stop… Local sampling alone insufficient

18. Why Sum-Count Fails • Variance[Nest] µ 1 / Scans • Many infected nodes too unlucky/new • Reduce error by increasing scans withoutincreasing scan rate • Sum-Count-X • Aggregate samples (scans) • Opportunistic exchange • Distributed samplingby combining host estimates

19. Sum-Count-X • Collaborative estimation via exchange Hits: 1 Scans: 3 Hits: 0 Scans: 1 Hits: 1 Scans: 2 Hits: 0 Scans: 0 50% hosts vulnerable Hits: 3 Scans: 6 Hits: 3 Scans: 6 + + 50% hosts vulnerable Hits: 2 Scans: 3 Hits: 1 Scans: 2 Hits: 0 Scans: 1 Hits: 0 Scans: 0

20. Sum-Count-X Similar result without perfect knowledge!

21. Why Sum-Count-X Succeeds • Combines local estimation with exchange • Leverages “experience” of older hosts

22. Summary • 20 simulation runs each Spreads quickly Stops quickly

23. Conclusions • Self-stopping worms • Easy to write • Advance knowledge of vulnerable host population is unnecessary to be successful • Sum-Count-X demonstrates these points • Implications for future defenses • Cannot depend on simple identification • Need new ways to identify/treat • If those fail, containment is even more critical

25. More in Paper • Basic Heuristics • From epidemic protocol literature • Dynamic Estimation with Bitmaps • Permutation Scanning • Scan Traffic

26. Infected Count

27. Sum-Count-Push

28. Nematodes • Aka “good worms” • Xerox PARC [Shoch and Hupp, 1980] • Prevent nematodes from spreading out of control • Utility not so convincing