Stopping Worm/Virus Attacks

Chiu Wah So (Kelvin)

Worms

Replicate worms over a computer network Perform malicious action Grow Exponentially

– Double in a few seconds to hours

Two Papers on stopping worms

Potemkin Virtual Honeyfarm:– Scalability, fidelity, and containment in worm dete

ction using honeypots. Vigilante:

– End-to-end worm containment strategy, which includes worm detection, alert propagation, and local response.

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

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 (Doesn’t execute

the kernel or application code)

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

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)

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

Observations High-interactive honeypots

Most of a honeypot’s processor cycles are wasted idling (given IP address is rarely accessed)

Most of a honeypot’s memory is idle Different honeypot servers in a honeyfarm re

plicate the same environment, and duplicate the effort.

Main Ideas

Use gateway router– Dynamically bind IP addresses to physical server

s, – Containment policies.

Use Virtual Machine Monitor (Xen) create lightweight virtual machines– Flash cloning (create VM from reference image)– Delta virtualization (copy-on-write)

Architecture

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

erface components

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

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

Cross Containment (1)

Yellow = contaminated by worm Wx Blue = contaminated by worm Wy

Cross Containment (2)

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

Cross Containment (3)

Green = contaminated by worm Wx and Wy

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

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

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

VMM: Flash Cloning

Reduces speed to instantiate a new clone

VMM: Delta Virtualization

Reduces memory overhead Shares VM pages and supports copy-on-

write operation

Evaluation: Question to address

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

rt?

Multiplexing Address Space

/16 network VM aggressively recycl

ed after 500 ms Average number of acti

ve VMs = 58 Peak = 13614

Multiplexing Honeyfarm Servers

Statistics

Delta Virtualization: 128MB for 116 clones Flash Cloning: 521.2ms to clone and

315.5ms to tear down CPU usage < 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

Limitations

Attracting Attacks– Tends to only receive traffic from randomly target

ed attacks

Honeypot Detection– Detects honeypot and evades honeypot

Denial-of-Service attack

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.

Vigilante

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

Current Worm Containment Strategies

Network level approach (doesn’t 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)

Vigilante architecture

Use honeypot for worm detection, and generate self-certifying alert

Propagate alert on overlay network

Install filter in local host

Self-certifying alert

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

SCAs.

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

Worm detection

Use Honeypots Two different worm detections engines:

1. Non-executable pages Non-execute protection on stack and heap to prevent c

ode injection attack

2. Dynamic dataflow analysis Data received from the network is dirty, and propagate

the dirty bit whenever data is moved

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.

Alert Verification

Verification is run in sandbox, virtual machine.

Service is instrumented according to alert type with the verified function.

Properties of SCA Verification

Fast – Overhead of virtual machine is small Simple and generic No false positives Some drawbacks

– Doesn’t describe the scheduling order for the threads

Alert Distribution

Distribution must be fast, secure and reliable Use of secure Pastry overlay to broadcast To avoid DOS:

– Don’t 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

Filter generation

Use dataflow and control flow analysis to generate filter

Use two filters: general filters and specific filters to reduce false negatives

Evaluation

Three real worms– Slammer: 75,000 MS SQL Servers infected, 8.5 s

econds to double– CodeRed: 360,000 MS IIS Servers infected, 37 mi

ns to double– Blaster: 500,000 MS Windows infected, rate of gr

owth similar to CodeRed

Alert generation and verification

Alert Distribution

Filter generation and CPU overhead

End-to-end experiments

5 host vigilante networks One detector, three super-peers for SCA dist

ribution overlay, and one vulnerable host Results

– Slammers: 79ms– Blaster: 305ms– CodeRed: 3044ms

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 strat

egy