countering kernel rootkits with lightweight hook protection

1

COUNTERING KERNEL ROOTKITS

WITH LIGHTWEIGHT HOOK PROTECTION

Presented by: Ruaa Abdulrahman

CAP 6135 .. Malware and Software Vulnerability Analysis

April 08, 2013

2

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

3

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.

4

KERNEL ROOTKITS

Because all of that threats : we need ?

Preservation of kernel code integrity.Safeguard relevant kernel control data which

are the return addresses and function pointers.

In this paper they focused on function pointers and called it

“kernel hook”.

Equally important

5

KERNEL HOOKkernel 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.

6

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”.

7

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.

hijack contro

l

data

subvert contro

l

data

8

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.

9

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.

10

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.

11

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.

12

PROBLEM OVERVIEW

13

PROBLEM OVERVIEW

What are Pages?

- Non-continuous memory blocks

- Creates a mapping between a physical address and a virtual ones

- Provides virtual RAM

14

HOOKSAFEo Hooksafe is a hypervisor-based

lightweight system that able to efficiently protect thousands of kernel hooks in a guest OS from being hijacked

o “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

15

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 systemA hypervisor can be securely loaded Protect the kernel at boot time

- Runtime integrity of hypervisor is maintained

16

HOOKSAFE DESIGN In order to resolve the protection

granularity gap problem,

They Relocate kernel hooks to a dedicate page- aligned 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 .

17

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.

18

HOOKSAFE DESIGN Hooksafe achieves its functionality in two

steps:

1- Offline hook profiles

2- On line hook protector

19

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).  

20

OFFLINE HOOK PROFILES

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.

- For the Design .. There are two approaches: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)

21

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.

22

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).

23

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.

24

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.

25

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.

26

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.

27

ONLINE HOOK PROTECTOR

28

ONLINE HOOK PROTECTOR

29

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.

30

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.

31

EVALUATION

32

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.

33

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.

34

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

35

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)

36

REFERENCES1. 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

37

38

QUESTIONS