iOS Application Security

Slide 1

Slide 1 text

iOS Application Security Intro

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

Check for Jailbreak

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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()

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

100%

Slide 11

Slide 11 text

100% Probability, that a motivated hacker bypasses jailbreak detection

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

File Paths from External Sources

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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:

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

URL schemes

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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)

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

URL Schemes Further Reading MITRE Mobile Techniques: URL Scheme Hijacking

Slide 30

Slide 30 text

Storing Credentials

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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)

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

3rd-Party Dependencies

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

Slide 38

Slide 38 text

Slide 39

Slide 39 text

22 This many years ShellShock vulnerability existed in the OpenSSL library

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

There's so Much to Remember…

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

MASVS Mobile Application Security Verification Standard

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

MASVS Mobile Application Security Verification Standard

Slide 48

Slide 48 text

MASVS Mobile Application Security Verification Standard

Slide 49

Slide 49 text

MASVS Mobile Application Security Verification Standard Download MASVS from GitHub

Slide 50

Slide 50 text

Thank you iaronskaya

Slide 51

Slide 51 text

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