COUNTERING KERNEL ROOTKITS
WITH LIGHTWEIGHT HOOK
PROTECTION
Presented by:
1
Ruaa Abdulrahman
CAP 6135 .. Malware and Software
Vulnerability Analysis
April 08, 2013
INFORMATION

Authors:

North Carolina State University
Zhi Wang
 Xuxian Jiang
 Peng Ning


Microsoft Research



Weidong Cui
Published at:
CCS '09 Proceedings of the 16th ACM conference
on Computer and communications security,
Chicago, Illinois, USA, 2009
Sponsored by:
NSF 0852131, 0855297, 0855036, and 0910767
2
KERNEL ROOTKITS
it’s one of the most stealthy computer malware
and poses significant security threats.
Why ?

its directly subverting OS kernel, not just hide their response, but
also tamper with OS functionalities to launch various attack like:
- opining system backdoors.
- Stealing privet information.
- Escalating privileges of malicious processes.
- Disabling defense mechanisms.
3
KERNEL ROOTKITS
Because all of that threats :
 Preservation
Equally important
we need ?
of kernel code integrity.
 Safeguard relevant kernel control data
which are the return addresses and
function pointers.
this paper they focused on function
pointers and called it “kernel hook”.
 In
4
KERNEL HOOK
kernel hook == Function Pointer

Intuitively, to safeguard kernel hooks , we need
to monitor and verify any write access to the
memory page with kernel hook .
This approach has two conditions to work well:
1- There existing a very limited number of kernel
hooks for protection.
2-These hooks are not co- located together with
frequently modified memory data.

5
KERNEL HOOK

Unfortunately ,these two conditions do not work
with OS like Linux and windows
because:
-
-
These OS may have thousands of kernel hook “not
limited number”
and it can be widely scattered across the kernel
space .

The solution for the above challenges::
”Hooksafe”.
6
PROBLEM OVERVIEW

Kernel rootkit : two types:
- Kernel Object Hooking (KOH).
- Dynamic Kernel Object Manipulation (DKOM)


They focused (KOH) because it is more common
attack.
KOH can hijack code hook or data hook.
7
PROBLEM OVERVIEW

Hijacking a kernel code hook:
is easier to protect because its require modifying
the kernel text section
which is - usually static
and - can be marked as read-only.
Kernel data hooks are function pointers and
usually reside in two main kernel memory
regions:
- Preallocated memory areas including the data
sections.
- The dynamically allocated areas such as Kernel
heap.

8
PROBLEM OVERVIEW
Kernel data hooks are function pointers and
usually reside in two main kernel memory
regions:
- Preallocated memory areas including the data
sections.
- The dynamically allocated areas such as Kernel
heap.

The aim is to protect the kernal hooks in
both memorie regions to be tampered by
a Kernal rootKits.
9
PROBLEM OVERVIEW
 Protection
granularity gap Challenge

Efficient Hook protection requires byte - level
granularity.

BUT .. Hardware only provides page level
protection

AND .. Since kernal hooks are scattered
across the kernal space and often co-located
with other dynamic kernal data,

SO .. we can not simply use hardware-based
page level protection.
10
PROBLEM OVERVIEW

Experiment ..
- They analyzed a typical Ubuntu 8.04 server
using a whole emulator called QEMU.
- They used 5881 Linux Kernal Hooks.
- They found that these Kernal hooks are
scattered across 41 Pages and some of them
located in dynamic kernal heap.
11
PROBLEM OVERVIEW
12
PROBLEM OVERVIEW

What are Pages?
-
Non-continuous memory blocks
-
Creates a mapping between a physical address
and a virtual ones
-
Provides virtual RAM
13
HOOKSAFE
o
o
Hooksafe is a hypervisor-based
lightweight system that able to
efficiently protect thousands of kernel
hooks in a guest OS from being hijacked
“In computing, a hypervisor, also called
virtual machine monitor (VMM), is one of
many virtualization techniques which allow
multiple operating systems, termed guests, to
run concurrently on a host computer, a feature
called hardware virtualization.” Wikipedia
14
HOOKSAFE DESIGN

-
Assumptions:
A hypervisor will be used to monitor
virtual machines
- A bootstrap like tboot exists to establish a
static root of trust of the system


A hypervisor can be securely loaded
Protect the kernel at boot time
- Runtime integrity of hypervisor is
maintained
15
HOOKSAFE DESIGN

In order to resolve the protection granularity
gap problem,
They Relocate kernel hooks to a dedicate pagealigned memory space.
 Introduce thin hook indirection layer to regulate
accesses to them with hardware based page level
protection.
 They created a shadow copy of the kernel hooks
in a centralized location. Any attempt to modify
the shadow copy will be trapped and verified by
the underlying hypervisor .

16
HOOKSAFE DESIGN



All read and Write accesses to protected Kernal
hooks are routed through the hook indirection
layer.
Only hypervisor can write to the memory pages
of protected kernel,
In read access they use piece of indirection code
residing in the guest OS kernel memory to read
corresponding shadow hook.
17
HOOKSAFE DESIGN

Hooksafe achieves its functionality in two steps:
1- Offline hook profiles
2- On line hook protector
18
OFFLINE HOOK PROFILES



