Countering Kernel Rootkits with
Lightweight Hook Protection
Presented by:
Hector M Lugo-Cordero, MS
CAP 6135
March 24, 2011
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
2
Outline
•
•
•
•
•
Rootkits
HookSafe
Design and Implementation
Performance
Closing Remarks
3
Outline
•
•
•
•
•
Rootkits
HookSafe
Design and Implementation
Performance
Closing Remarks
4
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)
5
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
6
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
7
Outline
•
•
•
•
•
Rootkits
HookSafe
Design and Implementation
Performance
Closing Remarks
8
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
9
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
10
Hooks per Page Histogram
[1]
11
What are Pages?
• Fundamental to use non-continuous
memory blocks
• Creates a mapping between a physical
address and a virtual ones
• Provides virtual RAM
12
Paging Process
[2]
13
Paging Mapping
[2]
14
Outline
•
•
•
•
•
Rootkits
HookSafe
Design and Implementation
Performance
Closing Remarks
15
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
16
HookSafe Architecture
17
[1]
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
18
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
19
Offline Hook Profiler Implementation
• Run in emulation and hooks are recorded
with set of read/write (HAPs) and values
[1]
20
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)
21
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
22
Online Hook Protector Implementation
• 5 bytes jmp instruction
• 1 byte opcode (0xE9)
• 32-bit integer offset operand
[1]
• Variable length instructions in x86
• jmps are padded with NOP (0x90)
• old instructions are re-written and moved
23
Outline
•
•
•
•
•
Rootkits
HookSafe
Design and Implementation
Performance
Closing Remarks
24
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
25
Evaluation
[1]
26
Evaluation Example
[1]
27
Outline
•
•
•
•
•
Rootkits
HookSafe
Design and Implementation
Performance
Closing Remarks
28
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
29
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
30
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)
31
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
3. http://www.bleepingcomputer.com
4. http://support.kaspersky.com/viruses/solutions
?qid=208280684
32
QUESTIONS
33