Mobile Systems and Smartphone Security�(MOBISEC 2020)

Prof: Yanick Fratantonio�EURECOM

1

Advanced Topics on Android System & Security

Today

• More details on Android system & security features

​

• Next: Complex Android features and APIs

2

Android Framework Architecture (reloaded)

3

Image from https://source.android.com/security

Android Framework Architecture (reloaded)

4

Image from https://source.android.com/security

App B

App A

Apps are sandboxed

Communication happens via well-defined interfaces exposed by the OS

Security checks

Security checks

Android Framework Architecture (reloaded)

5

Image from https://source.android.com/security

App B

App A

Instrumentation & analysis at these abstraction levels can be bypassed!

Pros: Syscall analysis CANNOT be bypassed

Cons: bridging the semantics gap is complicated [1]

[1] Exploring Syscall-Based Semantics Reconstruction of Android Applications

Building blocks for security

• Google security services

​

• Android OS / Linux kernel

​

• Device hardware

6

Google Security Services

7

Google Security Services

• Google Play
• A central place from where to install apps
• Developers and "apps on your phone" are linked via app signatures
• Community reviews, app security scanning, etc.

​

• Security Reports
• "Year in Review 20XX" reports
• https://source.android.com/security/overview/reports

​

8

Google Security Services

• Bug report / Triaging

​

• Process type
• Constrained process, Unprivileged process (third-party app), Privileged process (app with more privileged than unprivileged ones), Trusted Computing Base (TCB, part of the kernel, baseband processor, etc.), Bootloader, Trusted Execution Environment

​

• Local vs. Remote

​

• Severity: Critical, High, Moderate, Low

9

Google Security Services

• Android Updates
• Updates via the web or Over The Air (OTA updates)

​

• Monthly Security Updates
• A new security update every month (available via OTA)
• https://source.android.com/security/bulletin/index.html

​

10

Project Treble

• Android's core problem
• Fragmentation
• Many devices don't get updates
• The release update cycle is slow, especially for non-Google devices

​

• One core problem
• Previously: no clear interface between Android OS framework and vendor implementation
• When the Android OS is updated, vendors need to rework their parts
• This introduces delays

11

Project Treble

• Up to Android 7.x

12

Image from https://source.android.com/devices/architecture

Project Treble

• In Android 8.0+ (with Project Treble)

13

Image from https://source.android.com/devices/architecture

Google Security Services

• Application Services

​

• Frameworks that allow Android apps to use cloud capabilities

​

• Examples
• Backup service (doc)
• Cloud-to-device messaging (C2DM)
• Firebase Cloud Messaging (FCM) (doc)
• It allows "push" notifications from cloud to device

​

14

Google Security Services

• SafetyNet
• "A privacy preserving intrusion detection system to assist Google tracking and mitigating known security threats"
• It runs on all Google phones

​

• SafetyNet Attestation
• API to determine whether the device is "CTS compatible"
• CTS ~ "Android Compatibility Tests"
• It collects a software + hardware profile in a "trusted" way
• Check whether the app has been modified by an unknown source

​

15

Google Security Services

• Verify Apps
• System run by Google that continuously scan apps on the device
• Actually: continuously check the cached result of an app's analysis

​

• Android Device Manager
• Web app + Android app to locate lost / stolen devices
• Play sound, secure device (lock + display message), wipe device
• https://www.google.com/android/find

​

16

Kernel Security & SELinux

17

Linux Security

• A user-based permission model

​

• Process isolation

​

• Extensible mechanism for secure IPC

​

• The ability to remove unnecessary components

18

Linux's guarantees

• Prevents user A from reading user B's files

​

• Ensures that user A does not exhaust user B's memory

​

• Ensures that user A does not exhaust user B's CPU resources

​

• Ensures that user A does not exhaust user B's devices (e.g. telephony, GPS, Bluetooth)

​

19

The Application Sandbox

• Each app is isolated from each other
• How? Each app is assigned to a different user

​

• The sandbox is in the kernel
• Native code can't bypass it

​

• To bypass it, an attacker would need to compromise Linux

20

Defense in Depth

• Multiple layers of security controls are placed throughout a system

​

• It prevents single vulnerabilities from leading to compromise of the OS or other apps

​

• Rephrasing: redundancy

21

DAC vs MAC

• DAC: Discretionary Access Control
• Each resource has a list of users who can access it
• Permission is set by the data owner
• Example: Linux file permission, permissions on a social network

​

• MAC: Mandatory Access Control
• There are a number of levels, each user has a specific level
• A user can access all resources with non-greater level than hers
• Example: SELinux contexts, SELinux policies

22

SELinux

• Security-Enhanced Linux: a Linux kernel security module
• Useful to define access control security policies
• Example: allow/prevent execution of syscall X

​

• "Deny by default" policy

​

• Two modes
• Permissive mode: permissions denials are logged but NOT enforced
• Enforcing mode: permission denials are logged AND enforced

23

SELinux

