security versus energy tradeoffs in
play

Security versus Energy Tradeoffs in Host-Based Mobile Malware - PowerPoint PPT Presentation

Security versus Energy Tradeoffs in Host-Based Mobile Malware Detection Jeffrey Bickford *, H. Andrs Lagar-Cavilla #, Alexander Varshavsky #, Vinod Ganapathy *, and Liviu Iftode * * Rutgers University # AT&T Labs Research Smart Phone


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

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

  3. The Rise of Mobile Malware 2004 2006 2011 Mobisys 6/30/2011 3

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

  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 Mobisys 6/30/2011 5

  6. Contributions Explore the tradeoffs between security monitoring and energy consumption on mobile devices 1. Framework to quantify the security vs. energy tradeoffs on a mobile device 2. Create energy optimized versions of two security tools 3. Introduce a balanced security profile Mobisys 6/30/2011 6

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

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

  9. Rootkits Rootkits are sophisticated malware requiring complex detection algorithms User Anti App App Virus App Libraries Space Virus Rootkit Kernel System Process Kernel Drivers Call Space Lists Code Table Mobisys 6/30/2011 9

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

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

  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 – Lmbench for a CPU intensive workload Mobisys 6/30/2011 12

  13. Detecting Data-Driven Attacks • Gibraltar [Baliga et 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 Mobisys 6/30/2011 13

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

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

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

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

  18. Evaluating the Tradeoff Sweet Spot! Mobisys 6/30/2011 18

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

  20. Evaluating the Tradeoff 96% of rootkits! [Petroni et al. CCS ‘07] Mobisys 6/30/2011 20

  21. Detecting Code-Driven Attacks • Patagonix [Litty et 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 Mobisys 6/30/2011 21

  22. Detecting Code-Driven Attacks Trusted domain Guest domain Patagonix daemon Code: OS & Data applications 2 Hash hash(page) ? Code DB page 3 1 Resume Alert Hypervisor guest user Mobisys 6/30/2011 22

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

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

  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 Mobisys 6/30/2011 25

  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 Mobisys 6/30/2011 26

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

  28. Cloud Offload Feasibility Cloud offload impractical energy-wise Mobisys 6/30/2011 28

Recommend


More recommend