1. A Virtual Machine Introspection Based Architecture for Intrusion Detection
CS598 STK
Presented by Zahid Anwar

2. My favorite Newsgroup Comment
“paper is NOT interesting.. To save time, suggest reading just Fig 1 and Sec 8”

3. Types of IDSes Network IDS Poor visibility High attack resistance
User-space HIDS
High visibility
zero attack resistance
Kernel-space HIDS
User programs can modify kernel (e.g. sys_call_table) through LKM or even /dev/kmem
IDS crash  system fail open
VMI IDS
High attack resistance because  “a VMM is a simple-enough mechanism that we can reasonably hope to implement it correctly”
Too close a view  needs a interface library for interpretation

4. VMI IDS Architecture OS interface library
Interprets hardware state into OS-level events
For example, list of all processes
Hard to implement and tied to a particular guest OS
Policy modules
Determine if the OS has been compromised and what action to take
Many detection techniques can be implemented as policy modules and thus used to prevent intrusions
VMware running on a Linux host
Added necessary interposition/inspection hooks to VMware
IDS implemented in the host OS (Linux) as independent processes
Used crash as the OS Interface Library (assumes the guest OS is Linux compiled with debug symbols)
Policy Engine written in Python
VMM-VMI communication through Unix Domain Sockets and a memory mapped file
Crash dump tool
A slightly more “kernel-aware” gdb
If run on a live system takes kernel name and Core dump file ( /dev/mem ) as arguments
Lots of helpful commands
Symbolic display of kernel text or data
System state e.g. bt (a task’s kernel stack backtrace), files (task's current root directory and working directories)
Utility functions e.g search (Searches a range of user or kernel memory space for given value), wr (modify contents of memory)
Session Control Commands e.g. foreach (run the same crash context-sensitive command on a number of tasks )

5. Policy Modules Newsgroup Question:
“claim they opted to suspend VM only on definitive misuse, at the same time they do polling on periodic basis.
How these two relate?
Who is doing the polling and who decides if an event is definitive misuse?”

6. Sample Policy Modules User program integrity detector
Periodically hashes unchanging sections of running programs, compares to those of known good originals
Signature detector
Periodically scans guest memory for substrings belonging to known malware
Finds malware in unexpected places, like filesystem cache
Lie detector
Detects inconsistencies between hardware state and what is reported by user-level programs (ls, netstat, …)
Raw socket detector

7. Enforcing Confinement Policies
Event driven Modules run in response to a change in hardware state
Memory access enforcer
Prevents sensitive portions of the kernel from being modified
NIC access enforcer
Prevents the guest’s network interface card (NIC) from entering promiscuous mode or having a non-authorized MAC address
Event-driven checkers run when the VMM detects
changes to hardware state, such as a write to a sensitive
location in memory. At startup, each event-driven checker
registers all of the events it would like to be notified of
with the policy framework. At runtime, when one of these
events occurs, the VMM relays a message to the policy
framework. The policy framework runs the checker(s)
which have registered to receive the event. In a purely
intrusion-detection role, event-driven checkers can simply
report the event that has occurred according to their
policy, and allow the virtual machine to continue to run.
The VMM can also be directed to suspend on events, thus
allowing the policy module to also serve as a reference
monitor that regulates access to sensitive hardware.

8. Newsgroup question: "how to interpret the VMI performance graph - is the baseline, a native system executing directly or VMWare without any of our detection software.”
Backdoors
cd00r.c, T0rn, lrk5
Rootkits
Knark, Adore, Suckit
Worms
Ramen
Network Sniffers
Dsniff,
copied the kernel from one directory to another using the cp -r command to provide a more I/O intensive task. evaluate the overhead associated with running our checkers at different polling intervals. The baseline measurement shows performance of the workload without Livewire running. Our performance results were somewhat surprising to us. We had expected the time taken by polling modules as a function of the total time to decrease linearly as the cost of checking was amortized over the total running time of the the workload. While this was generally the trend, we found that as the polling interval decreased the interactions with the workload became more erratic.

9. Automatic maintenance and repair of advanced electric meters.
Remote Entity
Remote Entity
Extract Useful State
Send Policy
Corrupted VM VM
Agree to abide
And pass down
Report
Violations
Replace
With newly
Constructed VM
VMM
VMM
Thoughts:
Terra
IBM’s sHype
This "halt-on-fault" technique could be applied to good effect by other systems that require monitoring of a running operating system, such as extended forms of remote attestation.
Terra provides a way of attesting an application running in a closed box VM to a remote server. The remote server can make sure that it is communicating with a legitimate application which is in a state as expected by the server. If the application has been tampered with or compromised by a virus, then the server can detect that and stops communication. The attestation is done by a chain of digital certificates.
sHype uses remote reference monitor (shamons) to arbitrate resource’s shared by VMs

10. Fine-graining halt-on-fault
“Only stop those malicious programs and keep legal applications running”
Some thoughts:
Theoretically possible for user-level Trojans since they say you have control of process table
Not always possible to reverse a worm’s effects in a running kernel

11. Complicated OS Interface Library
“efforts are large. All the machine states visible in the OS should be explicitly exported across the border of VMs so that the monitoring VM is able to view them. Moreover, can every hardware/OS state be exported across a VM border?”
Some Thoughts:
XenAccess Introspection Library
provides a higher-level abstraction than available through Xen’s libxc
Limitation: DomU and Dom0 must use same kernel image

12. Other techniques
“seems to be some previous work (e.g., Linux LIDS) that make some system files unmodifiable, even by the root …good enough for attack resilience?”
Kernel hardening techniques such as LIDS and Pitbull are preventive (not detection)
MAC is hard to configure correctly
May still be subvirted by booting with an alternate kernel

13. Detecting unknown attacks
“IDS has weakness in detecting attacks & unknown vulnerabilities
Limitation of secure systems in general.
Virus checkers need to be constantly updated for new signatures
.. in addition, detecting attacks after compromise might be useless…”
Depends on nature of compromise. Consider timely recovery from a DoSed system
Might find an interesting read
Z Anwar, R H Campbell, “Secure Reincarnation of Compromised Servers using Xen Based Time-Forking Virtual Machines” ,"Perware, 5th Annual IEEE International Conference on Pervasive Computing and Communications NY, March, 2007.

14. Discussion
Malware might detect an IDS running on the infected host and remove itself from memory when a scan is performed
Can save entire system state for forensics
Better visibility into guest  worse performance
OS interface library is complex, can be fooled
Policy Management
How to differentiate good and bad behavior?
Hard to express and enforce fine-grained policies
Ad-hoc way to do intrusion detection
Update signature database
Maybe complete logging is better