Security versus Energy Tradeoffs in Host-Based Mobile Malware Detection
28
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
description
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. Smart Phone Apps. - PowerPoint PPT Presentation
Transcript of Security versus Energy Tradeoffs in Host-Based Mobile Malware Detection
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
Location
Banking
Smart Phone Apps
Contacts
Store personal and private information
3
The Rise of Mobile Malware
2004 2006 2011Mobisys 6/30/2011
4Mobisys 6/30/2011
Traditional Malware Detection
• Periodically scan the attack target– System comprised of code and data
• Personal files, executables, databases, network activity
Antivirus 2011
Cancel Scan
30469 of 121876 scanned
Remaining Time: 1 hour 2 minutesBattery life decreases 2x faster!
5
• 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
Mobile Detection Problem
Mobisys 6/30/2011
6Mobisys 6/30/2011
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
7Mobisys 6/30/2011
How Do I Conserve Energy?
Frequency of Checks
Attac
k Su
rfac
e
Wha
t to
Chec
k
When to Check
• Frequency of Checks– When to check?– Scan less frequently– Timing vs events
• Attack Surface– What to check?– Scan fewer code/data
objects
8Mobisys 6/30/2011Mobisys 6/30/2011 8
Security-Energy Tradeoff
Frequency of Checks
Attac
k Su
rfac
e
• Scan all continuously– Best possible security– High energy cost
• Periodically Scan– Vulnerable between
scans
• Scan Subset– Vulnerable to attacks
outside of subset
Various Attacks
Is there a sweet spot?
9Mobisys 6/30/2011
Rootkits
App App App
Kernel Space
Libraries
Kernel Code
SystemCall
TableDrivers Process
Lists
AntiVirus
Rootkit
Virus
Rootkits are sophisticated malware requiring complex detection algorithms
UserSpace
10
Attacker Send SMSRootkit Infected
Dial me “666-6666”
Call AttackerTurn on Mic
Delete SMS
Rootkit stealthily hides from the user
Demonstrated AttackConversation Snooping Attack
Mobisys 6/30/2011
[Bickford et al. HotMobile ‘10]
11
Host Machine
Hypervisor
Trusted User OS
Detector
Rootkit Detection
Mobisys 6/30/2011
OS must be monitored using a hypervisor
• Detection tools run in trusted domain
• Mobile hypervisors soon– VMWare– OKL4 Microvisor (Evoke)– Samsung Xen on ARM
12Mobisys 6/30/2011
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
13Mobisys 6/30/2011
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
14
Detecting Data-Driven Attacks
Hypervisor
Guest domain Trusted domain
KernelCode
KernelData
Gibraltar daemon
InvariantDBData
page
2Reconstruct data structures
?3
Alert user
Mobisys 6/30/2011
Fetch Page1
15Mobisys 6/30/2011
Problem – High Energy Cost
while(1) { for all kernel data structures { get current value check against invariant }}
• Maximum security• 100 % CPU usage• Poor Energy Efficiency
IdleContinuous
Scan
Must tradeoff security for energy
16
Tradeoffs for Data-Based Detectors
Poll Frequency(seconds)
Attack Surface
0
Static Data
AllData
FunctionPointers
All Lists
Process List
1 5 30100 12050 10 1
Original design of Gibraltar
Frequency of ChecksMobisys 6/30/2011
Event Threshold: (page changes between checks)
17
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 }}
Mobisys 6/30/2011
Frequency of Checks
Idle Scan
18
Evaluating the Tradeoff
Sweet Spot!
Mobisys 6/30/2011
19Mobisys 6/30/2011
while(1) { for all kernel data structures { get current value check against invariant }}
Attack Surface
while(1) { for all kernel data structures { for a subset of data structures { get current value check against invariant }}
20
Evaluating the Tradeoff
96% of rootkits![Petroni et al. CCS ‘07]
Mobisys 6/30/2011
21
• 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
Detecting Code-Driven Attacks
22
Detecting Code-Driven Attacks
Hypervisor
Guest domain Trusted domain
Code: OS & applications Data
Patagonix daemon
HashDBCode
page
Resume guest
1
2
3
hash(page)
Alertuser
Mobisys 6/30/2011
?
23
Tradeoffs for Code-Based Detectors
0
AllCode
Root Processes
KernelCode
1 5 30341 12050 10 1
Original design of Patagonix
Poll Frequency(seconds)
Frequency of Checks
Event Threshold: (pages exec between checks)
Attack Surface
Mobisys 6/30/2011
24Mobisys 6/30/2011
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
Mobisys 6/30/2011
26
Thank You!
Mobisys 6/30/2011
Fully Secure
Select a security plan:
High risk
Low risk
Balanced
Learn how to conserve powerMore security options
Smart Phone Security Center
27Mobisys 6/30/2011
Randomization
Frequency of Checks
Attac
k Su
rfac
e
• Periodically scan
• Attackers will attempt to exploit the system while idle
• Randomize the time the system is idle
28
Cloud Offload Feasibility
Mobisys 6/30/2011
Cloud offload impractical energy-wise