it is a component that profiles the guest kernel
execution and outputs a hook access profile for
each protected hook.
Hook access profile will be used to enable
transparent hook indirection.
Kernal instructions that read or write to a hook
called Hook Access Points (HAPs).
19
OFFLINE HOOK PROFILES
- For the Design .. There are two approaches:
1- Static analysis
 performed on OS kernel
source code,
 Utilize known program
analysis technique to
automatically collect
hook access profile.

More complete, but less
precise.
2- Dynamic analysis
 Doesn’t need OS kernel
source code,
 run the target system on
the top of an emulator and
monitor every memory
access to derive the hook
access instruction.
 Allow for recording precise
runtime information, but
less coverage
HookSafe chooses Precision (Dynamic) over Coverage (Static)
20
OFFLINE HOOK PROFILES
- Implementation
 It is based on an open source whole system
emulator( QEMU).
 QEMU uses binary translation technique which
rewrites guest’s binary instruction.
 Then records executions of instructions that read
or write memories.
 If instruction accesses any kernel hook it is
recorded as HAP and the value.
 At the end, collected HAP instructions and values
will be compiled as corresponding hook access
profile.
21
ONLINE HOOK PROTECTOR

Its input is the Hook Access Profile.

Creates a shadow copy of all protected hooks


Instruments HAP instructions such that their
accesses will be transparently redirected to the
shadow copy.
Shadow copies are moved into a centralized
location to be protected from unauthorized
modifications and kernel rootkits. (i.e. page level
protection).
22
ONLINE HOOK PROTECTOR
-

For the Design .. There are Three Processes :
Initialization:
1. Uses a short-lived kernel module (temporary)
to create shadow copy of kernel hooks and load
the code for indirection layer.
2. Use the online patching that provided by the
hypervisor in order to instrument HAPs in guest
kernel.
23
ONLINE HOOK PROTECTOR



Run-Time Read/Write Indirection
Read Access: reads from the shadow hook copy
and returns to HAP site.
Write Access: indirection layer issues hyper call
and transfers control to hypervisor for validation
check. Memory protection component validates
write request and update shadow hook.
24
ONLINE HOOK PROTECTOR




Run-Time Tracking of Dynamically Allocated
Hooks
Dynamically Allocated Hooks is embedded in
Dynamic Kernel Object (i.e. heap).
If one such kernel object is being allocated, a
hypercall will be issued to HookSafe to create a
shadow copy of the hook
Another hypercall is triggered to remove the
shadow copy when kernel object is released.
25
ONLINE HOOK PROTECTOR
- Implementation
 It is developed based on Xen Hypervisor.
 Hypervisor replaces the HAP instruction at
runtime with jmp instruction to allow execution
flow to trampoline code in Hook indirection layer.
 Trampoline code collects runtime info which is
used by hook redirector to determine exact kernel
hook being accessed.
 After hook redirector processes the actual read or
write on shadow hook, trampoline executes HAP
specific overwritten instruction, if any, before
returning to original program.
26
ONLINE HOOK PROTECTOR
27
ONLINE HOOK PROTECTOR
28
MEMORY PROTECTION
In order to protect the guest kernel code and the
in-guest memory used by hooksafe.
 the hypervisor maintains an SPT for each guest,
which regulate the translation directly from a
guest virtual address to the host physical
address.
 Any update in the guest page table GPT in the
guest kernel is trapped and propagated to the
SPT shadow page table by the hypervisor.

29
EVALUATION
In order to evaluate HookSafe’s effectiveness in
preventing real-world rootkits, They used the
Xen Hypervisor (version 3.3.o) to protect more
than 5900 kernel hooks in Ubuntu 8.04 Linux
system.
 There experiments with nine real-world rootkits
show that Hooksafe can effectively defeat these
nine rootkits attempt to hijack kernal hooks that
are being protected.
 It prevented all of nine rootkits from modifying
protected hooks and hiding themselves.
 This large scale protection is achieved with only
6% slow down in system performance.

30
EVALUATION
31
CONCLUSION



HookSafe is a hypervisor-based lightweight
system that can protect thousands of kernel
hooks from being hijacked by Kernel rootkits.
HookSafe overcomes a critical challenge of
Protection Granularity Gap by introducing a thin
hook indirection layer.
Experimental result with nine real-world rootkits
show HookSafe is effective in defeating their
hijacking attempts with only 6% performance
overhead.
32
STRENGTHS




Rootkit protection is performed without the need
of going to the source code (Dynamic Analysis)
Low overhead of 6% of runtime
Works with variable instruction length
architecture (e.g. x86)
Perform byte equivalent protection by using page
protection of the hypervisor.
33
WEAKNESS



Doesn’t record what caused the rootkit infection.
It can detect, but not defend against future
attempts.
When discrepancy is found it automatically
assumes the original hook was compromised.
Memory usage for creating shadow copies
34
SUGGESTIONS



Test HookSafe on Windows
Instead of checking discrepancy between hooks
and their copy, check against a hash value to find
out which is compromised
Incorporate static analysis or broader dynamic
analysis (e.g. adaptive analysis)
35
REFERENCES
1.
Z. Wang, X. Jiang, W. Cui, and P. Ning,
“Countering kernel rootkits with lightweight
hook protection”, Proceedings of the 16th ACM
conference on Computer and communications
security, Chicago, Illinois, USA, 2009, pp. 545
– 554
2.
http://www.wikipedia.org
36
37
QUESTIONS
38