Android Security, the Fun

Details

Jesse Burns

Hashdays 2010
Lucerne, Switzerland

Android is a trademark of Google Inc.

https://www.isecpartners.com Use of this trademark is subject to Google Permissions.
Agenda
 Android Security Model Overview
 Process, not Java sandbox
 Permissions, Services Activity & Package Manager
 Binder
 Updates
 Exploring Privileges
 System Packages
 Shell, Debug Intent sender
 Restrictions
 Conclusion

2
More Android Devices
http://en.wikipedia.org/wiki/List_of_Android_devices
Wikipedia’s list of over 60 existing Android based
smartphones, two dozen tablets and a few e-book
readers.
Additionally over two dozen “upcoming” smart phones,
and over three dozen tablets.

Google TV:
Android based with market apps next year

3
Android Security Overview
Process, not Java Sandbox
Permissions, Services, Activity & Package Manager
Binder
Updates
Application VS. Radio or Network

Wireless Network Protocols

5
Android Uses a Process Sandbox
 Applications are isolated
 Linux + Android’s Permissions
 Distinct UIDs and GIDs assigned on install
 Native vs. Java code doesn’t matter

6
Android Security Model
 Android is not the Java security model:
 No Security Manager, no Java Sandbox
 Dalvik NOT a security barrier

 This is not the iPhone security model:

 Platform permissions restrict applications
 Very open for development & customization

 Closest to OS user isolation, but each app is a user

 Usually supports OTA updates

7
Android Security Model
 Rights expressed as Permissions & Linux groups!

8
Android Permissions
 Permissions are granted to applications
 Strings like “android.permission.READ_CONTACTS”

 Descriptions, protection levels, group

 Must be meaningful to normal people
 i.e. “Read Contacts” good
 “Execute Native Code” meaningless to normal people

 Dalvik is not a security boundary, native code isn’t

special