• "SELinux domain"
• A label identifying a process (one or more)
• All processes labeled with the same domain are treated equal

​

• Early versions in Android: installd, netd, vold, and zygote

​

• Current version: 60+ domains

24

SELinux in Android 5.0

• MAC separation between system & apps

​

• Run in "enforcing" mode for the first time

25

SELinux in Android 6.0

• Makes the policy more restrictive / tighter domains

​

• IOCTL filtering
• Minimize exposed services

​

• Extremely limited /proc access

​

• SELinux sandbox to isolate across per-physical-user boundaries
• App's home dir default permissions changed from 751 to 700

26

SELinux in Android 7.0

• It broke up the monolithic mediaserver stack into smaller processes
• Before: if you exploit component X, you can control component Y

​

• Compartmentalization

27

SELinux in Android 8.0

• All apps run with a seccomp-bpf filter that limits syscalls that apps can use (attack surface reduction)

28

SELinux in Android 9.0

• Each app has an individual SELinux context

​

• It prevents apps from making their data world-writable

​

29

SELinux in Android X.Y?

• SELinux policies (and Android itself) are in constant evolution

​

• Things that work now may not work in the future

30

Boot and Verified Boot

31

The boot process and Verified Boot

• The system boots in "stages"
• Each stage loads and verifies the next one

​

​

32

Boot ROM

Secondary Boot Loader (SBL)

Android Boot Loader

(aboot)

ROM: Read-Only Memory

Linux Kernel

Initramfs,�Android framework

Can be upgraded

It cryptographically verifies aboot via key stored in ROM

Root of the chain of trust!

It can be unlocked!

It cryptographically verifies SBL via key stored in ROM

Root of the chain of trust!

The boot process and Verified Boot

• "Unlock bootloader"
• aboot will NOT enforce the chain of trust over the subsequent stages
• That's how you can install custom mods, etc.

​

• aboot itself CANNOT be changed
• Well, you can. But SBL will not load it. High risk of bricking the device.

​

• Same for the other partitions (boot, system)
• You can change them, but if aboot is locked, it refuses to load them

​

• Not all devices allow bootloaders to be unlocked

33

fastboot

• fastboot is a tool / protocol for writing data directly on the device's memory

​

• $ fastboot devices
• $ fastboot flash system system.img
• This flashes system.img to the system partition

​

• It's "implemented" in aboot... pay attention

34

Example: How to unlock Pixel 3's bootloader

• Boot device in "bootloader mode" (or "fastboot" mode)
• Technique #1
• press power + volume down button while booting
• a special menu will appear
• Technique #2
• $ adb reboot bootloader # This tells the device 'go in bootloader mode'

​

• $ fastboot flashing unlock

​

• Check the device's screen: confirm to unlock

35

Additional security mechanisms

• Device's data is wiped upon bootloader unlock
• If an attacker could unlock and flash custom Android, she could read all user's data, etc.

​

• If unlocked, the bootloader shows a warning to the user every time the device boots
• The user has a chance to understand "something may be off"
• This logic is in aboot, the attacker can't change it

36

Additional security mechanisms

• By default, you cannot unlock the bootloader

​

• "Allow OEM unlocking" settings
• It's in the "developer options" 'hidden' menu
• Settings ~> System ~> About phone ~> Tap on "build number" 7 times
• Developer options ~> Allow OEM unlocking (this may ask for PIN)
• Developer options ~> Allow USB debugging

​

• If a thief steals my phone, she can't do anything with it

37

Device State

• The "device state" indicates how freely software can be flashed to a device and whether verification is enforced

​

• Possible states: LOCKED and UNLOCKED

​

• LOCKED devices boot only if the OS is properly signed by the root of trust

38

dm-verity (doc)

• Kernel feature to provide transparent integrity checking of block devices
• It maintains a cryptographic hash tree

39

Image from here

Rollback Protection

• A non-persistent malware could install an older vulnerable version of Android...

​

• ... and then install a persistent exploit

​

• Rollback protection: It records the most recent version of Android and it refuses to boot an older one

40

Flash new image

• You can flash each partitions with new data

​

• $ fastboot flash system system.img

​

• Factory images from Google (link) come with a flash-all.sh script

41

flash-all.sh

$ cat flash-all.sh

​

fastboot flash bootloader bootloader-bullhead-bhz10m.img

fastboot reboot-bootloader

sleep 5

fastboot flash radio radio-bullhead-m8994f-2.6.31.1.09.img

fastboot reboot-bootloader

sleep 5

fastboot -w update image-bullhead-mhc19q.zip

42

image-bullhead-mhc19q.zip

$ unzip -l image-bullhead-mhc19q.zip

Length Date Time Name

--------- ---------- ----- ----

101 2009-01-01 00:00 android-info.txt

2005102896 2009-01-01 00:00 system.img

11793638 2009-01-01 00:00 boot.img

195274360 2009-01-01 00:00 vendor.img

12870890 2009-01-01 00:00 recovery.img

