VMM Based Rootkit Detection on Android

1. VMM Based Rootkit Detection on Android Class Presentation Pete Bohman, Adam Kunk, Erik Shaw

2. Problem Statement • Rootkit detection and prevention on the Android platform with specific regards to the sensitive resources Android provides. • Kapersky 2011: 1046 unique malware strains targeting mobile platforms • Android platform built on Linux Kernel, a well known target. • Sensitive information on smart phones • GPS, contacts, text messages, call log

3. Defensive Rootkit Approaches • User mode rootkits • Process infection, binary patching, lib hooks • User mode integrity checkers • tripwire, chkrootkit, rkthunter, AV scanner • Kernel mode rootkits • malicious device drivers and lkms • sys call hooking, kernel data structure manipulation • Kernel level inspection • behavioral analysis, data structure integrity checkers, hook detection • But… Any kernel level inspection mechanisms can be subverted by kernel level rootkits

4. Our Approach • Two Pronged • VMM inspection • Ensures integrity of static kernel module • Isolated from host OS • Kernel module security mechanisms • System call integrity checks • Hidden process detection • Android capability table • We exercise a “layer-below” level of security in which we establish trust beneath the kernel

5. Solution Preview Android Software Stack Kernel module implements security mechanisms Android VMM ensures integrity of static kernel module

6. Overview • Design • VMM Design • Protected KM Design • Implementation • Results • Demo Presentation • Conclusion • Q&A

7. VMM Interface Design Application Framework Android VMM Libraries and Runtime Linux Kernel 4. Invoke KM Trusted KM <ISR> 2. Validate Protected KM 3. Raise Monitor Interrupt 1. Hardware Timer Interrupt Hardware (Emulator)

8. Protection KM Design Maps Contacts SMS Phone Application Framework Content Provider Location Provider Activity Manager Malicious Native Application Libraries and Runtime System Calls Open Socket Read GPS SQL Query Linux Kernel Malicious LKM Trusted KM System Call Whitelist Original Sys Call Table Open SysCall Table

9. Implementation • Instead of utilizing a VMM as the lowest layer, we created a new hardware device in the QEMU emulator • Hardware device based on virtualized timer which expires at predefined intervals • When a timer interval expires, an interrupt is generated and the timer is reset • During each interrupt, the hardware device calls into our kernel module to pass execution • Integrity checks are done on the sys_call_table

10. Implementation (cont.) • We implemented a static Kernel Module (KM) in order to make integrity checks on the sys_call_table • The kernel module contains a copy of the original sys_call_table and compares this to the running version • The KM also sets its own hooks in the sys_call_table in order to detect malicious access to sensitive resources • e.g. Check for invalid process access to sys_open system call attempting to open a sensitive resource file (contacts2.db)

11. Results • We are able to detect/correct modifications to the sys_call_table • We are able to prevent malicious access to sensitive resources • TODO Mention Malicious App and LKM • TODO: (Insert link to demo)

12. Conclusion • Layer Below Protection • Security of the Linux kernel must be rooted in a layer below the kernel • Code contained solely in the kernel is subject to any kernel-level attack • Sensitive Resource Protection • Android mobile phones contain lots of sensitive information that must be protected

14. Kernel Image Linux Kernel Source with Protection KM Compilation Protected Text Sect. Protected Data Sect. QEMU Emulator(VMM) QEMU Emulator (VMM) Compilation Protected Text Protected Data