Stopping Worm/Virus Attacks

1
Stopping Worm/Virus Attacks

• Chiu Wah So (Kelvin)

2
Worms

• Replicate worms over a computer network
• Perform malicious action
• Grow Exponentially
• Double in a few seconds to hours

3
Two Papers on stopping worms

• Potemkin Virtual Honeyfarm
• Scalability, fidelity, and containment in worm
  detection using honeypots.
• Vigilante
• End-to-end worm containment strategy, which
  includes worm detection, alert propagation, and
  local response.

4
Background on HoneyPot

• Definition
• An information system resource whose value lies
  in unauthorized or illicit use of that resource
• Carefully monitored and frequently left
  unprotected to detect and analyze intrusions
• Analyzed intrusions for
• Antivirus/worm signatures
• Disinfection algorithm
• Criminal investigation and persecution

5
Low-interaction honeypots

• Minimal interactions with the attackers (at most
  network layer interaction)
• Passively monitors inbound packets
• Simply transmits a SYN/ACK sequence to TCP SYN
• Advantage high scalability - up to millions
• Disadvantage low fidelity (Doesnt execute the
  kernel or application code)

6
High-interaction honeypots

• Execution environment identical or similar to a
  real host
• Advantage high fidelity
• Disadvantage low scalability (each system
  monitors one IP address)
• Can use VM to multiplex such that each machine
  can monitor more IP addresses

7
Containment Strategies

• Prevent compromised honeypots from attacking
  other machines
• Disallow outbound messages
• Problems with phone home to receive updates
• Forward outbound packets sent in response to
  inbound packets
• Problems with DNS query
• Result low fidelity (impossible to understand the
  native behavior of a malware)

8
Goal of Potemkin Virtual Honeyfarm

• To implement scalable high-interactive honeypots
  with
• High fidelity running common operating system
  and application software
• High scalability
• High containment

9
Observations High-interactive honeypots

• Most of a honeypots processor cycles are wasted
  idling (given IP address is rarely accessed)
• Most of a honeypots memory is idle
• Different honeypot servers in a honeyfarm
  replicate the same environment, and duplicate the
  effort.

10
Main Ideas

• Use gateway router
• Dynamically bind IP addresses to physical
  servers,
• Containment policies.
• Use Virtual Machine Monitor (Xen) create
  lightweight virtual machines
• Flash cloning (create VM from reference image)
• Delta virtualization (copy-on-write)

11
Architecture
12
Gateway Router

• Direct inbound traffic to individual honeyfarm
  servers
• Manage the containment of outbound traffic
• Implement long-term resource management
• Interface with detection, analysis and
  user-interface components

13
Gateway Router Inbound traffic

• Attracts traffic routing (BGP) and tunneling
• Sends IP packets for which there is no active VM
  to a non-overloaded honeyfarm server
• Type map illusion that a given IP address hosts
  a particular software configuration
• Assigns to the same VM if the same IP
• Scan filter reduces inbound traffic

14
Gateway Router Outbound traffic

• Containment Policies implemented on the gateway
• Track communication patterns
• Proxy standard outbound service
• Internal Reflection redirect the unsafe
  outbound packet back into honeyfarm
• Avoid resource starvation
• Avoid cross-containment

15
Cross Containment (1)

• Yellow contaminated by worm Wx
• Blue contaminated by worm Wy

16
Cross Containment (2)

• Yellow contaminated by worm Wx
• Blue contaminated by worm Wy
• Green contaminated by worm Wx and Wy

17
Cross Containment (3)

• Green contaminated by worm Wx and Wy

18
Solution for Cross Containment

• Each packet is extended with a universe
  identifier (src, dest, src port) that identifies
  a unique virtual IP address space
• New universe identifier is created for each
  transaction
• Packets can only forward to hosts within the same
  universe

19
Gateway Router Resource Allocation

• Reclaim uncompromised VM if it is not receiving
  inbound traffic
• Allow compromised VM to persist for further
  analysis
• When resource is low, prioritize VM

20
Virtual Machine Monitor

• Active IP addresses are an order of magnitude
  smaller
• Each server only uses small subset of hardware
• Therefore, VMs are created on request to
  multiplex a lot of machines
• One VM per IP address per universe

21
VMM Flash Cloning

• Reduces speed to instantiate a new clone

22
VMM Delta Virtualization

• Reduces memory overhead
• Shares VM pages and supports copy-on-write
  operation

