Countering Kernel Rootkits with Lightweight Hook Protection

1. Countering Kernel Rootkits with Lightweight Hook Protection Presented by: Hector M Lugo-Cordero, MS CAP 6135 March 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. Outline • Rootkits • HookSafe • Design and Implementation • Performance • Closing Remarks

4. Outline • Rootkits • HookSafe • Design and Implementation • Performance • Closing Remarks

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. Outline • Rootkits • HookSafe • Design and Implementation • Performance • Closing Remarks

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. Outline • Rootkits • HookSafe • Design and Implementation • Performance • Closing Remarks

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. Outline • Rootkits • HookSafe • Design and Implementation • Performance • Closing Remarks

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. Outline • Rootkits • HookSafe • Design and Implementation • Performance • Closing Remarks

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 • 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 • http://www.wikipedia.org • http://www.bleepingcomputer.com • http://support.kaspersky.com/viruses/solutions?qid=208280684

33. QUESTIONS ¿?