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. whoami • macOS/Security Engineer at MacPaw • CleanMyMac Anti-Malware Team

    • ex Comodo Security Solutions • Women Who Code Kyiv macOS Lead aronskaya iaronskaya
  2. 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
  3. 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
  4. 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
  5. 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()
  6. 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
  7. 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
  8. 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
  9. 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
  10. Takeaways • In function and variable names do not use

    words jail, security, cydia, apt, etc. What if you do it anyway
  11. 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
  12. 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
  13. File Paths from External Sources Problem Attacker can: • Overwrite

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

    base: CWE-23: Relative Path Traversal OWASP Attacks: Path Traversal
  16. 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
  17. 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
  18. 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)
  19. 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
  20. 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
  21. 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)
  22. 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
  23. 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
  24. 22

  25. 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
  26. 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
  27. 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
  28. 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
  29. 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