9
Android Permissions
 Built-in applications are called “system”
 ls –l /system/app/*.apk

 No user approval needed

 Uninstalling not allowed
 Read only partition
/dev/block/mtdblock3 /system yaffs2 ro,relatime 0 0

10
Android’s Main Building Blocks
 Activities – Screens that do something, like the dialer
 Services – background features, like the IM service
 Broadcast Receivers – actionable notifications (startup!)
 Content Providers – shared relational data

All secured with Android Permissions like:

“android.permission.READ_CONTACTS” or
“android.permission.BRICK”
See Manifest.permissions and AndroidManifests near you
Coordinated through Activity Manager

11
Activity Manager
 Manages the starting of applications
 Enforces permissions
 Sending / receiving broadcast intents
 Starting activities / Intent dispatching
 Starting services / Intent dispatching
 Accessing content providers

Can kill, manage processes:

KILL_BACKGROUND_PROCESSES

12
Package Manager
 This is the system’s software manager
 “Package name” is the true name of an app
 Package Play tool uses this
 Allows review of installed software, rights,
signatures, etc
 Performs permission checks, management
 Performs signature checks
 Modification of this would allow custom control of
permissions

13
Enforcing Permissions
 User approval can allow enforcement of permissions
 For example, the AccountManager System Service
 Coordinates centralized storage of credentials

14
Binder as IPC
 Kernel mode IPC mechanism
 Similar to Unix domain sockets
 Supports moving:
 Primitive types
 Parcelable objects
 File Descriptors
 Binders (a reference to a binder interface)

15
Binder Interface Permissions
 Services exposing a binder interface can inspect
callers using:
android.content.Context checkCallingPermission()

 Allows enforcement of permissions thusly:

16
Binders as Capabilities
 When a (strong) Binder is marshalled
 Kernel validates the sender had binder
 Recipient validates kernel asserted this

 Allows us to have Binders that can’t be forged

 Allows sharing them

Window Manager
 Surfaces, LayoutParam Tokens, Application Token

17
Android’s Attack Surfaces
• Isolated applications is like having multi-user system
• Single UI / Device  Secure sharing of UI & IO
• Principal maps to code, not user (like browsers)
• Appeals to user for all security decisions i.e. Dialer
• Phishing style attack risks.

• Linux, not Java, sandbox. Native code not a barrier.

• Any java app can exec a shell, load JNI libraries, write
and exec programs – without finding a bug.

18
Accessing Binder Interfaces
Need to get a binder somehow.

ServiceManager – runs off the “Context Object”

• Exposes getService(), listServices(), etc.

These are “System Services”

Unrelated to “Service” subclasses

19
 System Services
>adb shell service list
Found 51 services:
0 phone: [com.android.internal.telephony.ITelephony]
1 iphonesubinfo: [com.android.internal.telephony.IPhoneSubInfo]
2 simphonebook: [com.android.internal.telephony.IIccPhoneBook]
3 isms: [com.android.internal.telephony.ISms]
4 diskstats: []
5 appwidget: [com.android.internal.appwidget.IAppWidgetService]
6 backup: [android.app.backup.IBackupManager]
7 uimode: [android.app.IUiModeManager]
...
11 dropbox: [com.android.internal.os.IDropBoxManagerService]
…

20
System Service Attack Surface
 Some are trivial IClipboard.aidl – ClipboardService
Or “clipboard” to getService()
 CharSequence getClipboardText();
 setClipboardText(CharSequence text);
 boolean hasClipboardText();

21
Updates
• Android Applications are signed
• Updates are just new builds – which are also signed
• Package Manager is part of Android
• Market is not

• Applications install over old version

• Mismatched signatures results in update failure

22
Updates - Signatures
 Android Signatures don’t identify users

 Market registration involves a small payment

 This isn’t “Android” it is Google’s Android Market

23
Exploring Privileges
System Packages
Shell, Debug Intent Sender
Restrictions
System Packages
 Installed by manufacturers or carriers
 Can’t be uninstalled
 Have access to “signatureOrSystem” permissions:
 WRITE_SECURE_SETTINGS
 INSTALL_PACKAGES
 DELETE_PACKAGES
 MASTER_CLEAR
 Can be enumerated:
adb pull /data/system/packages.xml
… or .. ls /system/app

25
System Packages
 List of system packages (ls /system/app/*.apk)
 Pull them off device (adb pull /system/app/…)
 Use APKTool or Manifest Explorer
 Extract AndroidManifest.xml
 Review permissions

26
System Packages - Reviewing
 android:debuggable=“true”
 Lets you debug with DDMS or see “runas”
 android:sharedUserId
 Lets that program run with other programs rights!
 Permissions to access your contacts?
 Settings’ DebugIntentSender (running as system)
find –name AndroidManifest.xml | xargs grep –A 1
SECRET_CODE

27
System Packages - Reviewing
 android:debuggable=“true”
 Lets you debug with DDMS or see “runas”
 android:sharedUserId
 Lets that program run with other programs rights!
 Permissions to access your contacts?
 Settings’ DebugIntentSender (running as system)
find –name AndroidManifest.xml | xargs grep –A 1
SECRET_CODE

28
System Packages - Reviewing
Nexus One Example:
find –name AndroidManifest.xml | xargs
grep secret_code
./CalendarProvider/AndroidManifest.xml: <data
android:scheme="android_secret_code" android:host="225" />
./GoogleServicesFramework/AndroidManifest.xml: <data
android:scheme="android_secret_code" android:host="2432546" />
./GoogleServicesFramework/AndroidManifest.xml: <data
android:scheme="android_secret_code" android:host="46" />
./GoogleServicesFramework/AndroidManifest.xml: <data
android:scheme="android_secret_code" android:host="7867" />
./Settings/AndroidManifest.xml: <data
android:scheme="android_secret_code" android:host="4636" />
./Talk/AndroidManifest.xml: <data
android:scheme="android_secret_code" android:host="8255" />
./VoiceDialer/AndroidManifest.xml: <data
android:scheme="android_secret_code" android:host="8351" />
./VoiceDialer/AndroidManifest.xml: <data
android:scheme="android_secret_code" android:host="8350" />

29
System Packages - Reviewing
G2 Example:
find –name AndroidManifest.xml | xargs
grep secret_code
./CalendarProvider/AndroidManifest.xml: <data android:scheme="android_secret_code" android:host="225" />
./CheckinProvider/AndroidManifest.xml: <data android:scheme="android_secret_code" android:host="682" />
./CheckinProvider/AndroidManifest.xml: <data android:scheme="android_secret_code" android:host="682364" />
./CheckinProvider/AndroidManifest.xml: <data android:scheme="android_secret_code" android:host="682226" />
./CheckinProvider/AndroidManifest.xml: <data android:scheme="android_secret_code" android:host="682668" />
./DebugTool/AndroidManifest.xml: <data android:scheme="android_secret_code" android:host="5382" />
./debug_tool/DebugTool/AndroidManifest.xml: <data android:scheme="android_secret_code" android:host="5382" />
./FieldTest/AndroidManifest.xml: <data android:scheme="android_secret_code" android:host="7262626" />
./GoogleServicesFramework/AndroidManifest.xml: <data android:scheme="android_secret_code"
android:host="2432546" />
./GoogleServicesFramework/AndroidManifest.xml: <data android:scheme="android_secret_code" android:host="46" />
./GoogleServicesFramework/AndroidManifest.xml: <data android:scheme="android_secret_code" android:host="7867"
/>
./QxdmLog/AndroidManifest.xml: <data android:scheme="android_secret_code" android:host="564" />
./Settings/AndroidManifest.xml: <data android:scheme="android_secret_code" android:host="4636" />
./Talk/AndroidManifest.xml: <data android:scheme="android_secret_code" android:host="8255" />
./VoiceDialer/AndroidManifest.xml: <data android:scheme="android_secret_code" android:host="8351" />
./VoiceDialer/AndroidManifest.xml: <data android:scheme="android_secret_code" android:host="8350" />

30
Shell
 Shell is the account ADB runs as
 Rights in /system/etc/permissions/platform.xml
 Including:
 WRITE_SETTINGS
 WRITE_SECURE_SETTINGS
 INSTALL_PACKAGES
 DELETE_PACKAGES
 BACKUP

31
Shell’s Limitations
am start -n
android/com.android.server.ShutdownAct
ivity
Starting: Intent {
cmp=android/com.android.server.ShutdownActivity }
java.lang.SecurityException: Permission Denial:
starting Intent { flg=0x10000000
cmp=android/com.android.server.ShutdownActivity }
from null (pid=497, uid=2000)
requires android.permission.SHUTDOWN

32
DebugIntentSender
am start -n com.android.settings/.DebugIntentSender

For example:
android.intent.action
.ACTION_REQUEST_SHUTDOWN

33
Exploratory Tools
 Logcat or DDMS or the “READ_LOGS” permission!
 Android SystemProperties - property_service
 Dropbox – dumpsys dropbox
 Linux
 /proc
 /sys (global device tree)
 /sys/class/leds/lcd-backlight/brightness
 dmesg i.e. calls to syslog / klogctl
 syscall interface
 File system o+r or groups we can join
 APKs in /system/app

34
Exploratory Tools
 /data/system/packages.xml
 Details of everything installed, who shares
signatures, definitions of UIDs, and the location of
the install APKs for you to pull off and examine.
 /proc/binder – the binder transaction log, state, and
stats
 /proc/binder/proc/
 File for each process using binder, and details of
every binder in use – read binder.c
 /dev/socket – like zygote and property_service
 /system/etc/permissions/platform.xml

35
Exploratory Tools
 DUMP permission – adb shell or granted

 dumpsys – dumps every system service

ServiceManager.listServices()
Example from “activity.provider” dump:
Provider android.server.checkin…
package=android process=system…uid=1000
clients=[ProcessRecord{4344fad0
1281:com.android.vending/10025}, ProcessRecord{433fd800
30419:com.google.process.gapps/10011},
ProcessRecord{43176210 100:com.android.phone/1001},
ProcessRecord{43474c68 31952:com.android.calendar/10006},
ProcessRecord{433e2398 30430:android.process.acore/10008}]

36
Exploratory Tools
 Android Manifest aka AndroidManifest.xml
 Not only does the system have one, but every app
 Defines exported attack surface including:
 Activities, Services, Content Providers,
Broadcast Receivers, and Instrumentations
 SystemServices / those privileged System APIs
 Primarily what my tools use
 Package Manager - “package” service
 Activity Manager – “activity”
 Some non-services like Settings

37
Package Signing
 Jar signing is tracked by Android
 Updates and rights controlled by matches
 Cross-app sharing may not be clear
 Doesn’t use public x509 PKI
 Transport for apps or markets may
 Perhaps useful in malware identification

38
Permissions
 Permissions need to be understandable
 When they are, users can make real choices
 Read Contacts or Access Internet are a choice
 “execute native code” is not
 The “user” is too coarse grained an principle
 Imagine if CNN could access your Intranet or Gmail
 Tetris shouldn’t be able to read my mail
 Simple applications can proliferate
 An authority can substitute for technical protections
like permissions

39
Ineffective Restrictions
 People get root on their devices
 Jailbreaking, breaking root
 If you make it hard, people write convenient exploits
 Undermines the whole systems security
 Once root is broken, updates are stopped

 15 year olds are smart

 They can break CSS on DVDs
 They can create proxy flashlights
 CA signed code compatibility problems

40
Effective Restrictions
 Blocking kernel patching stops legitimate AV

 No hook based AV systems on Android yet

 Little - no malware exploiting this lack of AV

 Opportunity for enterprise specific restrictions

41
Conclusion
Auditing Solutions
Restricting Applications
Permissions
 Android Permissions are too complex
 Other solutions are even worse
 Android not designed to restrict native code

 Repackaging applications causes security exceptions

 Prompting ala APEX is complex and ugly

 Dangerous tradeoff: security – convenience

60
Root lockdown
Carriers or Manufacturers
• Locking down the phone means securing for – not
against users. Don’t pick a fight with customers.
• People with root won’t upgrade & fix systems
• Schemes for maintaining root are dangerous

Market Enabler – little program to enable market

• Needs root to set system properties
• Only asks for “INTERNET” permission
• For this to work the Linux sandbox was defeated

61
Proprietary bits
• Radio firmware is private & highly privileged
• Many WiFi cards are similar – GPL purity combat
• Computer bios too
• Think about the phone switches on the backend
• Do you really know what’s in the heart of your CPU
• Do you even know what VPRO is?
Keep perspective & a disassembler
Search the net for platform documentation

62
Common Problems
• Implicit vs. Explicit Intents
• Too many or few permissions
• Data source & destination
• Who sent this broadcast
• Who might be able to see this
• Trusting external storage (Fat-32 no security for you)
• Users with unpassworded setuid root shells, su, etc.
• Implementing non-standardized features
• OTA updates, application distribution & update

63
Protected Broadcasts
• Added in Donut (1.6), with little comment
• Reminder that security requires staying up to date.

Cupcake – 0 Protected Broadcasts

Donut – 25
Éclair – 45, added: Backup, Bluetooth, and Locale
Froyo – 50, added: Modes, DOCK_EVENT

64
Questions?

65
Questions?
Incase you need some sample questions:
 What do protected broadcasts solve?
 What is Intent reflection?
 How would I secure a root shell for users of my
distribution of Android?
 What’s the deal code signing that doesn’t require a
trusted root?
 What’s the parallel between the browser security
model and the Android security model?

66
 Thank you for coming!
Want a copy of the presentation/tool?

Email:
[email protected]