Countering Kernel Rootkits with Lightweight Hook Protection

Presented by: Hector M Lugo-Cordero, MS

CAP 6135March 24, 2011

2

Acknowledgements

• Title: Countering Kernel Rootkits with Lightweight Hook Protection

• 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

• Rootkits

• HookSafe

• Design and Implementation

• Performance

• Closing Remarks

OutlineOutline

4

• Rootkits

• HookSafe

• Design and Implementation

• Performance

• Closing Remarks

OutlineOutline

5

Kernel Space

• Where the core of the OS resides

• May be accessed through system calls

• Has full access to the system

• Like running in real mode assembly language, but at a higher level (i.e. easier programming)

6

Kernel Rootkits

• Hide presence and activities– Hijack control by modifying kernel space

• Types:– Kernel Object Hooking (most of the rootkits)– Dynamic Kernel Object Manipulation

• Tamper OS to launch attacks– System backdoor– Stealing private information– Escalating privileges of malicious process– Disabling defense mechanisms

7

Example of Rootkit (TDL4)

• From the Rootkit.Win32.TDSS family• Installs in Master Boot Record• Runs before the Operating System• Blocks programs from running• Delivers advertisements• Google redirects• Keeps a copy of payload in MBR so it can be reinstalled• Best way to get rid of it is by replacing the MBR• Previous versions (infecting drivers) could be removed

with TDSSKiller from Kasperry group

8

• Rootkits

• HookSafe

• Design and Implementation

• Performance

• Closing Remarks

OutlineOutline

9

Traditional Defense Approaches

• Analyzing rootkits behaviors– Examples: Panorama, HookFinder, K-Tracer

• Search common symptoms on infected computers– Examples: Copilot, SBCFI, VMwatcher

• Preserve kernel code integrity– Examples: SecVisor, Patagonix, NICKLE– Can be bypassed by return-oriented rootkits

• Hijack function pointers or return addresses• Utilize kernel code snippets

10

HookSafe

• Challenge: Protection granularity gap– Hook protection requires byte granularity– Hardware only provides page level protection

• Kernel hooks (function pointers), after initialized have frequent read access, less write access (less than 1%)

• Move hooks to page-aligned memory and protect with traditional page protection– Any write access can be monitored

• Small overhead effect

11

Hooks per Page Histogram

[1]

12

What are Pages?

• Fundamental to use non-continuous memory blocks

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

• Provides virtual RAM

13

Paging Process

[2]

14

Paging Mapping

[2]

15

• Rootkits

• HookSafe

• Design and Implementation

• Performance

• Closing Remarks

OutlineOutline

16

Assumptions

• A hypervisor will be used to monitor virtual machines– From Wikipedia: “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.”

• 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

17

HookSafe Architecture

[1]

18

Offline Hook Profiler

• Set of functions that read/write the hook– Hook Access Points (HAPs)

• Set of values assign to a hook

• Enables transparent hook indirection

19

Offline Hook Profiler Design

• Static Analysis– Performed on kernel’s source code– Automatically collect hook profiles using 3rd party

program techniques (e.g. points-to analysis)• Dynamic Analysis

– Does not need the source code (good for Windows)– Run target system on an emulator and monitor

memory access to derive hook profiles• Tradeoff

– Coverage (static) vs Precision (dynamic)• HookSafe choses precision over coverage

20

Offline Hook Profiler Implementation

• Run in emulation and hooks are recorded with set of read/write (HAPs) and values

[1]

21

Online Hook Protector

• Its input is the Hook Access Profiles• Creates a shadow copy of all protected

hooks• Instruments HAP instructions so that the

access is redirected to the shadow copy• Shadow copies are moved into a

centralized location to be protected from unauthorized modifications (i.e. page level protection)

22

Online Hook Protector Design

• Initialization– Temporary kernel module to create shadow copy of hooks and

load the code for indirection layer– Patch the HAPs for redirection to copy

• Run-Time Read/Write Indirection– Read: reads from copy and returns to HAPs– Write: control is passed to hypervisor for validation check. New

value seen in the offline profiling phase.

• Run-Time Tracking of Dynamically Allocated Hooks– Embedded in Dynamic Kernel Object (i.e. heap)– Size is fixed because it can only be know at runtime

• Hardware abstraction intercept register access

23

Online Hook Protector Implementation

• 5 bytes jmp instruction

• 1 byte opcode (0xE9)

• 32-bit integer offset operand

• Variable length instructions in x86

• jmps are padded with NOP (0x90)

• old instructions are re-written and moved

[1]

24

• Rootkits

• HookSafe

• Design and Implementation

• Performance

• Closing Remarks

OutlineOutline

25

Detecting Rootkits

• At read periodically the hook indirection checks for consistency between the original hook, and the shadow copy

• Any discrepancy is caused by a compromised original hook

• At write if action is legitimate both original and copy of the hook is written

26

Evaluation

[1]

27

Evaluation Example

[1]

28

• Rootkits

• HookSafe

• Design and Implementation

• Performance

• Closing Remarks

OutlineOutline

29

Strengths (Remarks)

• Rootkit protection without the need of going to the source code

• Low overhead of 6% of runtime

• Works with variable instruction length architecture (e.g. x86)

• Byte equivalent protection using page protection of the hypervisor

30

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. This was not the case with mood-nt

• Legitimate values need to be inside of hook profile

• Memory usage for creating shadow copies

31

Suggestions

• Test HookSafe on Windows• Add mechanisms to restore MBR or VBR

in case of multiple OS present• 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)

32

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.org3. http://www.bleepingcomputer.com4. http://support.kaspersky.com/viruses/solutions

?qid=208280684

33

QUESTIONS