The 5th International conference On Network and Systems Security (NSS 2011)
CloudSec:
A Security Monitoring Appliance
For Virtual Machines In The
IaaS Cloud Model
Amani S. Ibrahim
James Hamlyn-Harris, John Grundy and Mohamed Almorsy
Center for Computing and Engineering Software Systems
Swinburne University of Technology
7 September 2011
Agenda
IaaS Cloud Computing Model
IaaS Security Problem
Key Problems
CloudSec
Future Work
IaaS Cloud Computing Model
 IaaS allows customers to increase their computational
and storage resources on the fly
 IaaS
is characterized
virtualization
by
the
concept
of
resource
Server Aggregation
1/20
Agenda
IaaS Cloud Computing Model
IaaS Security Problem
Key Problems
CloudSec
Conclusions
IaaS Security Problem

VMs are hosted by the Cloud Provider and controlled by the Cloud
Consumer.
CC1
VM
VM
CC2
CC3
VM
VM
Cloud Platform
CP
2/20
IaaS Security Problem (cont.)
 Cloud Providers who are hosting Virtual Machines (VMs)
are not aware of the actual contents of VMs.
 VMs can be easily compromised
 Compromised VMs can impact other CCs and CP
VMs cannot be trusted from Cloud Provider’s perspective to host security software
New Virtualization-aware security solutions need to
be provided that can protect VMs from outside
the VM itself
3/20
Virtualization For Security

As we need security for virtualization, virtualization can be
utilized to enhance security
 External Monitoring (Virtual Machine Introspection)
 Isolation
 Control
VM
VM
VMI Layer
Security
Software
Virtualization Software (Hypervisor)
Hardware
4/20
Agenda
IaaS Cloud Computing Model
IaaS Security Problem
Key Problems
CloudSec
Conclusions
Key Problems to Overcome

The “Semantic Gap”

How can we interpret hardware bytes to provide useful information about a running
OS (Running DS instances)
 Fully externally to the VM.
 Without relying on the OS kernel.
VM
VMI Layer
f875a020
f875a02c
f875a038
VM
001b0003 00000001 f875a028
External View
f875a028 f875a030 f875a030 (Hardware Bytes)
Security
0b0c1640 000c2fe0 00000000
Software
PROCESS f875a020
SessionId: 2
Peb: 7ffdb000
ParentCid: 0460
Virtualization
Software
(Hypervisor)
Internal View
DirBase: 0b0c1640 ObjectTable: 00000000 HandleCount: 0.
(High-Level OS Information)
Image: csrss.exe
Hardware
5/20
Key Problems to Overcome (Cont.)

Real-Time

Security software needs to trap and verify most system activities


This has a (potentially large) Performance Overhead.
Active Monitoring

Active monitoring requires installing hooks inside the hosted VMs to suspend system
activities until they are analysed (In-Guest Code)
 A major reason for moving to VASSs is to remove any security code form VMs.
6/20
Agenda
IaaS Cloud Computing Model
IaaS Security Problem
Key Problems
CloudSec
Conclusion
Agenda
IaaS Cloud Computing Model
IaaS Security Problem
Key Problems
CloudSec
Threat Model
System Architecture
Monitoring Scenario
Implementation
Evaluation
CloudSec
 Utilizes VMI techniques to monitor VMs at a hypervisor
level
 Inspects physical memory to construct an external high-
level semantic view of the running OS kernel data
structure instances
 Uses this view to write and enforce integrity constraints
on the running data structures instances to protect
against data hooks and DKOM attacks.
Semantic Gap
- Map between the hardware memory layout and the
OS kernel structure
- Recursive traversing for OS global variables
7/20
Threat Model
Hypervisor
VMs
TCB
CloudSec
vSwitch
8/20
System Architecture
 VMI Layer
 Back-end
 Inspect VM’s hardware
 Enables us to gain control
over the hosted VMs to
suspend access to VM’s
hardware
 Front-end
 A set of APIs that allow
communication with the
back-end
 Allows installing triggers
(access or timer) on the
physical memory pages
need to be monitored
Hosted VMs
KSDs
KSDs
KSDs
KSDs
KSDs
MPB
SGB
VMI
Back-end
Hypervisor
Kernel
Hypervisor
Profiles
VM-Thread
Pool Manager
Defense
Modules
Memory Access
Handler
VMI APIs Front-end
CloudSec
Host Physical Memory
9/20
Monitoring Scenario

VM Power on:
1)
2)
3)
The back-end notifies CloudSec
CloudSec creates a separate thread
Checks processor control registers (CR0 + CR4)

4)
Loads the appropriate kernel structure definition


Microsoft Symbols
Building Semantic Gap Knowledge
1)
2)

