Networks Worms Research and Engineering Challenges Stefan Savage Department of Computer Science and Engineering University of California, San Diego Joint.

Networks Worms

Research and Engineering Challenges

Stefan SavageDepartment of Computer Science and Engineering

University of California, San Diego

Joint work (in part or full) withDavid 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)

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


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…


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)


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 targetbehavior (easy to adapt to TCP-based worms)

Header

Oflow

API

Socket

Seed

PRNG

Sendto


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 saturateaccess 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


UCSD CSE

Eye Candy


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


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


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

N

IS

dt

dSN

IS

dt

dI

)1( ii

dt

di

)(

)(

1)(

Tt

Tt

e

eti

courtesy Paxson, Staniford, Weaver


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


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


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…


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]


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.


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 (95th 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


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?


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 eachstrategy need to react?

Address Blacklisting:

Reaction time (minutes)

% I

nfec

ted

(95th

per

c.)

Reaction time (hours)

% I

nfec

ted

(95th

per

c.)

Content Filtering:


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 timeto worm probe rate?

Content Filtering:

probes/second

reac

tion

time


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?


UCSD CSE

How effective are the deployment scenarios?

% I

nfec

ted

at 2

4 ho

urs

(95th

per

c.)

Top

100

CodeRed-like Worm:

25%

50%

75%

100%

Top

10To

p 20

Top

30To

p 40 All


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.

reac

tion

time

probes/second

Top 100 ISPs


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)


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]


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)


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


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?

Networks Worms Research and Engineering Challenges Stefan Savage Department of Computer Science and Engineering University of California, San Diego Joint.

Documents

network worm

infectionuniversity

forrest97university

yearsuniversity california

40mins1min worm

sapphireslammer worm

idea coin term worm

san diegojoint work