CS176C, Spring 2006 Internet Epidemics

1
CS176C, Spring 2006Internet Epidemics

• Administrivia
• 2 weeks away from project due date!
• Short project presentation (5 minutes) on 6/8?
• Grading via demo/writeup w/ Krishna and I
• Today
• Internet worms
• Some slide content from Stefan Savage (UCSD)
• Detailed look at newest research on measurement
  of DoS attacks and worms
• Inferring DoS activity with Internet Telescopes
• Potemkin Honeyfarm

2
Changing Nature of Network Threats

• Traditional threats
• Attacker manually targets high-value system
• Defender increases cost to compromise
• Biggest threat insider attacker
• Modern threats
• Attacker uses automation to attack all systems
  at once (can filter later)
• Defender must defend all systems at once
• Biggest threats software vulnerabilities and
  naïve users

3
Large-scale Technical Enablers

• What makes the Internet so vulnerable to worms?
• Unrestricted connectivity
• Large-scale adoption of IP model for networks
  apps
• Software homogeneity user naiveté
• Single bug ? mass vulnerability in millions of
  hosts
• Trusting users ? mass vulnerability in millions
  of hosts
• Few meaningful defenses
• Effective anonymity (minimal risk to attacker)

4
Driving Economic Forces

• No longer just for fun, but for profit
• SPAM forwarding (MyDoom.A backdoor, SoBig),
  Credit Card theft (Korgo), DDoS extortion, etc
• Symbiotic relationships worms, bots, SPAM, etc
• Fluid third-party exchange market (millions
  hosts for sale)
• Going rate for SPAM proxying 3-10 cents/host/week
• Seems small, but 25K botnet gets you
  40k-130k/year
• Or rent your own botnet for short-term extortion
  scheme
• Economic cycle
• Bad guys have large incentive to get better

5
Simplified Worm Operation

• Small executable code segment targeting specific
  software vulnerability
• Windows XP NetBios
• MSFT IIS
• Operation
• Attack single host
• Install backdoor / perform local attack
• Fetch/compute new target IP addrs (target
  selection)
• Random generation
• Biased
• Hitlist
• Topological

6
What Can Be Done?

• Prevention reduce the number of susceptible
  hosts
• Software quality
• Software heterogeneity
• Software updating
• Hygiene enforcement
• Containment
• Reduce the contact rate (how fast it spreads)
• A more difficult problem

7
Prevention Software Quality

• Goal eliminate vulnerability
• Static/dynamic testing (compilers, analysis
  tools)
• Software process, code review, etc.
• Active research community
• Taken seriously in industry
• Security code review alone for Windows Server
  2003 200M
• Traditional problems soundness, completeness,
  usability
• Practical problems scale and cost

8
Prevention Software Heterogeneity

• Goal reduce impact of vulnerability
• Use software diversity to tolerate attack
• Exploit existing heterogeneity
• Junqueria et al, Surviving Internet Catastrophes,
  USENIX 05
• Create Artificial heterogeneity (hot topic)
• Forrest et al, Building Diverse Computer Systems,
  HotOS 97
• Large contemporary literature
• Open questions class of vulnerabilities that can
  be masked, strength of protection, cost of support

9
Prevention Software Updates

• Goal reduce window of vulnerability
• Most worms exploit known vulnerability (1 day -gt
  3 months)
• Window shrinking automated patch-gtexploit
• Patch deployment challenges, downtime, Q/A, etc
• Network-based filtering decouple patch from
  code
• E.g. TCP packet to port 1434 and gt 60 bytes
• Symantec Generic Exploit Blocking
• Automated patch creation fix vulnerability
  on-line
• Anti-worms block the vulnerability and propagate

10
Prevention Hygiene Enforcement

• Goal keep susceptible hosts off network
• Only let hosts connect to network if they are
  well-cared for
• Recently patched, up-to-date anti-virus, etc
• A similar technique is used at National Science
  Foundation (done by hand)
• Active probing of well-known vulnerabilities
• Used at campuses (UCB) for access control on
  WLANs
• Cisco Network Admission Control (NAC)
• Automate this using network filters and security
  software

11
The Alternative to Prevention

• Containment is key
• Understand worm infection and subsequent behavior
• Possible generation / distribution of patches
• Reactive patch generation / distribution
• Protection network, including worm detectors
• Detectors entice worms, generates
  signatures/patches, distributes to rest of
  network
• Understanding worm behavior and DoS via monitors
• Network telescopes
• HoneyNets / Honeypots

12
Network Telescopes

• Infected host scans for other vulnerable hosts by
  randomly generating IP addresses
• Network Telescope monitor large range of unused
  IP addresses will receive scans from infected
  host
• Very scalable. UCSD monitors 17M addresses

13
DoS Attacks

• We know theyre prevalent, but how prevalent?
• No one has any real data
• How do you measure the global impact of DoS
  attacks?
• Targets single hosts
• Fully distributed attacks
• Do we need global knowledge?
• Turns out you dont

Some slides courtesy of Geoff Voelker
14
Inferring DoS Activity

