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 nativ
e 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