Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Avoiding Android App Security Pitfalls

Avoiding Android App Security Pitfalls

Presented at Mobile+Web DevCon

Zach Lanier

July 16, 2013
Tweet

More Decks by Zach Lanier

Other Decks in Technology

Transcript

  1. Avoiding Android App
    Security Pitfalls
    Zach Lanier
    1
    Monday, July 23, 12

    View full-size slide

  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

    View full-size slide

  3. Agenda
    • Android Overview
    • Application Overview
    • Common Issues
    • Conclusion
    3
    Monday, July 23, 12

    View full-size slide

  4. Android Overview
    4
    Monday, July 23, 12

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  8. Old Exploit Mitigations
    Executable stack/heap!
    8
    Non-randomized mmap/
    heap/exec!
    =
    Monday, July 23, 12

    View full-size slide

  9. Slightly Old Exploit Mitigations
    Non-exectuable stack/heap since Android 2.3
    9
    Still no ASLR
    Monday, July 23, 12

    View full-size slide

  10. Slightly New Exploit Mitigations
    10
    Ice Cream Sandwich added partial ASLR
    (heap randomization added in Android 4.0.2+)
    Monday, July 23, 12

    View full-size slide

  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

    View full-size slide

  12. Current Mitigations
    (Courtesy Jon Oberheide)
    12
    Monday, July 23, 12

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  16. 16
    Application Overview
    Monday, July 23, 12

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  21. Permissions
    • Others enforced by group membership in the
    linux kernel
    • “android.permission.INTERNET”
    • AF_INET: 3003
    21
    Monday, July 23, 12

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  24. Common Issues
    24
    Monday, July 23, 12

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  33. Insecure Storage
    33
    Derp
    Monday, July 23, 12

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  42. Case Study: Storage App
    42
    Monday, July 23, 12

    View full-size slide

  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

    View full-size slide

  44. Case Study: Storage App
    44
    Monday, July 23, 12

    View full-size slide

  45. Case Study: Storage App
    45
    Monday, July 23, 12

    View full-size slide

  46. Case Study: Storage App
    46
    Monday, July 23, 12

    View full-size slide

  47. Case Study: Storage App
    47
    Intercept response, change values…
    Monday, July 23, 12

    View full-size slide

  48. Case Study: Storage App
    48
    Monday, July 23, 12

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  52. Intents
    52
    Potentially dangerous, could be received by malicious app:
    Better activity, explicitly specifies component to call:
    Monday, July 23, 12

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  55. Intents
    55
    Monday, July 23, 12

    View full-size slide

  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

    View full-size slide

  57. Case Study: App Framework
    • Custom permissions restricted us from
    sending Intents to the runtime
    57
    Monday, July 23, 12

    View full-size slide

  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

    View full-size slide

  59. Case Study: App Framework
    59
    Monday, July 23, 12

    View full-size slide

  60. Case Study: App Framework
    60
    Malicious app added JS
    alert() to “Chess” widget
    Monday, July 23, 12

    View full-size slide

  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

    View full-size slide

  62. Conclusion
    62
    Monday, July 23, 12

    View full-size slide

  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

    View full-size slide

  64. Conclusion
    • Get involved with the OWASP Mobile Security Project!
    http://owasp.org/index.php/OWASP_Mobile_Security_Project
    64
    Monday, July 23, 12

    View full-size slide

  65. Questions?
    [email protected]
    https://twitter.com/quine
    http://n0where.org/
    Greetz:
    b7e86886b28786a51e568bb825c7f1e2dc757f6f
    787cd9982e2cbc4cd541791311d4014b7ca08816
    22c4bfa3b2de272786b1b6cfc0270a5f21b3f7c1
    caae4eaaf1aad7842dd04d55ec1b3c19404a5cdd
    65
    Monday, July 23, 12

    View full-size slide