• No results found

Smartphone Security pr. Sven Bugiel

N/A
N/A
Protected

Academic year: 2021

Share "Smartphone Security pr. Sven Bugiel"

Copied!
53
0
0

Loading.... (view fulltext now)

Full text

(1)

Smartphone Security

20-00-0615-pr

(2)

Organizational: Teams

2-3 Students per team

 Register your team by eMail to me

 Names, Student IDs, and eMail addresses of all team members

 Preferred and backup topic

 Deadline: Wednesday, October 31st

 Confirmation of the topic on the same (or next) day, depending on number of conflicts, RNG seed, and your discipline to adhere to the deadline

Maximum of two teams per topic

(3)

Organizational: Dates

Midterm report

 Progress report by each team

 Short (4-6 pages)

 Deadline: Friday, December 14th !!!

Final report and code submission

 10-15 pages report + zipped code ( or diff file)

 Clearly stating for which part which team members were responsible

 Deadline: Friday, February 15th

Concluding meeting and presentations

 Short presentation (10-15 min) of each team’s results

 Every team member has to speak

 Date: TBA

(4)

Today‘s Agenda

Introduction

Android Software Stack

Android Security Mechanisms Selected Attacks

Projects Proposals

(5)

Smartphones Applications Today

5 Mobile Phone Features Call, SMS, MP3, Video Interfaces

GPS, WiFi, Bluetooth, Infrared, NFC

Online Services

Browsing, E-Mail, E-Shopping, Social Networking

Location Services

(6)
(7)

Threat Classification

7

Attacks on Privacy

Location, E-Mail, Contacts

Runtime Attacks

Code Injection, Return-Oriented Programming

Hardware Attacks

GSM Module, Base Station

Malware

Trojans, Viruses, Worms

Attack

Vectors

(8)
(9)

Big Picture

9

(10)

Linux Kernel

10

 Standard Linux kernel (2.6.32 for Android 2.2.x “Froyo”; 3.1.10 for Android 4.1.x “Jelly Beans”)

 Patches for Android (e.g., aggressive Power Management, Logger, Binder)

 Binder:

 High-performance, shared memory based IPC

 Synchronous calls between processes

 Per-process thread pool for processing requests

(11)

Native Libraries

11

 C/C++ libraries

 Exposed to developers through the Android application framework

 Core libraries include:

 Libc (Bionic)  Media libraries  Surface Manager  3D libraries  SQLite  SSL

(12)

Android Runtime

12

 Dalvik Virtual Machine

 VM optimized for embedded environments

 Runs optimized file format “.dex” and Dalvik bytecode generated from Java .class/.jar files at build time

 Relies on underlying Linux kernel for threading and low-level memory management

 Core Libraries

 Provide most of the functionality available in the core libraries of Java

(13)

Application Framework

13

 Provides developers API to basic functionalities and services (e.g., set alarms, access location information, take advantage of device HW,…)

 App  Service (App. Framework)  lib

 App  Service (App. Framework)  Native Service  lib

 App  Service (App. Framework)  Native Daemon  lib

 APIs are the same as for the core applications (e.g., Phone, Contacts,…)

 Activity Manager

 Enforces permissions on IPC (“Reference Monitor”)

 Responsible for starting applications

 Package Manager

(14)

App

Runtime Service

lib

(15)

App

Runtime Service

lib

(16)

App  Runtime Service  Native Service  lib

(17)

App  Runtime Service  Native Service  lib

(18)

App  Runtime Service  Native Daemon  lib

(19)

App  Runtime Service  Native Daemon  lib

(20)

Applications

20

 Third party applications (e.g., Android Market)

 A number of core (“system”) applications (cannot be uninstalled)

 Contacts

 Settings

 Browser

 …

 Components of applications

 Activity: User interface

 Service: Background service

 Content Provider: SQL-like database

 Broadcast receiver: Mailbox for broadcasted messages

 Applications can contain native code (C/C++ shared libraries)

 For simplicity, Binder-based IPC between components often called “ Inter-Component Communication

(21)
(22)

Sandboxing

22

General Idea

The application sandbox specifies which system resources the application is allowed to access

An attacker can only perform actions defined in the sandbox

