Transcript Stopping Worm/Virus Attacks

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
–

Forward outbound packets sent in response to
inbound packets
–

Problems with “phone home” to receive updates
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 userinterface 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-onwrite 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
–

Honeypot Detection
–

Tends to only receive traffic from randomly
targeted attacks
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

2.
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
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 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
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