Countering Kernel - PowerPoint Presentation

Slide1

Countering Kernel Rootkits with lightweight Hook Protection

Authors:

Zhi

Wang,

Xuxian

Jiang,

Weidong

Cui,

Peng

Ning

Presented by:

Purva

GawdeSlide2

Outline

Introduction

Prior research

Problem overview

H

ookSafe Design

Implementation

Evaluation

Experiment result ConclusionSlide3

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

Prior Research

Prior research

Focus on analyzing rootkit

behavior

Detecting rootkits based on certain

symptoms

exhibited by rootkit infection

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

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

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

These two memory areas are:

1.

Preallocated

memory

areas:data

sections,

bss

sections, loadable kernel module

2. 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.Slide8

Distribution of kernel HooksSlide9

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

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

Online Hook ProtectionSlide12

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

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

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

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.04Slide16

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

Example access profileSlide18

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

Hook IndirectionSlide20

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

Example HAP instructionSlide22

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

Run time LKM and Hook Tracking”

In

L

inux, 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.Slide24

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%.Slide25

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

Effectiveness against Kernel RootkitsSlide27

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 processSlide28

HookSafe foils RootkitSlide29

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

.Slide30

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

Runtime OverheadSlide32

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

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.