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

Email

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