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

iOS Application Security

vashchenko
October 02, 2020

iOS Application Security

vashchenko

October 02, 2020
Tweet

More Decks by vashchenko

Other Decks in Programming

Transcript

  1. iOS Application Security
    Intro

    View full-size slide

  2. whoami
    • macOS/Security Engineer at
    MacPaw
    • CleanMyMac Anti-Malware Team
    • ex Comodo Security Solutions
    • Women Who Code Kyiv macOS
    Lead
    aronskaya
    iaronskaya

    View full-size slide

  3. Agenda
    Practical cases
    Several common security bugs in
    iOS apps (and how to avoid them)

    View full-size slide

  4. Agenda
    Practical cases
    Several common security bugs in
    iOS apps (and how to avoid them)
    Approach to secure coding
    1 Checklist to help you write secure apps

    View full-size slide

  5. Check for Jailbreak

    View full-size slide

  6. Check for Jailbreak
    Problem
    Attacker can:
    • Acquire root privileges on the device and mess with any app
    • Steal (and sell or publish) sensitive user data
    • Steal passwords and other authentication details

    View full-size slide

  7. Check for Jailbreak
    Usecases
    • Finance app, that allows to move user funds
    • App, that stores sensitive user information on device
    • Apps, that need to protect in-app purchases on device
    • Games
    • Apps, that need to protect Intellectual Property

    View full-size slide

  8. Check for Jailbreak
    Popular Techniques
    1. Check if paths exists: /bin/bash, etc. via FileManager or fopen(), stat(),
    access()
    2. Path permissions with FileManager or statfs()
    3. Process forking with fork() or popen()
    4. Check dynamic libraries currently loaded into memory via
    _dyld_image_count() & _dyld_get_image_name()

    View full-size slide

  9. Check for Jailbreak
    Controversy
    • The sandbox might work properly on device (trying to fork() will fail as
    expected)
    • Tools like Xcon https://www.theiphonewiki.com/wiki/XCon help to bypas
    all file checks
    • Replacing the Boolean value, retuned from isJailbroken(), disables all
    checks. Reverse engineering and hooking such function is trivial

    View full-size slide

  10. 100%
    Probability, that a motivated hacker bypasses jailbreak detection

    View full-size slide

  11. Takeaways
    • Talk to the manager: explain
    them, that 100% detection is
    impossible
    • Make bypassing jailbreak
    detection time-consuming
    • Avoid Objective-C if possible
    (easy to reverse engineer)
    What if you do it anyway

    View full-size slide

  12. Takeaways
    • Hide the jailbreak check deep
    in the app (not in AppDelegate)
    • Use a library (or just check out
    what libraries do for detection),
    like IOSSecuritySuite by
    Wojciech Reguła https://
    github.com/securing/
    IOSSecuritySuite or another
    one
    What if you do it anyway

    View full-size slide

  13. Takeaways
    • In function and variable names
    do not use words jail, security,
    cydia, apt, etc.
    What if you do it anyway
    Screenshot from OWASP Mobile Security Testing Guide

    View full-size slide

  14. Takeaways
    • In function and variable names
    do not use words jail, security,
    cydia, apt, etc.
    What if you do it anyway

    View full-size slide

  15. Takeaways
    • The app detects, and responds
    to, the presence of a rooted or
    jailbroken device either by
    alerting the user or terminating
    the app.
    OWASP MASVS
    What if you do it anyway

    View full-size slide

  16. Jailbreak detection
    Further Reading
    OWASP Mobile Application Security Verification Standard:
    § V8: Resilience Requirements
    Xcon

    View full-size slide

  17. File Paths from External Sources

    View full-size slide

  18. File Path from External Source
    Example
    • Say, we receive fileName from external source
    • Say, attacker replaces it with "../busted!"
    • We go a level up and rewrite the whole directory with user files

    View full-size slide

  19. File Paths from External Sources
    Problem
    Attacker can:
    • Overwrite important data for the app, causing crashes and other
    unwanted behaviour
    • Overwrite user data

    View full-size slide

  20. File Paths from External Sources Checklist
    ✓ Write files to NSTemporaryDirectory() with locally generated random
    name
    ✓ If you do have to work with externally obtained file names, sanitize
    them:

    View full-size slide

  21. File Paths from External Sources
    Further Reading
    MITRE ATT&CK Knowledge base: CWE-23: Relative Path Traversal
    OWASP Attacks: Path Traversal

    View full-size slide

  22. URL Schemes
    Example
    • Say, the client wants you to display a specific web page by request of other
    app
    • You implement a URL scheme handler
    • Another app registers the same URL scheme (Apple allows it)
    • Other app pretends to be your app and tricks user to type in the password

    View full-size slide

  23. URL Schemes
    https://developer.apple.com/documentation/xcode/allowing_apps_and_websites_to_link_to_your_content/
    defining_a_custom_url_scheme_for_your_app

    View full-size slide

  24. URL Schemes
    Example 2
    • Say, the client wants you to display a specific web page by request of other
    app
    • You implement a URL scheme handler, that parses received URL, extracts
    HTML and opens a web view
    • Other app passes you a page, that looks exactly like an installed banking app
    login page. Users type in their credentials. Your app is in the news

    View full-size slide

  25. URL Schemes
    Problem
    Attacker can:
    • Pretend to be your app (your implementation of URL scheme handling
    doesn't matter)
    • Make your app perform malicious actions (this case depends on your
    implementation)

    View full-size slide

  26. URL Schemes Checklist
    ✓ Forget about URL schemes: make use of Universal Links instead

    View full-size slide

  27. URL Schemes
    Further Reading
    MITRE Mobile Techniques: URL Scheme Hijacking

    View full-size slide

  28. Storing Credentials

    View full-size slide

  29. Storing Credentials
    Example
    • Say, the client wants the app to use a 3rd party cloud database, and
    you get the private key to authenticate
    • You store it as a string in the codebase
    • A reverse engineer runs strings command on your binary, acquires the
    key, steals the data and publishes it in the internet

    View full-size slide

  30. Storing Credentials
    Problem
    Attacker can:
    • Steal passwords, private keys , authentication details, that you store
    locally in any way (in a separate file, in codebase, obfuscated or not)
    • Use acquired credentials to pretend to be your app and use it agains you

    View full-size slide

  31. Storing Credentials Checklist
    ✓ Do not store credentials locally in any way.
    ✓ Store credentials on your remote server, and connect to it instead of
    connecting to the cloud database directly. Your app must
    authenticate with your server
    ✓ Implement SSL pinning to be sure, that the server you are talking is
    the one you expect (there is no man-in-the-middle)

    View full-size slide

  32. Storing Credentials
    Further Reading
    TrustKit: open-source framework to deploy SSL pinning

    View full-size slide

  33. 3rd-Party Dependencies

    View full-size slide

  34. 3rd-Party Dependencies
    Example
    • Say, the client wants to have UI a lot like in another app
    • You notice a nice popular pod in CocoaPods, that implements it
    • A researcher finds a security bug in this pod, owners quickly patch it
    • Before you roll out the update all your users are vulnerable to an
    attack, that is described in the Internet in great detail

    View full-size slide

  35. 3rd-Party Dependencies
    Example
    • Say, the client wants to have UI a lot like in another app
    • You notice a nice popular pod in CocoaPods, that implements it
    • A researcher finds a security bug in this pod, owners quickly patch it
    • Before you roll out the update all your users are vulnerable to an
    attack, that is described in the Internet in great detail

    View full-size slide

  36. 22
    This many years ShellShock vulnerability existed in the OpenSSL library

    View full-size slide

  37. 3rd-Party Dependencies
    Problem
    Attacker can:
    • Do anything in the app by merging their code in the library
    Steal, sell, publish user data
    Access microphone
    Access camera
    Crash your app
    Steal your application data
    Replace your methods implementation

    View full-size slide

  38. 3rd-Party Dependencies Checklist
    ✓ For every dependency subscribe to a mailing list / twitter/ ..., use
    any channel to get the news about your dependencies (so you know,
    when there is a security issue)
    ✓ Minimize the number of dependencies—information on
    vulnerabilities is fragmented and not easy to track
    P.S. Dependabot team is working on CocoaPods support

    View full-size slide

  39. 3rd-Party Dependencies
    Further Reading
    MITRE PRE-ATT&CK Techniques: Enumerate externally facing software applications
    technologies, languages, and dependencies
    OWASP Top Ten: A9:2017-Using Components with Known Vulnerabilities
    Vulnerable Dependency Management Cheat Sheet

    View full-size slide

  40. There's so Much to Remember…

    View full-size slide

  41. There's so Much to Remember…
    But You Shouldn't

    View full-size slide

  42. MASVS
    Mobile Application Security Verification Standard

    View full-size slide

  43. MASVS
    Mobile Application Security Verification Standard
    • Level 1. Client: "We don't need any security"
    • Level 1 + Resilience: Games and Apps, that must protect Intellectual Property
    • Level 2. Healthcare and Financial
    • Level 2 + Resilience. On device we need to: protect in-app purchases, store sensitive
    data, online banking with moving user funds functionality

    View full-size slide

  44. MASVS
    Mobile Application Security Verification Standard

    View full-size slide

  45. MASVS
    Mobile Application Security Verification Standard

    View full-size slide

  46. MASVS
    Mobile Application Security Verification Standard
    Download MASVS from GitHub

    View full-size slide

  47. Thank you
    iaronskaya

    View full-size slide

  48. Credits
    Hand holing an iPhone: Photo by freestocks on Unsplash
    Today...: Photo by Priscilla Du Preez on Unsplash
    Photo by Markus Winkler on Unsplash
    Hand holding locked iPhone: Photo by NeONBRAND on Unsplash

    View full-size slide