5824660 2009-01-01 00:00 cache.img

139966976 2009-01-01 00:00 userdata.img

--------- -------

2370833521 7 files

​

​

43

Many partitions

• boot
• It contains a kernel image
• ramdisk: small partition, /init & config files, mount other partitions
• system
• It contains everything that is mounted at /system
• Android framework, system apps
• vendor: Binary that is not part of AOSP
• userdata: It contains everything that is mounted at /data, third-party apps
• radio: the 'radio' image, super sensitive, run on its own processor
• recovery: like boot, but for 'recovery mode'

44

Recovery mode

• Two modes of booting your device
• Go in bootloader mode ~> then choose "start" vs. "recovery mode"

​

• "Normal mode"
• The system you are used to know, Android OS, etc.
• boot partition ~> system ~> vendor / userdata

​

• Recovery mode
• By default, empty (at least on my Nexus 5X)
• Very basic system to perform "admin" operations
• Once the bootloader is unlocked, you can flash what you want here

45

TWRP

• Team Win Recovery Project (TWRP) is a custom recovery image for Android-based devices.

​

• https://dl.twrp.me/

​

• $ fastboot flash recovery <twrp.img>

46

Protection of System Partition

• The "system" partition contains Android's kernel, OS libraries, application runtime, "the framework", and pre-installed apps

​

• The "system" partition is read-only

​

• It helps preventing attacker's persistence on the device

47

Safe Mode

• You can boot the device in "safe mode"
• Usually: press device's power button + volume down button when the animation starts

​

• In safe mode, third-party apps are not started automatically
• But they can be launched "manually" by the owner

​

• It prevents user-space attacker's persistence

48

What if there are bugs?

• What if there is a bug in aboot?
• What if there is a bug in Boot ROM?

​

​

49

Boot ROM

Secondary Boot Loader (SBL)

Android Boot Loader

(aboot)

ROM: Read-Only Memory

Linux Kernel

Initramfs,�Android framework

Can be upgraded

It cryptographically verifies aboot via key stored in ROM

Root of the chain of trust!

It can be unlocked!

It cryptographically verifies SBL via key stored in ROM

Root of the chain of trust!

unpatchable checkm8 exploit for iOS bootrom!

Data Encryption

50

Data encryption (doc)

• User-created data are encrypted before writing to disk

​

• Full-disk encryption (Android 5.0+)
• One single key protected by the user's device password
• The user must provide her credentials upon boot
• UX problems: nothing works without password, not even alarm clocks
• What if the user changes her password? Not a problem...

51

Data encryption (doc)

• File-based encryption (FBE) (Android 7.0+)
• Files are encrypted with different keys, which can be unlocked independently
• Apps can work in a limited context before full unlock
• It makes work profiles more secure: not only one "boot-time password"

52

Metadata Encryption

• FBE encrypts file contents and names

​

• FBE does NOT encrypt other informations
• Directory layout, file sizes, permissions, timestamps

​

• Android 9 has support for metadata encryption
• It encrypts whatever is not encrypted by FSE
• It needs hardware support

53

Direct Boot (doc)

• Direct Boot mode when the device has been powered on but the device is still locked

​

• Apps have two storage location for data
• Credential encrypted storage
• Decrypted only when the user unlocks the device
• Device encrypted storage
• Available both during Direct Boot and unlocked device
• Still secure!

54

Device Admin and Work Profiles

55

Device Admin Apps

• An app can act as "device admin"

​

• It can specify security policies
• Password enabled / minimum password length
• Require storage encryption, disable camera

​

• When enabled
• The policies are enforced
• Device admin app can: wipe data, force lock, reset password
• The user gets some benefits: Access to work VPN, ability to sync data

56

Work profile

• Device admin is in the process of being deprecated

​

• Android supports "work profiles" (doc)
• Admins can manage a self-contained work profile on user's device
• Corporate apps & data are restricted to work profile
• They are secure and separated from personal data (and viceversa!)

​

• Work admins have remote control over the work profile

57

TrustZone

58

ARM TrustZone

• I've always drawn the system as userspace + kernelspace

​

• I have lied, it's more complex than that

59

ARM TrustZone

60

Image from ARM

ARM TrustZone

61

User space

Kernel space

Non-Secure World

Secure World

Untrusted Apps (UA)

(System apps, 3rd-party apps)

Untrusted OS�(Linux, Android OS)

Trusted OS

Trusted Apps (TA)

• KeyMaster
• Fingerprint API
• DRM
• Confirmation API

Secure even if the Linux/Android OS is compromised!!!

Library API

Driver Interface (ioctl)

TEE Interface

Unlocking phones with your nose

62

BSides DC 2018 - Nick `mike_pizza` Stevens - Bypassing Huawei's Fingerprint Authentication by Exploiting the TrustZone (Nose Injection Exploit @ 46.44)

Verified Boot (reloaded)

63

Image from BootStomp, USENIX Security 2017 (link)