iOS Application Security

6e39a16132f9e41e6869527ba0ced276?s=47 vashchenko
October 02, 2020

iOS Application Security

6e39a16132f9e41e6869527ba0ced276?s=128

vashchenko

October 02, 2020
Tweet

Transcript

  1. iOS Application Security Intro

  2. whoami • macOS/Security Engineer at MacPaw • CleanMyMac Anti-Malware Team

    • ex Comodo Security Solutions • Women Who Code Kyiv macOS Lead aronskaya iaronskaya
  3. Agenda Practical cases Several common security bugs in iOS apps

    (and how to avoid them)
  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
  5. Check for Jailbreak

  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
  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
  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()
  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
  10. 100%

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

  12. 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
  13. 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
  14. 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
  15. Takeaways • In function and variable names do not use

    words jail, security, cydia, apt, etc. What if you do it anyway
  16. 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
  17. Jailbreak detection Further Reading OWASP Mobile Application Security Verification Standard:

    § V8: Resilience Requirements Xcon
  18. File Paths from External Sources

  19. 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
  20. File Paths from External Sources Problem Attacker can: • Overwrite

    important data for the app, causing crashes and other unwanted behaviour • Overwrite user data
  21. 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:
  22. File Paths from External Sources Further Reading MITRE ATT&CK Knowledge

    base: CWE-23: Relative Path Traversal OWASP Attacks: Path Traversal
  23. URL schemes

  24. 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
  25. 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

  26. 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
  27. 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)
  28. URL Schemes Checklist ✓ Forget about URL schemes: make use

    of Universal Links instead
  29. URL Schemes Further Reading MITRE Mobile Techniques: URL Scheme Hijacking

  30. Storing Credentials

  31. 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
  32. 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
  33. 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)
  34. Storing Credentials Further Reading TrustKit: open-source framework to deploy SSL

    pinning
  35. 3rd-Party Dependencies

  36. 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
  37. 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
  38. 22

  39. 22 This many years ShellShock vulnerability existed in the OpenSSL

    library
  40. 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
  41. 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
  42. 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
  43. There's so Much to Remember…

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

  45. MASVS Mobile Application Security Verification Standard

  46. 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
  47. MASVS Mobile Application Security Verification Standard

  48. MASVS Mobile Application Security Verification Standard

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

  50. Thank you iaronskaya

  51. 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