Detecting Large-Scale System Problems by Mining Console Logs

Download Report

Transcript Detecting Large-Scale System Problems by Mining Console Logs

Author : Jiang Wang, Angelos Stavrou,
and Anup Ghosh
Conference: RAID 2010
Advisor: Yuh-Jye Lee
Reporter: Yi-Hsiang Yang
Email: [email protected]
2011/4/28
1
Outline
Introduction
Related Work
System Architecture
Implementation
Evaluation
Conclusion
2011/4/28
2
Introduction
• Virtual Machine Monitors (VMMs)
• Deep isolation of untrusted software components
• Attackers towards VMM vulnerabilities
• HyperCheck
• Works at the BIOS level
• CPU System Management Mode (SMM)
2011/4/28
3
Related work
 Copilot employed a special PCI device to poll the physical
memory of the host and send it to an admin station
periodically
 HyperGuard Rutkowska et al. suggested using SMM of the
x86 CPU to monitor the integrity of the hypervisors
 DeepWatch also offers detection of hypervisor rootkits by
using the embedded micro-controller(s) in the chipset. Relying
on hardware-assisted virtualization technologies such as Intel
VT-d
 Flicker uses a TPM based method to provide a minimum
Trusted Code Base (TCB), which can be used to detect the
modification to the kernels
2011/4/28
4
Threat model
 System Management Mode (SMM)
 Intel386 SL and Intel486 SL processors
 The processor enters SMM when the external