(23)

Application Isolation by Sandboxing

Each application is isolated in own sandbox  Applications can access only own resources

 Access to sensitive resources depends on the application’s capabilities (“permissions”)

Sandboxing is enforced by Linux

 Each App is assigned a unique UserID and runs in separate process

 Each App has a private data folder

(24)

Android Installer:

Installation of a Benign App

Android Market User Install Requested permissions are reasonable Permissions Movie Player Download App 24
(25)

Android Market

User Why does this app

requests permission to send SMS?

Permissions

Malicious Movie Player

Download app

Deny install

25

Android Installer:

(26)

Android Permission System

Applications (UIDs) are assigned permissions

Permissions are needed to control access to

 System resources (logs, battery, etc.)

 Sensitive data (SMS, contacts, e-mails, etc.)

 System interfaces (Internet, send SMS, etc.)

Application (developers) can also define own permissions to protect application interfaces

Permissions are either

 Simply associated strings (most permissions)

 Mapped to Linux GIDs (few: Internet, Bluetooth, ext. storage,…)

(27)

Android Permissions: Example

27

App A is allowed to send SMS (P1)

App A also holds permission P2 (e.g., access location)

App B has two interfaces

protected by permission P2 and P3 App B App A Perm. P1 Perm. P2 Perm. P2 Perm. P3

(28)

Permission Enforcement

Binder provides certain information to the callee of IPC

 getUID(): returns caller’s UID

 getPID(): returns caller’s PID

System enforces permission check upon IPC call

 checkPermission(String Perm): checks if caller has

been granted the permission “Perm”

 Can also be called by applications themselves

(29)
(30)

Do you understand “Permissions”?

(31)

Requesting dangerous permissions

31 android.permission.INTERNET android.permission.ACCESS_COARSE_LOCATION android.permission.READ_PHONE_STATE android.permission.VIBRATE com.android.launcher.permission.INSTALL_SHORTCUT android.permission.ACCESS_FINE_LOCATION android.permission.CALL_PHONE android.permission.MOUNT_UNMOUNT_FILESYSTEMS android.permission.READ_CONTACTS android.permission.READ_SMS android.permission.SEND_SMS android.permission.SET_WALLPAPER android.permission.WRITE_CONTACTS android.permission.WRITE_EXTERNAL_STORAGE com.android.browser.permission.READ_HISTORY_BOOKMARKS com.android.browser.permission.WRITE_HISTORY_BOOKMARKS android.permission.ACCESS_GPS android.permission.ACCESS_LOCATION android.permission.RESTART_PACKAGES android.permission.RECEIVE_SMS android.permission.WRITE_SMS android.permission.INTERNET android.permission.ACCESS_COARSE_LOCATION android.permission.READ_PHONE_STATE android.permission.VIBRATE Geinimi Trojan 2010

User has to confirm requested permissions

(32)

The really dangerous permissions are reserved for the System

Components / Apps

Bad news:

Android’s Security Framework is prone to privilege escalation

attacks

32

(33)

Application-level

Privilege Escalation Attacks

Confused

deputy

attacks

Attacks by

colluding

applications

33
(34)

Android Middleware

Application-level

Privilege Escalation Attacks

34

Scenario 1:

Confused deputy attack

App B App A

Unprivileged Privilege P1

Examples:

1) Invoke browser to download malicious files (Lineberry et al., BlackHat 2010)

2) Unauthorized phone call

(Enck et al., TechReport 2008)

A privileged program is fooled into misusing its privileges on behave of another (malicious) unprivileged program.

(35)

Google Android:

Communication with web servers without possessing INTERNET Permission

Malicious App 0 Permissions

Android Web Browser

INTERNET Permission

1) Ask Browser for data transfer from a remote server

2) Browser forwards request 3) Files are transmitted to SD card

(36)

Android Middleware

Application-level

Privilege Escalation Attacks

36 App B Android Core App A Scenario 2: Collusion attack Privilege P1 Privilege P2

1) Apps communicate directly

2) Apps communicate via covert (e.g., volume settings) or overt (e.g., content providers) channels in AndroidCore

Example: Soundcomber (Schlegel et al.,

NDSS’2011)