23
Evaluation Question to address

• How many honeypot VMs are necessary?
• How many VMs can a machine spawn?
• How many connections can a gateway support?

24
Multiplexing Address Space

• /16 network
• VM aggressively recycled after 500 ms
• Average number of active VMs 58
• Peak 13614

25
Multiplexing Honeyfarm Servers
26
Statistics

• Delta Virtualization 128MB for 116 clones
• Flash Cloning 521.2ms to clone and 315.5ms to
  tear down
• CPU usage lt 0.01 for HTTP request
• Gateway traffic 160,000 packets / sec (hitting
  flow cache), 28,000 packets /sec (random traffic)
• Gateway Memory 256 bytes per flow

27
Limitations

• Attracting Attacks
• Tends to only receive traffic from randomly
  targeted attacks
• Honeypot Detection
• Detects honeypot and evades honeypot
• Denial-of-Service attack

28
Next Paper Vigilante

• What do we do after we detect a worm?
• Generate worm signatures by human.
• Too slow? Usually generating worm signatures by
  human takes days to weeks.
• And worm doubles in seconds to hours.
• Therefore, we need an end to end worm
  containment solution.

29
Vigilante

• An automatic end to end worm containment with
  negligible false positive rate
• Detection
• Propagation
• Response

30
Current Worm Containment Strategies

• Network level approach (doesnt have enough
  information, and has false positives)
• Host-based detection (not end-to-end solution)
• Host-based architecture (uses heuristic to
  correct the vulnerable service)

31
Vigilante architecture

• Use honeypot for worm detection, and generate
  self-certifying alert
• Propagate alert on overlay network
• Install filter in local host

32
Self-certifying alert

• Remove the trust between hosts
• Prove the existence of a vulnerability
• Can be verified inexpensively
• Automatically generate, verify, and distribute
  SCAs.

33
Alerts types

• Arbitrary Execution Control contains the address
  of a code to execute
• Arbitrary Code Execution contains the code to
  execute
• Arbitrary Function contains the value of
  argument of critical functions
• Format id of the vulnerable service, id of the
  alert type, verification information, and the
  messages

34
Worm detection

• Use Honeypots
• Two different worm detections engines
• Non-executable pages
• Non-execute protection on stack and heap to
  prevent code injection attack
• Dynamic dataflow analysis
• Data received from the network is dirty, and
  propagate the dirty bit whenever data is moved

35
Alert generation

• Log all the network messages for some threshold
  time
• When worm is detected, use all the network
  messages in the log to generate candidate SCAs.
• Run verification procedure for each candidate.
• If verification succeeds, generate SCA.

36
Alert Verification

• Verification is run in sandbox, virtual machine.
• Service is instrumented according to alert type
  with the verified function.

37
Properties of SCA Verification

• Fast Overhead of virtual machine is small
• Simple and generic
• No false positives
• Some drawbacks
• Doesnt describe the scheduling order for the
  threads

38
Alert Distribution

• Distribution must be fast, secure and reliable
• Use of secure Pastry overlay to broadcast
• To avoid DOS
• Dont forward already seen or blocked SCAs
• Only forward verifiable SCAs
• Limit rate of SCAs received on each neighbors
• Use super-peers they only have overlay code and
  VMs with vulnerability services for verification

39
Filter generation

• Use dataflow and control flow analysis to
  generate filter
• Use two filters general filters and specific
  filters to reduce false negatives

40
Evaluation

• Three real worms
• Slammer 75,000 MS SQL Servers infected, 8.5
  seconds to double
• CodeRed 360,000 MS IIS Servers infected, 37 mins
  to double
• Blaster 500,000 MS Windows infected, rate of
  growth similar to CodeRed

41
Alert generation and verification
42
Alert Distribution
43
Filter generation and CPU overhead
44
End-to-end experiments

• 5 host vigilante networks
• One detector, three super-peers for SCA
  distribution overlay, and one vulnerable host
• Results
• Slammers 79ms
• Blaster 305ms
• CodeRed 3044ms

45
Conclusion

• Is it possible to incorporate Potemkin Virtual
  Honeyfarm into the worm detection of Vigilante to
  make it a more scalable solution?
• Different aspects of worm containment
• Potemkin Virtual Honeyfarm talks about
  salability, fidelity, and containment of
  honeypots
• Vigilante is an end-to-end worm containment
  strategy