SMM interrupt pin (SMI#) is activated or received
from the advanced programmable interrupt
controller (APIC)
 Processor switches to a separate address space,
called system management RAM (SMRAM)
2011/4/28
5
Attacker’s capabilities
 Exploit vulnerabilities in any software after
bootup.
Eg. compromise a guest domain and escape
to the privileged domain
 Modify the hypervisor code or data using any
known or zero-day attacks.
Eg. DMA attack
2011/4/28
6
General Assumptions
 Attacker cannot tamper with PCI NIC using the
same driver interface
 SMRAM is properly setup by BIOS upon boot
time and locked
 Limitations

Analysis cannot protect against attacks that
modify the dynamically generated function
pointers
2011/4/28
7
In-scope Attacks
 Aims to detect the in-memory Ring-0 level rootkits
 Rookits




2011/4/28
A set of programs and code that allows a
permanent or consistent
Modifies the memory and/or registers
Runs in the kernel level
Eg . idt-hook rootkit
 Modifies the interrupt descriptor table (IDT)
 Gains the control of the complete system
8
System Architecture
 HyperCheck is composed of three key components
 Physical memory acquiring module
 Reads the contents of the physical memory
 Sends data to the analysis module
 Analysis module

Checks the memory contents and verifies if anything is
altered
 CPU register checking module

2011/4/28
Reads the registers and validates
9
System Architecture
2011/4/28
10
System Architecture
 HyperCheck should not rely on any software running
 Use hardware
 PCI Ethernet card– as memory acquiring module
 SMM to read the CPU registers
 Uses the CR3 register
 Translate the virtual addresses to the physical
addresses
2011/4/28
11
System Architecture
-Acquiring the physical memory
 Two ways to acquire the physical memory
 Software method
 /dev/kmem on Linux or \Device\PhysicalMemory on
Windows
 If the operating system or the hypervisor is compromised
 Hardware method
 Uses a PCI device
 Depends less on the integrity of the operating system or
the hypervisor
2011/4/28
12
System Architecture
-Acquiring the physical memory
 HyperCheck puts drivers into the SMM code
 To prevent from a malicious NIC driver in the OS
to spoof the SMM driver
 Use a secret key obtained from the monitor machine
when booting up and stored in the SMRAM
 Denial of service(DoS) attacks
 Advanced Configuration and Power Interface (ACPI)

2011/4/28
Allow the operating system to control the state of the
devices
13
System Architecture
-Translating the physical memory
 Three properties of the kernel memory
 Linear mapping
 Kernel memory is linearly mapped to physical memory
 Static nature
 Contents of monitoring part of hypervisor have to be
static
 Persistence

2011/4/28
Memory will not swap to the hard disk
14
System Architecture
-Reading and verifying the CPU registers
 Ethernet card cannot read the CPU registers
 Use SMM in x86 CPU
 When switches to SMM it saves the register context in the
SMRAM
 Focuses on monitoring two registers:
 IDTR
Should never change after system initialization
 CR3
 Translate the physical addresses of the hypervisor kernel
code and data

2011/4/28
15
Implementation
 HyperCheck-I
 Virtual machine uses QEMU
 Analysis module runs on the host of QEMU
 Placed NIC driver into the SMM
 Program runs in the SMM and collects and sends out the
CPU registers via the Ethernet card
 Quick Prototyping and Debugging
 QEMU network card is much lower than a real NIC device
(10MB/s)
 Performance may not reflect the real world performance
2011/4/28
16
Implementation
-Memory Acquiring module
 SMM code is one part of BIOS
 Using SMM for ”Other Purposes”. Phrack Magazine, 2008
 Writes the SMM code in 16bit assembly
 Uses a user level program to open the SMRAM
 Copy the assembly code to the SMRAM
 Program the transferring part in assembly


Assembly code is compiled to an ELF object file
Write a loader parse the ELF object file and load the code and
data to the SMM
 Modified the existing Linux E1000 driver to initialize the
network card
2011/4/28
17
Implementation
-Memory Acquiring module
 Two transmission descriptors per packet
 Header

NIC is already initialized by OS
 Data


2011/4/28
Prepare Descriptor table and write it to the Transmit Descriptor
Tail (TDT) register of the NIC
Secret key
 Create a random seed to selectively hash the data
 for one-time pad encryption
 Serial random numbers
 indexes of the positions of the memory being scanned
18
Implementation
-Analysis module
 CentOS 5.3
 Tcpdump to filter the packets from the acquiring module
and output is sent to the analysis module
 Recovers the contents using the same secret key
 Written in a Perl script reads the input and checks for any
anomalies
 Compares every two consecutive memory snapshots
 Check the integrity of the control data and code

2011/4/28
Control data includes IDT table, hypercall table and exception
table of Xen
19
Implementation
-CPU register checking module
 Triggering SMI to enter SMM
 SMI is often used for power management, and Southbridge
provides some timers to monitor the state of a device
 Employ the Ethernet card to trigger the SMI event
 Checking the registers in SMM
 Reporting the result
2011/4/28
20
Implementation
 HyperCheck-II
 Target
Xen 3.1
 Intel E1000 Ethernet card
 SMM NIC driver from the QEMU VM does not work on the
physical machine
 NIC can access the SMRAM in a QEMU VM
 Reserved 12MB for HyperCheck by using mem parameter
 Monitor
 Analysis module
 Used for performance measurement

2011/4/28
21
Evaluation
 HyperCheck-I
 Dell Precision 690
 8GB RAM
 3.0GHz Intel Xeon CPU with two cores
 The host : CentOS 5.3 64bit
 QEMU version was 0.10.2
 Xen version was 3.3.1
 Domain 0 was CentOS 5.3 32bit with PAE
 HyperCheck-II
 Dell Optiplex GX 260
 2.0GHz Intel Pentium 4 CPU
 512MB memory
 Xen 3.1 and Linux 2.6.18
 Domain 0 is CentOS 5.4
2011/4/28
22
Evaluation
-Detection
 HDD DMA attacks to modify the Xen hypervisor and
Domain 0
 Four attacks to Xen hypervisor and Two attacks to Domain 0
 Modified pcnet NIC in QEMU to attack Linux and
Windows operating systems
2011/4/28
23
Evaluation
-Monitoring overhead
Internal NIC transfer FIFO is 16KB
2011/4/28
24
Evaluation
-Operation
 Two programs
 Use Dummy SMM code
 Time for switching between protected mode & SMM
 Use the registers to simulate the verification of
IDTR and CR3
 Sending the data : 73 Million cycles.
 Accessing the main memory : 5.28 Million cycles.
 The total time is 80 Million cycles
2011/4/28
25
Evaluation
- Overhead of the operations
2011/4/28
26
Evaluation
 Reading memory contents and comparing
 Total 230 ms
 49 ms for only comparing the data
2011/4/28
27
Evaluation
2011/4/28
28
Conclusion
 Introduced HyperCheck-a hardware-assisted tamper
detection framework
 Rely on CPU System Managed Mode (SMM)
 Implemented two prototypes : QEMU and physical x86
machine
 HyperCheck operation is relatively lightweight
 Produce and communicate a scan of the state of the
protected software in less than 40ms
2011/4/28
29
Thanks for listening!
Q&A
2011/4/28
30