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: 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 rootkit

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 Implementation Results Demo Presentation Conclusion
Q&A

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

8. Protection KM Design

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: (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

13. Limits application abilities in order to prevent malicious behavior.
Architecture Layer
Security Mechanism
Threat Mitigation
App Permissions
Dalvik VM Isolation
App signatures
Limits application abilities in order to prevent malicious behavior.
Virus Scanners
Remote Lockout
Modified system binaries
Trojan’d services
Stolen device
Linux user and group permissions
Access control
Application permissions are granted by the user to reduce malicious behavior. (An application can only access the GPS device if it has been granted the GPS privilege when it was installed.
Application isolation – Each application is ran in Dalvik VM, protects against memory corruption / remote code execution from compromising other applications.
Application Signatures –