• Truly ingenious concept
• Moore/Voelker/Savage, Usenix Security 2001
• If you cant measure the attacks
  directly,observe the reactions (backscatter)
• Intuition
• Most attacks flooding style (ICMP, TCP SYN)
• Attackers spoof source IP randomly (true of all
  major tools)
• Victims respond to attacks w/ legit responses
• Unsolicited responses (backscatter) equally
  distributed across IP space

15
Backscatter
D
A
V
Attack
B
Backscatter
C
16
Measuring Backscatter

• Monitor block of n IP-addresses
• Gather cries for help from victims
• Expected of backscatter packets given an attack
  of m packets
• Estimate global-scale measurement
• Extrapolate gathered data back to scale of entire
  Internet

17
Telescopes Active Responders

• Problem Telescopes are passive, cant respond to
  TCP handshake
• Is a SYN from a host infected by CodeRed or
  Welchia? Dunno.
• What does the worm payload look like? Dunno.
• Solution proxy responder
• Stateless TCP SYNACK (Internet Motion Sensor),
  per-protocol responders (iSink)
• Stateful Honeyd
• Can differentiate and fingerprint payload
• False positives generally low since no regular
  traffic

18
HoneyNets

• Problem dont know what worm/virus would do? No
  code ever executes after all.
• Solution redirect scans to real infectable
  hosts (honeypots)
• Individual hosts or VM-based Collapsar,
  HoneyStat, Symantec
• Can reduce false positives/negatives with
  host-analysis (e.g. TaintCheck, Vigilante, Minos)
  and behavioral/procedural signatures
• Challenges
• Scalability
• Liability (honeywall)
• Isolation (2000 IP addrs ? 40 physical machines)
• Detection (VMWare detection code in the wild)

19
The Scalability / Fidelity Tradeoff
20
Potemkin Honeyfarm

• Goal
• High fidelity true OS/app behavior via VMM
• High scalability potentially up to 1000 IP
  addr/server
• Key insights
• Utilize light-weight VMMs
• Most honeypots sit idle, can do time-multiplexing
• Most honeypots have near-identical state
• Late binding of physical resources to external
  requests
• IP addr assigned to servers on demand from
  external traffic
• Light-weight VMM generated from reference
  image(flash cloning)
• New memory only allocated when diverging from
  reference (delta virtualization)

21
Remember Virtual Machines?

• Traditionally designed for resource isolation
• Protect user processes from each other at VM
  level
• Virtual machines for resource virtualization
• VMware, Xen, Virtual PC, UML
• Near-complete OS-level emulation running real
  apps
• Xen light-weight VMs through paravirtualization
• VM NOT 100 functionally equivalent to the
  hardware
• Guest OS is modified for tighter interface with
  VMM
• Net result
• Advantage Improved performance
• Disadvantage The hosted operating system must
  be modified before being hosted by Xen
• Supports up to 128 VMs scalably per physical
  host

22
The Xen VMM Architecture
23
Light-weight VMs in Potemkin

• Benefits of using VMs
• Protection crashes isolated to single VM
• Easy to manage, reduces server deployment cost
• Individual VMs can be loaded, frozen or stored on
  demand
• VM images can be copied and moved on-demand!
• Specialized network gateway and VMMs derived from
  Xen
• Each flow at the network layer dispatched to the
  honeyfarm
• Each server creates new VM for every flow, and
  emulates different IP for each flow

24
Architecture Overview
25
Worm Containment

• Cannot assist or accelerate worm attacks
• Most VMs quickly retire after an attack, since
  most attacks are unsuccessful
• If a VM is compromised, must make the right
  tradeoff between worm-freedom for observation,
  and potential damage to external hosts
• A number of approaches
• Deny all outgoing traffic
• Honeywall system outgoing only in response to
  incoming
• Proposed solution gateway router policy
• Centralized gateway with state
• Track communication patterns
• Scrub std. outbound service E.g. DNS requests
• Centralization simplifies mgt. policy
  specialization E.g. internal reflection

26
Reflection

• Challenges of reflection
• If N reflected requests go to X, do we
  instantiate one VM for X, or N VMs for each
• If N VMs, then worms isolated, no symbiotic
  behavior
• If one VM, then can potentially re-infect
  infected hosts with a second worm
• Solution
• Universe Identifier per incoming packet to
  identify a unique virtual IP address space
• Each new incoming transaction gets new UI
• Captures the causal relationships of
  communication
• Can designate mixing of universes explicitly to
  capture symbiotic behavior

27
Reflection and Cross Contamination
Wy
Wy
VM
X
Wx
Wx
Wy
Wx
Gateway
Wy
VM
Wy
Y
28
VMM Scalability Techniques

• Flash cloning
• New instance of VM necessary for isolation
• Gateway maintains map of which server maintains
  which OS/HW combinations
• Each server keeps local reference image of
  ready-to-run OS and application state
• New request ? instantiate new copy of reference
  image
• Delta virtualization
• Nearly all state identical to reference image
  (since only one reference type per server)
• Simply instantiate the same reference image, and
  only allocate memory when differs from reference
• Copy-on-write memory allocation
• Also used in other contexts for scalability