Self-Stopping Worms

28
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

description

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. Worm Epidemic Aftermath. Belief: identifying infected hosts easy - PowerPoint PPT Presentation

Transcript of Self-Stopping Worms

Page 1: Self-Stopping Worms

Self-Stopping Worms

Justin Ma, Geoffrey M. Voelker, Stefan SavageCollaborative Center for Internet Epidemiology and Defenses (CCIED)

Department of Computer Science and EngineeringUniversity of California, San Diego

Page 2: Self-Stopping Worms

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

Page 3: Self-Stopping Worms

3

State of Affairs

Time

Vul

nera

ble

Hos

ts

Prelude Onset Aftermath

Prevention

Containment Treatment

100%

Zotob: 1 weekWitty: 1 day

Page 4: Self-Stopping Worms

4

State of Affairs• Opportunity to prevent/contain is short• Real-world responses focus on treatment

Time

Vul

nera

ble

Hos

ts

Prelude Onset Aftermath

Prevention

Containment

Treatment

100%

Slammer: 10 minutesStaniford et al.: a few seconds

Zotob: 1 weekWitty: 1 day

Page 5: Self-Stopping Worms

5

State of Affairs• Opportunity to prevent/contain is short• Real-world responses focus on treatment

Time

Vul

nera

ble

Hos

ts

Prelude Onset Aftermath

Prevention

Containment

Treatment

100%

From: [email protected]: [email protected]

Dear Hapless,

123.2.53.101 (hapless.ucsd.edu, 00:0f:ca:c0:e6:64, HAPLESS_WIN2K) appears tobe infected with a worm and is scanning external networks on port 445 inviolation 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 bereported to [email protected].

Sincerely,Academic Computing Services / Network Security

Page 6: Self-Stopping Worms

6

State of Affairs• Opportunity to prevent/contain is short• Real-world responses focus on treatment

Time

Vul

nera

ble

Hos

ts

Prelude Onset Aftermath

Prevention

Containment

Treatment

100%

Just need to know when all hosts infected

Why spew?

Page 7: Self-Stopping Worms

7

State of Affairs• Opportunity to prevent/contain is short• Real-world responses focus on treatment• Self-stop gives malware many advantages

Time

Vul

nera

ble

Hos

ts

Prelude Onset Aftermath

Prevention

Containment

Treatment

100%

Just need to know when all hosts infected

Self-stop

Page 8: Self-Stopping Worms

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

Page 9: Self-Stopping Worms

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

Page 10: Self-Stopping Worms

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)

Page 11: Self-Stopping Worms

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

Page 12: Self-Stopping Worms

12

Know-NI

Perfect knowledge lets worms stop on

a dime

Page 13: Self-Stopping Worms

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

Page 14: Self-Stopping Worms

14

Estimating I(t) from N

Only knowing N, worms can still stop

quickly

Page 15: Self-Stopping Worms

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)

Page 16: Self-Stopping Worms

16

Hits: 0 Scans: 1Hits: 0 Scans: 0Hits: 1 Scans: 2

Sum-Count• Estimate N through local estimation

Hits: 1 Scans: 3

33% hosts vulnerable

Page 17: Self-Stopping Worms

17

Sum-Count

More than 2x longer to stop… Local sampling alone

insufficient

Page 18: Self-Stopping Worms

18

Why Sum-Count Fails• Variance[Nest] 1 / Scans

• Many infected nodes too unlucky/new

• Reduce error by increasing scans without increasing scan rate

• Sum-Count-X– Aggregate samples (scans)– Opportunistic exchange– Distributed sampling by combining host estimates

Page 19: Self-Stopping Worms

19

Sum-Count-X• Collaborative estimation via

exchangeHits: 1 Scans: 3

Hits: 2 Scans: 3

Hits: 3 Scans: 6Hits: 3 Scans: 6

Hits: 1 Scans: 2Hits: 0 Scans: 1

Hits: 0 Scans: 1Hits: 1 Scans: 2Hits: 0 Scans: 0

Hits: 0 Scans: 0

+

50% hosts vulnerable

50% hosts vulnerable

+

Page 20: Self-Stopping Worms

20

Sum-Count-X

Similar result without perfect knowledge!

Page 21: Self-Stopping Worms

21

Why Sum-Count-X Succeeds

• Combines local estimation with exchange

• Leverages “experience” of older hosts

Page 22: Self-Stopping Worms

22

Summary• 20 simulation runs each

Speed (to 85%)

Duration

Strategy 50th 90th 50th 90thGreedy 117 135 - -Know-NI 119 139 161 181Know-N 121 147 154 154Sum-Count 159 189 448 482Sum-Count-X

119 136 174 199

Spreads quickly Stops quickly

Page 23: Self-Stopping Worms

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

Page 24: Self-Stopping Worms

24

Page 25: Self-Stopping Worms

25

More in Paper• Basic Heuristics

– From epidemic protocol literature• Dynamic Estimation with Bitmaps• Permutation Scanning• Scan Traffic

Page 26: Self-Stopping Worms

26

Infected Count

Page 27: Self-Stopping Worms

27

Sum-Count-Push

Page 28: Self-Stopping Worms

28

Nematodes• Aka “good worms”• Xerox PARC [Shoch and Hupp, 1980]• Prevent nematodes from spreading

out of control

• Utility not so convincing