iOS App Security

Presented by Ravi Aggarwal at MobileFlock III

Transcript

1. iOS App Security Ravi Kumar Aggarwal - 15 Jan 2022 Don’t learn it the hard way
2. whoami • Engineering Manager at TataCLiQ • ex iOS Lead at Tokopedia • ex iOS Engineer at PaytmMoney @raviAggarwal61 @ravi.aggarwal61
3. Agenda • Common Security Breach Areas • Jailbreak Detection • Securing Sensitive Keys • URLSchemes • 3rd Party Dependencies • Where to go next?
4. Jailbreak Detection
5. Jailbreak Detection A motivated hacker can: • Acquire root privileges on the device and mess with the app. • Steal and publish/sell sensitive information. • Tamper with the in-app purchases. Problem
6. Check for Jailbreak Use cases • Finance app, that allows to move user funds • Apps, 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
7. Common Solutions 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() Check for Jailbreak
8. Check for Jailbreak When it doesn’t work • Advanced Jailbreak tools can fool your app into thinking root access is not available. • Tools like Xcon https://www.theiphonewiki.com/wiki/XCon help to bypas all f ile checks. 
 • Replacing the Boolean value, retuned from isJailbroken(), disables all checks. Reverse engineering and hooking such function is trivial.
9. 100% Probability that a motivated black hat will bypass jailbreak
10. What can you do? • Understand that 100% detection is impossible. • Make it harder and time consuming to bypass jailbreak detection using random checks. • Avoid ObjC. (Easy to reverse engineer) • Avoid straight-forward naming. func isJailbreak() -> Bool { //... } + BOOL isDeviceJailBroken { //… }
11. Jailbreak Detection Further Reading • OWASP Mobile Security Testing Guide • Xcon
12. Securing Sensitive Keys
13. Securing Sensitive Keys Problem An attacker can: • Steal passwords, private api keys, authentication details, etc that you store locally in the app. • Use the same credentials to gain access to the server, exhaust usage limit or generate millions in AWS bills. • Run the strings command on your binary and extract all this information.
14. Godbolt Decompiling Swift Code
15. What can you do? • Hash the keys being stored locally and name them “not-obvious”. cocoapods-keys will be effective here. • Store the credentials on remote server and connect to your server for information instead of the third parties directly. • You can implement SSL pinning (understanding all the risks) to make sure that the server you are talking to is the one you expect.
16. URLSchemes
17. URLSchemes Problem A motivated attacker can: • Pretend to be your app by using the same URLScheme (your implementation doesn’t matter). • Make your app perform malicious actions (depends on how you are handling app input).
18. URLSchemes An example • You have an implementation to open a URL coming from other app. • Your URLSchemeHandler, parses the received URL and opens up the WebView using that URL. • A malicious app passes you a URL for a page that looks exactly like a banking app, your customer’s credentials gets stolen by your app!
19. What can you do? • Sanitise the input you receive in URLScheme. • Move to Universal Links instead.
20. 3rd Party Dependencies
21. 3rd Party Dependencies An example • You add a nice 3rd party cocoapod for networking. • A security researcher f inds that the pod has been logging all information on the console. • Pod owners quickly patch it. • Your users are vulnerable till your update is rolled out and adopted.
22. 3rd Party Dependencies Problem • An attacker can basically do anything by merging their code in your app. Crash your app Access Microphone Steal sensitive information Swizzle method implementation Access Camera
23. Log4j
24. 22 years Shellshock vulnerability in OpenSSL
25. What can you do? • Make sure you understand what code are you adding to your project. • Subscribe to the mailing list or twitter feeds of the third parties to stay updated. • Minimise the number of third parties.
26. Where to go next?
27. Where to go next? • Use the vulnerabilities checklist present at Mobile Application Security Veri f ication Standard (MASVS) to understand which ones you need to implement a check against. • Use the OWASP Mobile Security Testing Guide to understand those vulnerabilities and know how to test your app against them.
28. Thank You!