Countering Kernel Rootkits with lightweight Hook Protection

1. Countering Kernel Rootkits with lightweight Hook Protection Authors: Zhi Wang, Xuxian Jiang, Weidong Cui, PengNing Presented by: PurvaGawde

2. Outline • Introduction • Prior research • Problem overview • HookSafe Design • Implementation • Evaluation • Experiment result Conclusion

3. Introduction • A rootkit is a malicious prgramdesigned 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.

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

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

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

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

8. Distribution of kernel Hooks

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

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

11. Online Hook Protection

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

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

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

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

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

17. Example access profile

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

19. Hook Indirection

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

21. Example HAP instruction

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

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

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

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

26. Effectiveness against Kernel Rootkits

27. Adore-ngRootkit 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 HookSafeand showed it can successfully hide a running process • Experiment is repeated in same OS protected by HookSafe. Rootkit failed to hide process

28. HookSafe foils Rootkit

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

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

31. Runtime Overhead

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. • Performance benchmark shows that HookSafe only adds about 6% performance overhead.

33. References • Zhi Wang , Xuxian Jiang , Weidong Cui , PengNing, 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.