Avoiding Android App Security Pitfalls

Avoiding Android App Security Pitfalls

Presented at Mobile+Web DevCon

C65347082fd2c5ec7c783f214e2d49e0?s=128

Zach Lanier

July 16, 2013
Tweet

Transcript

  1. 2.

    Intro • Zach Lanier • Security Researcher with Veracode •

    the “CH” in TEAM JOCH (Jon Oberheide is the “JO”) • (Net | Web | Mobile | App) pen tester type • Recovering consultant • ex-CISSP 2 Monday, July 23, 12
  2. 5.

    Android Overview • Base platform • ARM core (typically) •

    Linux 2.6.3x - 3.0.x kernel • Native libraries • libc, WebKit, OpenSSL, etc. • Dalvik VM • Register-based VM • Runs dex bytecode • Applications • Developed in Java • Run on Dalvik VM • Linux process 1:1 5 Monday, July 23, 12
  3. 6.

    Android Overview • Fragmented versions :( • Various choke points

    (OEMs, carriers, etc.) mean bugs don’t get fixed (app, system kernel, etc.) 6 Chart source: developer.android.com (Data current as of July 2, 2012) Monday, July 23, 12
  4. 7.

    “Sandboxing” • “Sandboxed” by standard UNIX uid/gid • Generated unique

    per app at install time • High-level permissions restricted by Android runtime framework 7 Monday, July 23, 12
  5. 10.

    Slightly New Exploit Mitigations 10 Ice Cream Sandwich added partial

    ASLR (heap randomization added in Android 4.0.2+) Monday, July 23, 12
  6. 11.

    Current Exploit Mitigations • Full ASLR w/PIE added in 4.1

    (Jelly Bean) for most system binaries • Position Independent Executables = random base address for program, strengthening ASLR • RELRO + BIND_NOW • RELRO: Reordering of ELF sections, read-only GOT, etc. • BIND_NOW: load all executable sections at runtime; helps assists RELRO 11 Monday, July 23, 12
  7. 13.

    Current Exploit Mitigations • dmesg_restrict & kptr_restrict (added in 4.1)

    • dmesg_restrict: prevents unprivileged users from reading dmesg or klogctl (kernel log) buffer (wherein kernel information, useful in exploit dev, might be exposed) • kptr_restrict: prevents exposure of sensitive kernel pointer addresses (which would also be useful in exploit development) 13 Monday, July 23, 12
  8. 14.

    “Weak” ASLR • Zygote pre-forking model • Java processes inherit

    VM from zygote • Same mappings across all Java apps • Performance vs. security trade-off • Most ARM CPUs are 32-bit • No need to address more than 4GB physical • 32-bit ASLR can be brute-forced 14 Monday, July 23, 12
  9. 15.

    Future Mitigations • Code signing? • Ensure that only signed

    code w/app is what’s running (i.e. no [remote] retrieval and loading of new code) • Additional hardening of system libraries (e.g. bionic) 15 Monday, July 23, 12
  10. 17.

    17 • Application signing • No CAs • Self-signed by

    developers • Android Market/Google Play • $25 signup, anyone can publish • Anonymous sign-up possible • Some dynamic app analysis via Bouncer • See also http://jon.oberheide.org/files/summercon12-bouncer.pdf App Distribution Monday, July 23, 12
  11. 18.

    18 • Android apps contained in “APK” (ZIP file) including:

    • classes.dex - the Dalvik executable (app code) itself • Application manifest • Resources (images, GUI layout files) • Supporting native libraries • Cryptographic signature files App Structure Monday, July 23, 12
  12. 19.

    Manifest • AndroidManifest.xml • Every APK must include a manifest

    called AndroidManifest.xml • Manifest presents essential information about an app • Package name, components, linked libraries, permissions, and more 19 Monday, July 23, 12
  13. 20.

    Permissions • At install time, applications explicitly request pre-defined permissions,

    such as: • Cellular: calls, SMS, MMS • Network: Bluetooth, WiFi, Sockets • Hardware: vibrate, backlight • Location: coarse, fine • App data: contacts, calendars 20 Monday, July 23, 12
  14. 21.

    Permissions • Others enforced by group membership in the linux

    kernel • “android.permission.INTERNET” • AF_INET: 3003 21 Monday, July 23, 12
  15. 22.

    Permissions • Is current approach granular enough? • Coarse network

    permissions • More granularity would be useful • Address/CIDR/DNS specification • Fine line between effective granularity and overloading users • e.g. Facebook app • Credentials should only be sent to facebook.com 22 Monday, July 23, 12
  16. 23.

    Permissions • Dalvik VM != sandbox • Not limited to

    executing dex bytecode • Can pop out of the VM to execute native code • User privileges still enforced • Native code packaged within APKs • Android doesn’t do code signing like iOS 23 Monday, July 23, 12
  17. 25.

    Insecure Transmissions • Complete lack of encryption for transmitted data

    • Yes, unfortunately this happens often • Weakly encrypted data in transit • Strong encryption, but ignoring security warnings • Ignoring certificate validation errors • Falling back to plain text after failures 25 Monday, July 23, 12
  18. 26.

    Insecure Transmissions • Real World Example: Google ClientLogin Authentication Protocol

    • Authorization header sent over HTTP • When users connected via WiFi, apps automatically sent the token in an attempt to automatically synchronize data from server • Sniff this value, impersonate the user • See also: http://www.uni-ulm.de/in/mi/mitarbeiter/koenings/ catching-authtokens.html 26 Monday, July 23, 12
  19. 27.

    Case Study: Foursquared • Foursquare client for Android • Foursquare

    is a location-based social network • Source available under Apache 2.0 license 27 Monday, July 23, 12
  20. 28.

    Case Study: Foursquared • Foursquare API supports HTTP Basic Auth

    and OAuth… • OAuth includes signatures for transactions, helps prevent replay attacks, etc. • Guess which one foursquared used 28 Monday, July 23, 12
  21. 29.

    Case Study: Foursquare • That’s right. HTTP Basic Auth…over plaintext

    transport • There’s a CWE for that! • CWE-311: Missing Encryption of Sensitive Data (including credentials) 29 Monday, July 23, 12
  22. 30.

    Insecure Transmissions • Why is this a problem? Well, a

    lot of people use Foursquare • Well, maybe not you, but everyone else! • Most applications “prefer” WiFi to cell radio...ergo trivial interception of creds • Credential re-use by users exacerbates this • Funny enough, Foursquared had OAuth support • But it wasn’t actually used/enabled 30 Monday, July 23, 12
  23. 31.

    Insecure Transmissions • Ensure that all sensitive data leaving the

    device is encrypted • This includes data over carrier networks, WiFi, and even NFC • When security exceptions are thrown, it’s generally for a reason…don’t ignore them! 31 Monday, July 23, 12
  24. 32.

    Insecure Storage • Android devices isolate applications’ filesystem data stores

    through Unix permissions • Note: rooted device -> all bets are off • Leaving USB debugging enabled, say for a lost phone, is an opportunity for access 32 Monday, July 23, 12
  25. 34.

    Insecure Storage • Default mode for files created through Java

    (files, databases, shared prefs, etc.): • Files created through native code inherit Zygote’s umask: 0000 34 Monday, July 23, 12
  26. 35.

    Insecure Storage • Public example: • Skype (April 15, 2011)

    - multiple, sensitive files with insecure permissions, including DB with all account information (including personal info) 35 Source: AndroidPolice.com Monday, July 23, 12
  27. 36.

    Insecure Storage • Store ONLY what is absolutely required •

    Never use shared storage areas lacking access control (i.e. SD card) • Leverage secure containers and platform provided encryption APIs • DON’T MAKE CLASSIC CRYPTO MISTAKES • Do not assign world readable or world writeable permissions to files, databases, sharedprefs, etc. 36 Monday, July 23, 12
  28. 37.

    Information Leakage: Logs • Logs are a good source of

    information leaks Example of a user tapping a link in an SMS/MMS message, firing an Intent to start the browser and go to a site • Trivial example, but easily retrievable information • A rogue app may request android.permission.READ_LOGS 37 Monday, July 23, 12
  29. 38.

    Information Leakage: Logs • Example: app with strict SSL cert

    validation and pinning (meaning we couldn't MITM) still leaked structure of POST request in the logs • Easy to then create custom client -> attack the webserver 38 Monday, July 23, 12
  30. 39.

    Information Leakage • Never log credentials, PII, or other sensitive

    data to system logs • Remove sensitive data before screenshots are taken, disable keystroke logging per field, and utilize anti-caching directives for web content • Debug your apps before releasing them to observe files created, written to, or modified in any way • Carefully review any third party libraries you introduce and the data they consume • Test your applications across as many platform versions as possible 39 Monday, July 23, 12
  31. 40.

    Case Study: Storage App • Multi-platform application for storing and

    retrieving music, videos, documents, and more • Android, BREW, BlackBerry, and fat web browser • Proprietary, binary-only 40 Monday, July 23, 12
  32. 41.

    Case Study: Storage App • Simple crash in storage quota

    viewer • Divide-by-zero error leads to DoS • Attacker must successfully intercept and modify server response for this to happen • A bit more difficult since this tends to occur over the carrier’s network, but WiFi is still an option 41 Monday, July 23, 12
  33. 43.

    Case Study: Storage App • Diddling with “Digital Rights Management”

    • App supported sharing of video, audio, image content with your contacts • Enforces “DRM” on “protected” files • Often copyrighted or premium content • Enforcement occurs based on the value of an attribute in the file’s XML manifest • Effectively under the user / attacker's control 43 Monday, July 23, 12
  34. 49.

    Case Study: Storage App • The “DRM” is basically enforced

    within the client, predicated on the response from the server • And that response can be intercepted and modified -> “DRM” bypass • CWE-807: Reliance on Untrusted Inputs in a Security Decision 49 Monday, July 23, 12
  35. 50.

    API Related Issues • Isolation/sandbox “forces” components to interact via

    API • “Intent” message objects used to interact with Activities, Services, and BroadcastReceivers • Think “IPC” • Intent objects bear attributes defining their destination, action, pertinent data, etc. • Reference monitor in Android checks permission labels of caller and callee components 50 Monday, July 23, 12
  36. 51.

    Intents • Applications’ activities must have an “intent-filter” and the

    “android:exported” attribute to be invoked by other applications • For sensitive actions, developers can require the callee to bear custom permissions • Further restrict requests for permissions, ex. by setting “protectionLevel=signature” • When invoking activities, target components should be granular/explicit 51 Monday, July 23, 12
  37. 52.

    Intents 52 Potentially dangerous, could be received by malicious app:

    Better activity, explicitly specifies component to call: Monday, July 23, 12
  38. 53.

    Intents • Applications can register BroadcastReceivers to receive broadcast (Intent)

    messages • This could include receivers the sending app didn’t expect or want to receive a message • Restrict messages only to receivers bearing specific permissions when calling sendBroadcast() • Avoid sending highly sensitive data in broadcast messages! 53 Monday, July 23, 12
  39. 54.

    Intents • Don’t forget that Intents are another potential point

    of input • Sanitize input! • Control access! • Handle exceptions! • iSEC Partners’ “Intent Fuzzer” app reveals a lot of poor exception handling in even the most basic fuzzed Intents 54 Monday, July 23, 12
  40. 56.

    Case Study: App Framework • Cross-platform framework for HTML/JS “widgets”

    (think “small applications”) • WinMo, Android, etc. • “Write once, run anywhere” 56 Monday, July 23, 12
  41. 57.

    Case Study: App Framework • Custom permissions restricted us from

    sending Intents to the runtime 57 Monday, July 23, 12
  42. 58.

    Case Study: App Framework • But, other (malicious) apps can

    clobber widget content! • CWE-276: Incorrect Default Permissions • So we wrote a malicious app to do just that 58 Monday, July 23, 12
  43. 60.

    Case Study: App Framework 60 Malicious app added JS alert()

    to “Chess” widget Monday, July 23, 12
  44. 61.

    Case Study: App Framework • Developers didn’t couple widget runtime

    and widget management app via IPC • Developers didn’t understand things like sharedUserID • Allows apps to share the same UID/GID, granting access to (otherwise protected) app data store (amongst other things) • Devs sidestepped filesystem perm model by making a custom shared data directory 61 Monday, July 23, 12
  45. 63.

    Conclusion • Avoid storing sensitive data (especially in plaintext and

    without proper access control) • BE AWARE of system nuances (filesystem perms, memory issues) • Think about the permissions your app really needs (requesting more than necessary?) • Leverage security facilities provided by the platform! • Remember that bugs in components you use can affect the security of your application (Flash, WebKit, OpenSSL, libc, etc.) 63 Monday, July 23, 12
  46. 64.

    Conclusion • Get involved with the OWASP Mobile Security Project!

    http://owasp.org/index.php/OWASP_Mobile_Security_Project 64 Monday, July 23, 12