Countering Kernel Rootkits with lightweight Hook Protection

Authors: Zhi Wang, Xuxian Jiang, Weidong Cui, Peng Ning

Presented by: Purva Gawde

Outline

Introduction Prior research Problem overview HookSafe Design Implementation Evaluation Experiment result Conclusion

Introduction

A rootkit is a malicious prgram designed to hide the existence of certain processes from normal methods of detection and enable continued privileged access to computer.

Kernel rootkits are considered to be one of the most stealthy computer malware and pose significant security threats.

By directly subverting the OS they not only hide their presence but also tamper with functionality to launch various attacks.

Prior Research

Prior research1. Focus on analyzing rootkit behavior2. Detecting rootkits based on certain symptoms

exhibited by rootkit infection3. SecVisor, NICKLE developed to preserve kernel

code integrity by preventing rootkit code by executing.

These can be bypassed by return oriented rootkits which subvert kernel control flow and launch attack by only using legitimate kernel code snippets.

In addition to preservation of kernel code, it is important to safeguard relevant kernel code data to preserve kernel control flow integrity.

Two main type of control data: return addresses and function pointers.

Intuitive approach: hardware-based page-level protection.

In the OS kernel, there exist thousands of kernel hooks that can be widely scattered.

Also they can be dynamically allocated. In this approach, all writes have to be trapped. It can

cause performance overhead due to unnecessary page faults.

Problem overview

The focus of the paper is on Kernel object hooking rootkits that gain the control of kernel execution by hijacking either code hooks or data hooks.

Hijacking kernel code requires modifying kernel text which is usually static so it can be marked as read-only.

Kernel data hooks are function pointers and reside in two main kernel memory regions.

These two memory areas are:1. Preallocated memory areas:data sections, bss

sections, loadable kernel module2. Dynamically allocated areas such as kernel heap HookSafe design faces the challenge of ,

protection granularity gap.Protection granularity gap: hardware provides page

level protection but kernel hooks are at byte level granularity

Kernel hooks are scattered in kernel space and often co-located with other dynamic kernel data, we cannot simply use page-level protection.

Distribution of kernel Hooks

HookSafe Design All read and write accesses to protected kernel

hooks are routed through hook indirection layer. Offline hook profiler component profiles guest

kernel execution and outputs hook access profile for each protected hook. Kernel instructions that read or write to a hook called Hook Access Points(HAP).

Online hook protector creates shadow copy of hooks and instrument Hap instructions such that their access will be directed to shadow copy.

Offline Hook Profiling

Static analysis and dynamic analysis Static analysis is performed on OS kernel source

code and uses program analysis to automatically collect hook access profile.

Dynamic Analysis runs target system on top of an emulator and monitors every memory access to derive hook access information.

This allows recording precise runtime info such as the values a hook has taken.

Online Hook Protection

Initialization

Initialization:1. Uses an in-guest short-lived kernel module to

create shadow copy of kernel hooks and load the code for indirection layer.

2. Then it leverages the online patching provided by the hypervisor to instrument HAPs in guest kernel.

Read/write Indirection

Run-time Read/Write Indirection: Read Access: reads from the shadow hook and

returns to HAP site. Write Access: indirection layer issues hypercall

and transfer control to hypervisor. Memory protection component validates write request and update shadow hook.

Run-time tracking of dynamically allocated hooks Dynamically allocated hook is embedded in

dynamic kernel object. 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.

Implementation

The online hook protection component was developed based on Xen hypervisor.

Offline hook profiling is based on QEMU, an open source whole-system emulator.

The prototype HookSafe is implemented and evaluated in a system running Ubuntu Linux 8.04

Offline Hook Profiler

QEMU implements a key virtualization technique called binary translation which rewrites guest’s binary instruction.

Prototype extends this with additional instrumentation code to record execution of instructions that read or write memories.

If instruction accesses any kernel hook it is recorded as HAP and log the value

At the end, collected HAP instructions and values will be compiled as corresponding hook access profile.

Example access profile

Hook Indirection

Hypervisor replaces the HAP instruction at runtime with jmp instruction to detour execution flow to trampoline code.

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.

Hook Indirection

HAP patching

Five byte jmp instruction is used to detour control from HAP instruction to Trampoline code.

When HAP instruction occupies more than five bytes, rest space is filled with NOP instr.

When it has less than five bytes, subsequent instruction is overwritten to make space.

Example HAP instruction

Read/ Write Indirection: Trampoline code prepares hook related context info like

HAP address and machine register address Redirector uses this info to find which hook is being read

or written and then identify corresponding shadow hook.

For each redirected hook read access, hook indirection layer in addition performs a consistency check.

Any difference indicates original hook has been compromised.

For write access, if write operation is legitimate, both shadow hook and original hook are updated.

Run time LKM and Hook Tracking” In Linux, kernel objects are allocated/deallocated

through SLAB. There are only two instructions for this. Before these instruction return, code checks

whether SLAB manages particular kernel object containing hook.

If so, hypercall will be issued to HookSafe to track hook creation and termination.

For hooks in LKM, relative offset to base address where the module is loaded is fixed.

Hence, hooks runtime location can be calculated.

Evaluation

Two sets of experiments are conducted. First set is to evaluate HookSafe’s effectiveness in

preventing real-world rootkits. It prevented all of them from modifying protected hooks and hiding themselves.

The second set of experiment is to measure performance overhead induced. Which resulted to be around 6%.

Experiment setting

In experiments, HookSafe takes two sets of kernel hooks.

The first set includes 5,881 kernel hooks in pre-allocated memory area and dynamic loaded kernel module.

The second set is from 39 kernel objects that will be dynamically allocated from kernel heap.

Effectiveness against Kernel Rootkits

Adore-ng Rootkit Experiment

Hijacks a number of kernel hooks and gains control over kernel execution. Also has user level control program named ava that can send detailed instruction to rootkit.

Adore-ng is loaded in guest OS not protected by HookSafe and showed it can successfully hide a running process

Experiment is repeated in same OS protected by HookSafe. Rootkit failed to hide process

HookSafe foils Rootkit

By analyzing the experiment, it was found that rootkit was able to locate and modify certain kernel hooks at their original locations.

But since control flows related to these hooks are now determined by shadow hooks, this rootkit failed to hijack control flow and thus was unable to hide running processes.

Also, check is performed for comparing original hook and shadow hook at each access. Hence kernel hooks were identified which were manipulated by adore-ng.

Performance

HookSafe’s runtime overhead is measured on 10 tasks including UnixBench and Unix Kernel Decompression and compilation. Also its throughput degradation is measured on a web server using ApacheBench.

The guest OS is a default installation on Ubuntu server 8.04.

In Apache test, Apache web server is used to serve a web page of 8K bytes.

Runtime Overhead

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.

Performance benchmark shows that HookSafe only adds about 6% performance overhead.

References

Zhi Wang , Xuxian Jiang , Weidong Cui , Peng Ning, Countering kernel rootkits with lightweight hook protection, Proceedings of the 16th ACM conference on Computer and communications security, November 09-13, 2009.

Wang, X. Jiang, W. Cui, and X. Wang. Countering Persistent Kernel Rootkits through Systematic Hook Discovery. In RAID ’08: Proceedings of the 11th International Symposium on Recent advances in Intrusion detection, 2008.

R. Hund, T. Holz, and F. Freiling. Return-Oriented Rootkits: Bypassing Kernel Code Integrity Protection Mechanisms. In security’09.

Ralph Hund, Thorsten Holz, Felix C. Freiling, Return oriented rootkits: Bypassing Kernel code integrity protection Mechanism.