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 detection 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 replicate the same environment, and duplicate the effort.

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)

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- interface 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 support?

Multiplexing Address Space /16 network VM aggressively recycled after 500 ms Average number of active 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 targeted 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 code 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 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

Alert generationand verification

Alert Distribution

Filter generation and CPU overhead

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

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