![About
Aleksandar
(Saša)
Gargenta
• Developing
in
Java
since
1996
–
mostly
server-‐side
• Hacking
Android
since
2008
–
from
the
SDK
to
the
kernel
• Teaching
Java,
Android,
etc.
at
Marakana
since
2005
– h"p://marakana.com/
• Founder
&
Organizer
of
San
Francisco
Java
User
Group
– h"p://www.sZava.org/
• Founder
&
Organizer
of
San
Francisco
Android
User
Group
– h"p://www.sfandroid.org/
• Co-‐founder
&
co-‐organizer
of
San
Francisco
HTML5
User
Group
– h"p://www.s]tml5.org/
• Wri_ng
a
book
Android
Internals
for
O'Reilly
(ETA?
yesterday)
• Worked
on
SMS,
MMS,
WAP
Push,
but
also
Linux
and
system
administra_on
in
past
life](https://image.slidesharecdn.com/securingandroid-111010042411-phpapp01/75/Securing-Android-2-2048.jpg)
![[Physical]
Access
Control
• Screen
unlock
pa"ern,
pin,
password
• More
op_ons
with
device
admin
(including
password
expira_on,
encryp_on,
auto-‐device-‐wipe,
etc.)
• Low-‐level
access
to
SIM
card
is
not
available
to
apps
• But:
" SIM/SD
Card
can
be
simply
ejected,
bypassing
screen
unlock
" Cold-‐boot
a"acks](https://image.slidesharecdn.com/securingandroid-111010042411-phpapp01/75/Securing-Android-25-2048.jpg)
More Related Content
![[Wroclaw #1] Android Security Workshop](https://cdn.slidesharecdn.com/ss_thumbnails/owaspplwroclaw1-160225150939-thumbnail.jpg?width=640&height=640&fit=bounds)
![[Wroclaw #2] iOS Security - 101](https://cdn.slidesharecdn.com/ss_thumbnails/owaspios101-160429210915-thumbnail.jpg?width=640&height=640&fit=bounds)
![Dark Side of iOS [SmartDevCon 2013]](https://cdn.slidesharecdn.com/ss_thumbnails/smartdevconpresentation-130913064401-phpapp01-thumbnail.jpg?width=640&height=640&fit=bounds)
Securing Android
- 1. Securing Android by Aleksandar Gargenta, Marakana Inc. h"p://mrkn.co/f/497
- 2. About Aleksandar (Saša) Gargenta • Developing in Java since 1996 – mostly server-‐side • Hacking Android since 2008 – from the SDK to the kernel • Teaching Java, Android, etc. at Marakana since 2005 – h"p://marakana.com/ • Founder & Organizer of San Francisco Java User Group – h"p://www.sZava.org/ • Founder & Organizer of San Francisco Android User Group – h"p://www.sfandroid.org/ • Co-‐founder & co-‐organizer of San Francisco HTML5 User Group – h"p://www.s]tml5.org/ • Wri_ng a book Android Internals for O'Reilly (ETA? yesterday) • Worked on SMS, MMS, WAP Push, but also Linux and system administra_on in past life
- 3. Overview • Why care? • Android Security Model • Permissions on Android • Encryp_on on Android • Device Admin • Roo_ng Android Devices • An_-‐roo_ng? ASLR? SE-‐Linux? Locking bootloaders? • Tap-‐jacking • Developer Best Prac_ces • Other concerns
- 4. Why Care? " "Scary Android security hole in 99% of phones: PANIC!" – Computerworld " "HTC promises fix for massive Android security flaw" – MobileBeat " "Android users are two and a half _mes as likely to encounter malware today than 6 months ago…" – Lookout Mobile Threat Report " "Today’s mobile devices are a mixed bag when it comes to security… s_ll vulnerable to many tradi_onal a"acks….” -‐ Carey Nachenberg, Symantec " "Android Security Will Be Big News in 2011: 10 Reasons Why" -‐ eWeek " "The growth rate in malware within Android is huge; in the future there will definitely be more." -‐ Nikolay Grebennikov, CTO of Kaspersky " "Any _me a technology becomes adopted and popular, that technology will be targeted by the bad guys." -‐ Jay Abbo", PricewaterhouseCoopers LLP
- 5. Founda_ons of Android Security • Applica_on Isola&on and Permission-‐Control – Can we control what applica_ons are able to do? – Can a misbehaving app affect the rest of the system? • Applica_on "Provenance" – Can we trust the author of an app? – Can we trust our apps to be tamper-‐resistant? • Data Encryp&on – Is our data safe if our device is hacked/lost/stolen? • Device Access Control – Can we protect our device against unauthorized use?
- 6.
- 7.
- 8. Android Applica_on Isola_on • By default, each app runs in a separate process with a dis_nct user/group ID (fixed for the life_me of the app) – Possible for mul_ple apps to share UID and process – Based on decades-‐old, well-‐understood UNIX security model (processes and file-‐system permissions) • Applica_on-‐framework services also run in a separate process (systemserver) • Linux kernel is the sole mechanism of app sandboxing • Dalvik VM is not a security boundary – Coding in Java or C/C++ code – no difference – Enables use of JNI (unlike JavaME!) • Same rules apply to system apps
- 9. Default Android Permissions Policy
- 10. Default Android Permissions Policy • No app can do anything to adversely affect – Other apps – The system itself – The user of the device • So, by default, apps cannot: – Read*/write files outside their own directory – Install/uninstall/modify other apps – Use other apps' private components – Access network – Access user's data (contacts, SMS, email) – Do things that cost money (make phone calls, send SMS) – Keep device awake, automa_cally start on boot, etc.
- 11. Escaping The Sandbox • Actually, apps can* talk to other apps via – Intents – IPC (a.k.a. Binder) – ContentProviders • Otherwise, to escape our sandbox, we need to use permissions
- 12. Built-‐in Android Permissions ACCESS_FINE_LOCATION, ACCESS_NETWORK_STATE, ACCESS_WIFI_STATE, ACCOUNT_MANAGER, BLUETOOTH, BRICK, CALL_PHONE, CAMERA, CHANGE_WIFI_STATE, DELETE_PACKAGES, INSTALL_PACKAGES, INTERNET, MANAGE_ACCOUNTS, MASTER_CLEAR, READ_CONTACTS, READ_LOGS, READ_SMS, RECEIVE_SMS, RECORD_AUDIO, SEND_SMS, VIBRATE, WAKE_LOCK, WRITE_CONTACTS, WRITE_SETTINGS, WRITE_SMS, … h"p://developer.android.com/reference/android/Manifest.permission.html
- 13. Example: Buddy Tickler App • For example, an app that vibrates your phone any _me you get in close vicinity to a friend would need to use at least the following permissions: • App's AndroidManifest.xml: <manifest package="com.marakana.android.trackapp" …> <uses-permission android:name="android.permission.ACCESS_FINE_LOCATION"/> <uses-permission android:name="android.permission.INTERNET" /> <uses-permission android:name="android.permission.VIBRATE" /> … </manifest>
- 14.
- 15. Permission Enforcement Example • Only the system user (i.e. SS proc) can write to the vibrator driver: $ adb shell ls -l /sys/class/timed_output/vibrator/enable -rw-r--r-- system system 4096 2011-09-30 23:23 enable • Only apps with android.permission.VIBRATE permissions can access VibratorSevice.vibrate(…) method: frameworks/base/services/java/com/android/server/VibratorService.java package com.android.server; … public class VibratorService extends IVibratorService.Stub { … public void vibrate(long milliseconds, IBinder token) { if (mContext.checkCallingOrSelfPermission( android.Manifest.permission.VIBRATE) != PackageManager.PERMISSION_GRANTED) { throw new SecurityException( "Requires VIBRATE permission"); } … } … }
- 16. Kernel Permission Enforcement • Some Android permissions directly map to group IDs, which are then enforced by the kernel/FS: /system/etc/permissions/platform.xml: <permissions> … <permission name="android.permission.INTERNET" > <group gid="inet" /> </permission> <permission name="android.permission.CAMERA" > <group gid="camera" /> </permission> <permission name="android.permission.READ_LOGS" > <group gid="log" /> </permission> <permission name="android.permission.WRITE_EXTERNAL_STORAGE" > <group gid="sdcard_rw" /> </permission> … </permissions> • Interes_ng example: android.permission.INTERNET -> inet -> 3003 -> ANDROID_PARANOID_NETWORK (kernel patch)
- 17. Permission Gran_ng • Permissions are granted once, at the applica_on install _me – Ok, updates too – One excep_on, URI permissions • All-‐or-‐nothing! • But, can a novice any user tell whether the combina_on of requested permissions is OK? (Can you?) – Permissions marked as "normal" are hidden behind "See all" • What about combo of permissions across different apps from the same (malicious) author? (Apps can share)
- 18. Applica_on Provenance • Can we trust the developer of an applica_on we are about to install? (mostly, no) • Can we trust that our apps are resistant to tampering once installed? (mostly, yes) • To get onto Android Market, a developer just needs to register with Google and pay $25 with a valid credit card – A mild deterrent against authors of malicious apps • Apps can also be side-‐loaded (not on AT&T)
- 19. Applica_on Provenance (Signing) • All apps (.apk files) must be digitally signed prior to installa_on on a device (and uploading to Android Market) • The embedded cer_ficate can be self-‐signed (no CA needed!) and valid for 25+ years • App signing on Android is used to: – Ensure the authen_city of the author on updates – Establish trust rela&onship among apps signed with the same key (share permissions, UID, proc.) – Make app contents tamper-‐resistant (moot point) • An app can be signed with mul_ple keys
- 20. Applica_on Provenance (Signing) • Lost/expired key? No way to update the app(s) • Stolen key? No way to revoke • How do we trust the author on the first install? – Is this the real author, or an imposter? Can I check the cert? – Has this app been ve"ed? – Go by the number of installs? • Follow the sheep?
- 21. Applica_on Provenance (Signing) • The result? " Android.Rootcager " Android.Pjapps " Android.Bgserv • All took advantage of weak trust rela_onship ① Take an exis_ng (popular) app ② Inject malicious code (e.g. a trojan) ③ Re-‐package and re-‐sign with a new key/cert ④ Upload to market (or distribute via web) ⑤ Wait for the "sheep" to come (not really our fault)
- 22. Safeguarding Apps' Data • Apps' files are private by default – Owned by dis_nct apps' UIDs • Excep_ons – Apps can create files that are • MODE_WORLD_READABLE • MODE_WORLD_WRITABLE – Other apps (signed with the same key) can run with the same UID – /mnt/sdcard is world-‐readable and world-‐writable (with WRITE_TO_EXTERNAL_STORAGE)
- 23. Data Encryp_on VPN (IPSEC) with 3DES and AES and cert auth. 802.11 with WPA/2 and cert auth. OpenSSL JCE (based on BouncyCastle provider) Apache HTTP Client (suppor_ng SSL) java.net.H"psUrlConnec_on Whole-‐disk encryp_on (requires >= 3.0) • Using encryp_on well is non-‐trivial (e.g. IV) • Does not help if the key is stored on the device
- 24. Whole Disk Encryp_on • Se/ngs → Loca3on & Security → Encryp3on → Encrypt tablet – Requires screen-‐lock password – Encrypts /data par__on with 128-‐bit AES – Disabling encryp_on requires device master reset • Based on Linux' dm-‐crypt kernel feature – Wraps /data as an encrypted block device • User-‐password used directly (change expensive) • Not hardware-‐accelerated: 54% degrada_on in performance on reads* on Samsung Galaxy Tab 10.1 • Vulnerable to "Evil maid a"ack" and cold-‐boot a"acks
- 25. [Physical] Access Control • Screen unlock pa"ern, pin, password • More op_ons with device admin (including password expira_on, encryp_on, auto-‐device-‐wipe, etc.) • Low-‐level access to SIM card is not available to apps • But: " SIM/SD Card can be simply ejected, bypassing screen unlock " Cold-‐boot a"acks
- 26. Taking Android To Work: Device Admin
- 27. Roo_ng • Why root? – Access to custom ROMs – Reuse old hardware – Remove offending system apps – Get more speed – Get be"er looks – Because it's cool • But, it comes at a price
- 28. Roo_ng: How-‐to 1. Exploit a weakness of the exis_ng ROM to gain root 2. Flash the recovery par__on with an alterna_ve image 3. Download an alterna_ve compa_ble ROM (already rooted) onto the /sdcard 4. Reboot into recovery, and flash the new ROM 5. Get root at any _me with Superuser.apk + /system/bin/su • Or, as easy as: $ fastboot oem unlock
- 29. Ge€ng Root • exploid: exploit a bug in udev (on Android init/ueventd) to pass a fake message (NETLINK_KOBJECT_UEVENT) with executable FIRMWARE code to run as root • rageagains<hecage: exploit a race-‐condi_on in adbd to preempt its call to setuid() (to shell user) leaving it running as root • so>break/gingerbreak: exploit a buffer-‐overrun condi_on in vold (which runs as root) to execute arbitrary code as root • …
- 30. Dangers of Roo_ng • App isola_on • System/app permissions • Data-‐safeguards + encryp_on • Device administra_on • … all fall-‐apart when we allow un-‐trusted code to run as root (this is what malicious apps do)
- 31. Memory Security Protec_on • Hardware-‐based No eXecute (NX) to prevent code execu_on on the stack and heap • ProPolice to prevent stack buffer overruns • safe_iop to reduce integer overflows • Extensions to OpenBSD dlmalloc to prevent double free() vulnerabili_es and to prevent chunk consolida_on a"acks (against heap corrup_on) • OpenBSD calloc to prevent integer overflows during memory alloca_on • Linux mmap_min_addr() to mi_gate null pointer dereference privilege escala_on • But, what about shared libraries?
- 32. Address Space Layout Randomiza_on • Shared libraries on Android are pre-‐linked: their address are fixed, for performance reasons • Successful memory corrup_on a"acks can easily return to libc (i.e. execute arbitrary code) • ASLR on Android ( just a proposal at this _me): – Randomize offsets to shared libs and executables at system upgrade-‐_me – Record offsets to undo randomiza_on for OTA updates – Detect brute-‐force guessing with cloud-‐based analysis • h"p://bojinov.org/professional/wisec2011-‐ mobileaslr-‐paper.pdf
- 33. SE-‐Linux on Android • SELinux allows us to run OS services with minimum privileges (i.e. not root) – Heavy use on the desktop/server-‐side • SELinux on Android is possible, but hard – Slow – Requires rethinking on the security model for easier configura_on – Does not support yaffs2 • Folks at Hitachi got it to work, but it seems stalled
- 34. Tap-‐Jacking on Android • A malicious app starts a security-‐ sensi_ve (e.g. system se€ngs) ac_vity • It then overlays a full-‐screen custom no_fica_on dialog on top of the targeted ac_vity (like a game) – works like Toasts • User interacts with the custom no_fica_on dialog, but her touch events are passed down to the legi_mate ac_vity • In API >=9 prevent with XML a"r on UI filterTouchesWhenObscured (or programma_cally)
- 35. Developer Best Prac_ces • If you are using encryp_on, be sure to know what you are doing (e.g. use IVs) • Mark your applica_on's components as android:exported="false" unless you are specifically building them for public use – Don't trust Intent inputs/results (especially pending) – Don't leak broadcast events you are sending out – Use custom permissions to control access • Avoid building apps that require root
- 36. An_-‐malware • Use PackageManager.getInstalledPackages(int) for the ini_al scan of apps/packages against a known black-‐list – E.g. check for package names, permissions, signatures • Listen for android.intent.action.PACKAGE_ADDED broadcasts and verify new apps • Once a malicious app is found, offer the user a chance to delete it: Uri packageURI = Uri.parse("package:com.malicous.app"); Intent uninstallIntent = new Intent( Intent.ACTION_DELETE, packageURI); startActivity(uninstallIntent); • For personal use, consider something like: – Lookout Security & An3virus – Norton Mobile Security
- 37. Other Security Concerns • Push-‐based install from Android Market (GMail) • Social-‐engineering • Firewall • Encryp_on of communica_on • Compromised pla•orm keys • App obfusca_on • Protec_ng bootloader/recovery • Security of skins • OEM/Carrier OS upgrade cycles
- 38. Thank You! • Ques_ons? • Video/slides: h"p://mrkn.co/f/497 • More info: – h"p://source.android.com/tech/security/index.html – h"p://source.android.com/tech/encryp_on/ android_crypto_implementa_on.html – h"p://www.symantec.com/about/news/release/ar_cle.jsp? prid=20110627_02 • Contact Info: – h"p://marakana.com/ – [email protected] – @agargenta on Twi"er – [email protected] on Google+