iOS Application Security

Transcript

1. iOS Application Security
   Intro
   

   View 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 Slide

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

   View 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 Slide

5. Check for Jailbreak
   

   View 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 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 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 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 Slide

10. 100%
    

    View Slide

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

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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

    View Slide

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
    

    View Slide

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

    View Slide

18. File Paths from External Sources
    

    View Slide

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
    

    View Slide

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

    View Slide

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:
    

    View Slide

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

    View Slide

23. URL schemes
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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)
    

    View Slide

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

    View Slide

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

    View Slide

30. Storing Credentials
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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)
    

    View Slide

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

    View Slide

35. 3rd-Party Dependencies
    

    View Slide

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
    

    View Slide

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
    
    

    View Slide

38. View Slide

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

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

43. There's so Much to Remember…
    

    View Slide

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

    View Slide

45. MASVS
    Mobile Application Security Verification Standard
    

    View Slide

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
    

    View Slide

47. MASVS
    Mobile Application Security Verification Standard
    

    View Slide

48. MASVS
    Mobile Application Security Verification Standard
    

    View Slide

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

    View Slide

50. Thank you
    iaronskaya
    

    View Slide

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
    

    View Slide