Malicious apps collude in order to merge

their respective permissions

(37)

Google Android:

Soundcomber: A stealthy and context-aware sound Trojan

APP_A

Permission:

Record Audio

1) Call Credit Institute

2) Credit Card Number is extracted from the speech

37

APP_B

Permission:

(38)

Soundcomber Internals

Exploiting Covert Channels in Android

APP_A Permission: Record Audio 38 APP_B Permission: Internet Volume Setting Android Core Application Write Read

(39)

39

Reference Monitor a) IPC / RPC / Sockets

(Example: Davi et al., 2010)

a) Root exploit

(Example: DroidDream Trojan 2011)

Application-level

Privilege Escalation Attacks

Scenario 3:

(40)
(41)

Update attack

41

1. Install App 2. App triggers Update 3. Deploy malicious update

4. Load update (dynamically) 5. Perform malicious action

8/23/2012

(42)

Rootkit

Example: Interposing communication with GSM Modem

42 Phone / SMS App System Call Table sys_open sys_reboot sys_read Hardware GSM Modem List of modules List of processes

List network connections

Middleware

8/23/2012

(43)

TapLogger / TouchLogger

Infer user’s input to virtual keyboard by measuring the accelerometer and gyroscope during typing

[Xu et al., WiSec 2012; Cai et al., HotSec 2011]

43

S A F E

(44)

Projects Proposals in a Nutshell

(see course material for details)

(45)

Confused Deputy Finder

Develop a tool to detect whether a 3rd party

app unintentionally leaks security/privacy sensitive data.

Preferred implementation based on blackbox

testing

Alternative approach: Using static analysis frameworks.

(46)

Data Shadowing

Extend the query interface of 1-2 selected system ContentProviders (e.g., Contacts and SMS), such that a very fine-grained data

filtering is possible:

 Per-row: Is access to an entire contact/SMS allowed,

e.g., because he belongs to a certain group like “work”?

 Per-column: Should certain information of a

contact/SMS (e.g., phone number) not be returned?

 Per-cell: Combination of the both above

(47)

Data Exfiltration

Use the TaintDroid framework to prevent security/privacy sensitive data from being exfiltrated.

Very similar to AppFence architecture, so

difference should be made clear (NO PLAGIATISM!)

(48)

SEAndroid Multi-Level Security

Extend the Mandatory Access Control of

SEAndroid from the kernel into the middleware level by extending strategically important API with policy enforcement hooks and adding the corresponding security types to SEAndroid’s

default definitions.

(49)

KeyChain Extension and Integration

KeyChain is a central credential storage on Android 4.X

Extend this service with

1. Support for new crypto credentials and a

functionality to encrypt/sign data without the need to reveal the key (“crypto service”)

2. Use this new functionality by integrating the

KeyChain into Contacts (i.e., connect a contact with a key for its ID) and SMS (i.e., use the stored key of the recipient to encrypt the SMS and hence enable encrypted SMS)

(50)

Enhanced Installer

Extend the Android default installer with new security features to check whether an

installation is allowed

1. Based on static properties of apps (e.g., developer signature and requested permissions)

2. Based on dynamic properties of the system (e.g., which permissions inherits the new app due to a shared UID)

3. Based on a very simple virus scan to detect if the App’s native code contains, e.g., a root exploit, etc.

(51)

Blue Pill / KeyLogger

Develop malicious versions of the default

Launcher and Keyboard app which are able to

hide/re-link installed apps or log the user’s input, respectively

Consider how security mechanisms like the “Home” button can be prevented or the user be tricked into “taking this blue pill”

(52)

Rootkit

Develop a rootkit which can interpose on the communication with high-value low-level

targets such as rild in order to compromise the system security and which is able to

communicate with a control server

Consider how the rootkit could be made

persistent

(53)

References

http://developer.android.com http://source.android.com http://source.android.com/source/using-eclipse.html http://www.kandroid.org/online-pdk/guide/build_system.html

Android tutorials by MarakanaTech on Youtube

Books:

 Manning: Android in Action

 Hashimi: Android 2

http://www.malgenomeproject.org/

http://stackoverflow.com

References

Related documents