Best Secure Practices in iOS Development.

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!