SlideShare a Scribd company logo

iOS Application Security.pdf

•
•
Ravi Aggarwal
Ravi Aggarwal

This document discusses iOS app security best practices. It covers common security breach areas like jailbreak detection, securing sensitive keys, URL schemes, and third-party dependencies. For jailbreak detection, it notes that 100% detection is impossible and the focus should be on making bypassing detection harder. For keys, it recommends hashing and storing them remotely. For URL schemes, it advises moving to universal links and sanitizing input. For dependencies, it notes the risks of incorporating third-party code and importance of staying updated. It concludes by recommending checking the OWASP Mobile Security Testing Guide for vulnerabilities to address.

Related slideshows

Fragments-Plug the vulnerabilities in your App
Fragments-Plug the vulnerabilities in your AppFragments-Plug the vulnerabilities in your App
Fragments-Plug the vulnerabilities in your App
 
React commonest security flaws and remedial measures!
React commonest security flaws and remedial measures!React commonest security flaws and remedial measures!
React commonest security flaws and remedial measures!
 
9 Writing Secure Android Applications
9 Writing Secure Android Applications9 Writing Secure Android Applications
9 Writing Secure Android Applications
 
1 of 28
Download to read offline
iOS App Security Ravi Kumar Aggarwal - 15 Jan 2022 Don’t learn it the hard way
whoami • Engineering Manager at TataCLiQ • ex iOS Lead at Tokopedia • ex iOS Engineer at PaytmMoney @raviAggarwal61 @ravi.aggarwal61
Agenda • Common Security Breach Areas • Jailbreak Detection • Securing Sensitive Keys • URLSchemes • 3rd Party Dependencies • Where to go next?
Jailbreak Detection
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
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
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
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.
100% Probability that a motivated black hat will bypass jailbreak
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 { //… }
Jailbreak Detection Further Reading • OWASP Mobile Security Testing Guide • Xcon
Securing Sensitive Keys
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.
Godbolt Decompiling Swift Code
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.
URLSchemes
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).
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!
What can you do? • Sanitise the input you receive in URLScheme. • Move to Universal Links instead.
3rd Party Dependencies
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.
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
Log4j
22 years Shellshock vulnerability in OpenSSL
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.
Where to go next?
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.
Thank You!

More Related Content

iOS Application Security.pdf

  • 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?
  • 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
  • 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.
  • 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.
  • 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.
  • 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
  • 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.