Security versus Energy Tradeoffs in Host-Based Mobile Malware Detection

1. Security versus Energy Tradeoffs in Host-Based Mobile Malware Detection Jeffrey Bickford *, H.Andrés Lagar-Cavilla #, Alexander Varshavsky #, VinodGanapathy *, and LiviuIftode * * Rutgers University # AT&T Labs – Research

2. Smart Phone Apps Store personal and private information Location Contacts Email Banking

3. The Rise of Mobile Malware 2004 2006 2011

4. Traditional Malware Detection Antivirus 2011 • Periodically scan the attack target • System comprised of code and data • Personal files, executables, databases, network activity Battery life decreases 2x faster! 30469 of 121876 scanned Remaining Time: 1 hour 2 minutes Cancel Scan

5. Mobile Detection Problem • Typical machines can execute malware detection systems 24/7 • Mobile devices are limited by their battery • Detection mechanisms in their current state lead to high energy cost • Executing malware detection systems only when charging is not sufficient

6. Contributions Explore the tradeoffs between security monitoring and energy consumption on mobile devices • Framework to quantify the security vs. energy tradeoffs on a mobile device • Create energy optimized versions of two security tools • Introduce a balanced security profile

7. How Do I Conserve Energy? • Frequency of Checks • When to check? • Scan less frequently • Timing vs events • Attack Surface • What to check? • Scan fewer code/data objects What to Check Attack Surface When to Check Frequency of Checks

8. Security-Energy Tradeoff • Various Attacks • Scan all continuously • Best possible security • High energy cost • Periodically Scan • Vulnerable between scans • Scan Subset • Vulnerable to attacks outside of subset Is there a sweet spot? Attack Surface Frequency of Checks Mobisys 6/30/2011 8

9. Rootkits Rootkits are sophisticated malware requiring complex detection algorithms User Space App App AntiVirus App Virus Libraries Rootkit Kernel Space System Call Table Drivers Process Lists Kernel Code

10. Demonstrated Attack Conversation Snooping Attack Rootkit Infected Attacker Send SMS Delete SMS Dial me “666-6666” Call Attacker Turn on Mic Rootkit stealthily hides from the user [Bickford et al. HotMobile‘10]

11. Rootkit Detection OS must be monitored using a hypervisor • Detection tools run in trusted domain • Mobile hypervisors soon • VMWare • OKL4 Microvisor (Evoke) • Samsung Xen on ARM Trusted User OS Detector Hypervisor Host Machine

12. Experimental Setup • Viliv S5 • Intel Atom • 3G, WiFi, GPS, Bluetooth • Xen Hypervisor • Evaluated the tradeoff using two existing rootkit detectors within trusted domain • Workloads • 3G and WiFi workload simulating user browsing • Lmbenchfor a CPU intensive workload

13. Detecting Data-Driven Attacks • Gibraltar[Baligaet al. IEEE TDSC ‘11] typifies the usual form of rootkit defense for kernel data attacks • Primarily pointer-based control flow • Scans data structures within the OS Kernel • Scanning approach analogous to antivirus scans • Original version monitored all data structures all of the time

14. Detecting Data-Driven Attacks Guest domain Trusted domain Gibraltar daemon Reconstruct data structures Kernel Code Kernel Data 2 Invariant DB Data page ? 3 1 Alert user Fetch Page Hypervisor

15. Problem – High Energy Cost while(1) { for all kernel data structures { get current value check against invariant } } Continuous Scan Idle Must tradeoff security for energy • Maximum security • 100 % CPU usage • Poor Energy Efficiency

16. Tradeoffs for Data-Based Detectors Attack Surface All Data Function Pointers Original design of Gibraltar All Lists Process List Event Threshold: (page changes between checks) Static Data Poll Frequency (seconds) 100 50 120 1 10 0 1 5 30 Frequency of Checks

17. Frequency of Checks while(1) { for all kernel data structures { get current value check against invariant } } while(1) { every “x” seconds { for all kernel data structures { get current value check against invariant } } Scan Idle

18. Evaluating the Tradeoff Sweet Spot!

19. Attack Surface while(1) { for all kernel data structures { for a subset of data structures { get current value check against invariant } } while(1) { for all kernel data structures { get current value check against invariant } }

20. Evaluating the Tradeoff 96% of rootkits! [Petroni et al. CCS ‘07]

21. Detecting Code-Driven Attacks • Patagonix[Littyet al. USENIX Security ‘08] typifies most code integrity monitoring systems • A different class of rootkits attack code • trojaned system utilities • kernel code modifications • Can protect both kernel code and user space code • Protects against a different set of attacks compared to Gibraltar

22. Detecting Code-Driven Attacks Trusted domain Guest domain Patagonixdaemon Code: OS & applications Data 2 Hash DB hash(page) ? Code page 3 1 Resume guest Alert user Hypervisor

23. Tradeoffs for Code-Based Detectors Attack Surface Original design of Patagonix All Code Root Processes Kernel Code Poll Frequency (seconds) Event Threshold: (pages exec between checks) 341 50 120 1 10 0 1 5 30 Frequency of Checks

24. Putting it Together • Cover 96% of Rootkits • Polling sweet spot – 30 sec

25. Conclusion • Mobile malware is a threat • Security tools costly when energy constrained • Developed a framework to quantify the tradeoff • between energy efficiency and security • Optimized two previously existing tools • Generated a “balanced” security profile

26. Thank You! Fully Secure Select a security plan: Balanced Low risk High risk Learn how to conserve power More security options Smart Phone Security Center

27. Randomization • Periodically scan • Attackers will attempt to exploit the system while idle • Randomize the time the system is idle Attack Surface Frequency of Checks

28. Cloud Offload Feasibility Cloud offload impractical energy-wise