eg CR0.PG is set + CR4.PAE is clear = 32-bit paging, PAE disabled
Locate global variables and Read the corresponding memory pages
Recursively traverse and map bytes to the KSD
Profiling and Security
1)
2)
3)
Create profile for VM's reconstructed view
Install timer-based or memory-access triggers
Start Security Modules
10/20
Deployment Model
 ESX 4.1 Server
 CloudSec
 vCompute + Posix
Threads + CloudSec Code
 Isolated in a dedicated
vSwitch
 Windows XP VMs
VM2
VM1
vSwitch 2
CloudSec
vSwitch 1
vCompute APIs Backend
ESX 41 Hypervisor
 Connected to another
vSwitch
11/20
Implementation
Data Structures
EPROCESS
KeServiceDescriptorTable
12/20
Implementation
Data Structures
EPROCESS
KeServiceDescriptorTable
EPROCESS1
EPROCESS2
EPROCESSLast
ActiveProcessLink
FLINK
ActiveProcessLink
FLINK
ActiveProcessLink
FLINK
BLINK
BLINK
BLINK
PsActiveProcessHead
13/20
Implementation
Data Structures
EPROCESS
KeServiceDescriptorTable
LDR_DATA_TABLE_ENTRY
InMemoryLoadedModules
InMemoryLoadedModules
DllBase
InMemoryLoadedModules
EPROCESS
ActiveProcessLinks
PsActiveProcessHead
PCB
(0x000)
DllBase
DllBase
DllName
DllName
DllName
……
……
……
DirectoryTableBase (DTB)
(0x018)
ActiveProcessLinks
(0x088)
ImageName
(0x174)
PEB
(0x1b0)
List_Entry
FLINK
BLINK
_PEB_LDR_DATA
(0x00c)
InLoadOrderModuleList
( 0x00c)
_LDR_DATA_TABLE_ENTRY
(0x000)
ImageBaseAddress
(oxoo8)
IMAGE_DOS_HEADER
(0X000)
e_lfanew member
(0x3C)
IMAGE_DIRECTORY_ENTRY_IMPORT
(0X008)
IMAGE_IMPORT_DESCRIPTOR
OriginalFirstThunk
OriginalFirstThunk
OriginalFirstThunk
Name
Name
FirstThunk
Name
FirstThunk
FirstThunk
……
……
……
_IMAGE_THUNK_DATA
ForwarderString
OriginalFirstThunk
OriginalFirstThunk
Function
Name
Name
Ordinal
FirstThunk
FirstThunk
……
……
……
DataDirectory
(0X060)
IMAGE_NT_HEADERS
(0X000)
OptionalHeader
(0X018)
_IMAGE_IMPORT_BY_NAME
……
……
Name……
Name
Name
14/20
Implementation
Data Structures
EPROCESS
KeServiceDescriptorTable
 Data structure hiding eg Process Hiding
 Keep our process list updated as allocation or de-allocation happens in the heap
memory
 NtCreateProcess + NtTerminateProcess + EAX Register
 Check the Process ID, PDT and ThreadListHead
EPROCESS1
ActiveProcessLink
EPROCESS2
ActiveProcessLink
FLINK
FLINK
FLINK
BLINK
BLINK
BLINK
EPROCESS3
ActiveProcessLink
15/20
Implementation
Data Structures
EPROCESS
KeServiceDescriptorTable
typedef struct ServiceDescriptorTable {
SDE ServiceDescriptor[4];
} SDT;
typedef struct ServiceDescriptorEntry {
PDWORD ServiceTable;
PDWORD CounterTableBase;
DWORD ServiceLimit;
PBYTE ArgumentTable;
} SDE;
16/20
Implementation
Data Structures
EPROCESS
KeServiceDescriptorTable
Set KiServiceDescriptorTable
address
Entry_offset = 0
Entry_index = 0
Read SSDT table address
(Offset 0x00)
Read SSDT table
Memory pages
Read Entry [i]
address
Read SSDT table entries
number (Offset 0x0C)
Entry_offset = Entry_offset + 4
Entry_Index = Entry_Index + 1
Yes
Entry Index =
No of entries
No
17/20
Evaluation
 CloudSec
was able to get all running kernel data
structure instances externally
 Comparison between external and internal views
18/20
Performance
 CloudSec builds all the necessary information to bridge
the semantic gap and install monitoring triggers once a
VM is booted-up
19/20
Future Work

Developing and enforcing integrity constraints on the extracted data
structures with their instances to detect and prevent DKOM and data
hooks attacks.


e.g. Object Hiding (process and DLL), Hooking (IAT, SSDT and GDT Hooking)
and Code injection (DLL injection)
This method has two main drawbacks

You need to get a complete list of structure offsets for each kernel build.

Cannot cover all data structures in the kernel (thousands) because this
mainly depends on security expert analysis.
Detect all kernel data structures automatically, beyond the kernel version
(Pointer Analysis)
20/20
Questions
Amani S. Ibrahim
aibrahim@swineduau