AusCERT - Developing Secure iOS Applications
0 likes457 views
Michael Gianarakis' presentation discusses developing secure iOS applications. It provides an overview of the iOS application attack surface and common security issues. It outlines secure design principles such as not trusting the client/runtime, understanding the app's risk profile, implementing anti-debugging controls, jailbreak detection, and address space validation. The presentation aims to help developers design apps that are secure against common attacks.
AusCERT - Developing Secure iOS Applications
- 1. Developing Secure iOS Applications Michael Gianarakis AusCERT 2017
- 2. whoami @mgianarakis Director, Trustwave SpiderLabs SecTalks Brisbane Flat Duck Justice Warrior
- 3. This Presentation • Aims to give a good overview of how to design secure iOS applications • Focuses on the key security issues commonly found in iOS applications • Not a guide to hacking iOS applications
- 4. Topics • Overview of the iOS attack surface • Common iOS security issues • Secure iOS application design principles • Secure development approaches for key security iOS issues
- 5. iOS Application Attack Surface
- 7. Your App Other Apps Network iOS Device Your Backend 3rd Party Services Man in the middle attacks
- 8. Your App Other Apps Network iOS Device Your Backend 3rd Party Services Man in the middle attacks Server compromise and web attacks
- 9. Your App Other Apps Network iOS Device Your Backend 3rd Party Services Man in the middle attacks Server compromise and web attacks
- 10. Your App Other Apps Network iOS Device Your Backend 3rd Party Services Man in the middle attacks Server compromise and web attacks Jailbroken or compromised device
- 11. Your App Other Apps Network iOS Device Your Backend 3rd Party Services Malicious apps Man in the middle attacks Server compromise and web attacks Jailbroken or compromised device
- 12. Your App Other Apps Network iOS Device Your Backend 3rd Party Services Malicious apps Man in the middle attacks Server compromise and web attacks Jailbroken or compromised device
- 13. Understanding the Risk Profile of Your App • Important first step that is often overlooked. • Drives the security design of your application • Key considerations: • What information is in the app and how sensitive/valuable is it? • Who are the likely threat actors? How capable are they? • What are the likely attack scenarios for each threat actor? • What is your tolerance for risk? • Regulatory requirements?
- 14. Common iOS Application Security Issues
- 15. Common Issues • Based on working with a range of companies and a variety of applications including: • Mobile banking and trading apps • Board paper apps • Internal business apps • Retail apps • Social networking apps • Games
- 16. Binary and runtime security issues
- 17. Transport layer security issues
- 19. Get these right and you are ahead of the pack
- 20. Secure iOS Design Principles
- 21. Don’t trust the client or the runtime environment
- 22. Users will connect to untrusted networks
- 23. Don’t store anything sensitive on the device
- 24. Binary and Runtime Security
- 25. Binary and Runtime Security • As a reflective language, Objective-C can observe and modify it’s own behaviour at runtime. • Can be great from a development perspective • Not so much from a security perspective
- 26. Binary and Runtime Security • The ability to create and call ad hoc classes and methods on the fly allows attackers to manipulate and abuse the runtime of the application: • Bypass security locks • Break logic checks • Escalate privilege • Steal information from memory. • Implementing runtime security checks significantly increases the security of your application • You should always assume that your application will run on a compromised device
- 27. What about Swift? • Less dynamic than Objective-C • Less flexible than Objective-C in some areas • Harder to perform the dynamic techniques described previously in the same way but still possible - particularly in mixed runtime apps • Greater dynamism planned for future versions of Swift
- 28. Aside - Compromised Devices
- 29. Myths Surrounding Jailbreaking • Generally speaking, iOS is one of the most secure operating systems available • One of the defining security features of iOS is the chain of trust. Every bit of code is signed and approved by Apple. • Break that trust and all bets are off
- 30. Myths Surrounding Jailbreaking • Some of the security issues discussed in this presentation will require a compromised device • This is usually the cause of a lot of misunderstanding when it comes to assessing the impact of these issue
- 31. Myth 1 - Public jailbreaks are the only jailbreaks
- 32. Myth 1 - Public jailbreaks are the only jailbreaks • I often hear “but there is no jailbreak for version x.x.x so we are safe” • FACT: Public jailbreaks for every version of iOS released so far • FACT: Not all users update to the latest firmware • FACT: iOS vulnerabilities are extremely valuable, there are many more exploits than just those that people give out for free on the internet
- 33. Myth 2 - Jailbreaks require physical access to the device
- 34. Myth 2 - Jailbreaks require physical access to the device • I often hear “well someone would need to steal the device to compromise it” • FACT: Not all exploits require physical access. • jailbreakme.com TIF image processing vulnerability and PDF processing vulnerability required only a user visit a web page in Safari • Remote code execution via SMS found by Charlie Miller (https://www.blackhat.com/ presentations/bh-usa-09/MILLER/BHUSA09-Miller-FuzzingPhone-PAPER.pdf) • Nitro JIT vulnerability to download and execute unsigned code via POC app that was approved also found by Charlie Miller (http://reverse.put.as/wp-content/uploads/2011/06/ syscan11_breaking_ios_code_signing.pdf) • Vulnerability in carrier mandated baseband control protocols by Matt Solnik and Marc Blanchou (https://www.blackhat.com/docs/us-14/materials/us-14-Solnik-Cellular- Exploitation-On-A-Global-Scale-The-Rise-And-Fall-Of-The-Control-Protocol.pdf)
- 35. Myth 3 - Jailbreaks are always obvious to the user
- 36. Myth 3 - Jailbreaks are always obvious to the user • It is a commonly held misconception that if Cydia is not on the device then it is not jailbroken. • Cydia is an app that is commonly installed with public jailbreaks but is certainly not a prerequisite or in any way required for a jailbreak. • In fact, any kind of targeted exploit is unlikely to install Cydia in the first place.
- 37. Myth 4 - Jailbreaking is Apple’s problem
- 38. Myth 4 - Jailbreaking is Apple’s problem • FACT: The security of your app, your data and your users is your responsibility. • FACT: The security risk to your organisation is your responsibility. You will be the one that suffers the impact if your app is compromised and you should be actively managing that risk. • FACT: Apple won’t secure your app for you.
- 39. Myth 5 - You can completely protect against jailbreaking
- 40. Myth 5 - You can completely protect against jailbreaking • FACT: Unfortunately you will never be able to completely secure an application. • The idea is to raise the bar for the security of your app so that it becomes too difficult or costly to attack.
- 41. </aside>
- 42. Debug Check • A simple and effective method of securing the runtime is to implement anti-debugging control. • There may be reasons to allow an application to run on a jailbroken device but there are no legitimate reasons for debugging a production application
- 43. Debug Check • Debugging protection can be implemented using the following techniques: • Periodically monitoring the process state flag to determine if application process is being debugged and then terminating the process. • Using the ptrace request PT_DENY_ATTACH two prevent future tracing of the process. This can be done with the following function call from within the application: • ptrace(31,0,0,0) • These techniques should be used in conjunction with each other to provide a more robust anti-debugging control.
- 44. Jailbreak Detection • There are multiple ways to implement jailbreak detection but the two most common methods are: • File system check • Sandbox integrity check
- 45. File System Check • File system checks test for the presence of files that are typically found on jailbroken devices. • Some examples of files to look for: • /Library/MobileSubstrate/MobileSubstrate.dylib • /var/cache/apt • /var/lib/apt • /bin/bash and /bin/sh • /usr/sbin/sshd and /etc/ssh/sshd_config
- 46. File System Check • When implementing a file system check you should ensure you check for multiple files using different methods such as fileExistsAtPath and isReadableFileAtPath • This protects against attacks that simply patch the implementation of these methods.
- 47. Sandbox Integrity Check • A sandbox integrity check tests that the integrity of Apple’s sandbox is intact on the device, and that the application is running inside it. • A sandbox integrity check works by attempting to perform an operation that would not typically succeed on a device that has not been jailbroken. • A common test is to attempt to use the fork function to spawn a new child process • If it works - sandbox integrity is compromised • If it doesn’t - all good
- 48. Jailbreak Detection • Check out the IMAS project’s Security Check module https:// github.com/project-imas/security-check • A bit old now but still solid
- 49. Inline Functions • Any sensitive functions such as the security checks should be compiled as inline functions • Inlining functions complicates attacks that involve editing memory and patching the application by forcing an attacker to find and patch all occurrences of the code. • Specify a function as inline using the __attribute__((always_inline)) compiler directive.
- 50. Inline Functions • This directive may not always be honoured however. To minimise the chance that this will happen configure the following: • Set the -finline-limit compiler flag high enough to allow for inlining of your code (e.g. 5000) • Set the optimisation level at least -O1 • Don’t use -unit-at-a-time (note this is automatically set at -O3 and above) • Don’t use -keep-inline-functions if your functions are static
- 51. Address Space Validation • Any time malicious code is injected into your application it must be loaded into an address space • Validating the address space adds complexity to attacks as it forces an attacker to inject the malicious code into the existing address space with the valid code or attacking dynamic linker
- 52. Address Space Validation • The dladdr function in the dynamic linker library returns information about the address space a particular function belongs to. • Passing it the function pointer of a class’s method implementation can determine whether it came from your app, Apple’s frameworks, or an unknown/malicious source
- 53. Avoid Simple Logic • Simple logic checks for security functions and business logic are susceptible to to manipulation. • Examples include: • - (BOOL) isLoggedIn • BOOL isJailbroken = YES • - (void) setDebugFlag
- 55. Securing Memory • Instance variables stored within Objective-C objects can be easily mapped inside the Objective-C runtime. • Never store anything in memory until the user has authenticated and data has been decrypted. • Manually allocate memory for sensitive data rather than storing the data (or pointers to this data) inside Objective-C instance variables. • Wipe sensitive data from memory when it’s not needed.
- 56. Securing Memory
- 58. Transport Layer Security • Users will connect their devices to untrusted networks • If your app handles sensitive data you should be encrypting all traffic between the app and the back end.
- 59. App Transport Security • App Transport Security (ATS) was introduced in iOS 9 requires that all apps use HTTPS to secure all network connections • Use of ATS is intended to mandated by Apple for all App Store apps - original deadline was the end of 2016 but this was extended • Forces the use of the latest protocol versions (i.e TLS v1.2)
- 60. App Transport Security • There is some fine grained control available to developers • Can set per domain exceptions in Info.plist
- 61. App Transport Security • Possible to completely bypass ATS • Don’t do this….
- 62. Cipher Suites • You should disable support for low and medium strength cipher suites on the server. • Can also control on the client to some extent although less relevant now with ATS • If using NSURLSession you can specify the minimum supported TLS protocol version by setting the TLSMinimumSupportedProtocol property in the NSURLSessionConfiguration • If using NSURLConnection there is no API to set minimum protocol however it’s possible by working with lower level C functions in the older Core Foundation frameworks but not worth it
- 63. Certificate Validation • Always perform certificate validation checks • When using Apple frameworks iOS will accept a certificate if it’s signed by a CA in the trust store • Certificate validation checks will often be overridden in development to avoid issues with self-signed certs. • Typically this is encapsulated in a variable somewhere or in some other simple logic that can be subverted.
- 65. Certificate Validation • To avoid having to do this, use valid certs in development (e.g. free certs) • If you do need to disable validation, ensure that the production builds essentially “hard code” validation. • Consider certificate pinning.
- 66. Certificate Pinning • Mobile apps are great candidates for certificate pinning as they only need to communicate with a small, clearly defined set of servers • Certificate pinning improves security by removing the need to trust the certificate authorities. • iSEC partners have a great library for implementing certificate pinning https://github.com/iSECPartners/ssl-conservatory • It is important to remember that when pinning a certificate that if you need to revoke the certificate it will mean an app update.
- 67. Data Security
- 68. Two types of data security issues….
- 69. Sensitive data stored on the device by the application that was not secured appropriately by the developer
- 70. Unintended data leakage via system functionality
- 71. Insecure Data Storage • It’s common to find sensitive data stored insecurely on the device. • As a general rule sensitive information should not be stored on the device at all. • Really consider the need to store sensitive information on the device. Generally it is functionally and technically possible to not store the data at all.
- 72. Property List Files • Don’t store sensitive information using NSUserDefaults. Plist files are unencrypted and can easily be retrieved from the device and backups • Find all sorts of sensitive information stored in the clear in property list files including: • Passwords • Session tokens • Sensitive configuration items • PII (if you consider that sensitive)
- 73. SQLite Databases • Avoid storing sensitive information in SQLite databases if at all possible. • If you need to store sensitive information encrypt the database using SQLCipher https://github.com/sqlcipher/sqlcipher • If you are using Core Data the Encrypted Core Data module of the IMAS project leverages SQLCipher to encrypt all data that is persisted https://github.com/project-imas/encrypted-core-data/
- 74. Data Protection APIs • If you need to write files with sensitive information to the device (not credentials) at a minimum write files with an appropriate data protection attribute • If you don’t need to access the file in the background use NSFileProtectionComplete (for NSFileManager) or NSDataWritingFileComplete (for NSData). • With this attribute set the file is encrypted on the file system and inaccessible when the device is locked.
- 75. Data Protection API • If you need to access the file in the background use NSFileProtectionCompleteUnlessOpen for (NSFileManager) or NSDataWritingFileProtectionCompleteUnlessOpen (for NSData) • With this attribute set the file is encrypted on the file system and inaccessible while closed. • When a device is unlocked an app can maintain an open handle to the file even after it is subsequently locked, however during this time the file will not be encrypted.
- 76. Unintended Data Leakage • Sensitive data captured and stored automatically by the operating system. • Often developers are unaware that the OS is storing this information.
- 77. Background Screenshot • Every time an application suspends into the background, a snapshot is taken to facilitate the launch animation. • Stored unencrypted in the app container. • This allows attackers to view the last thing a user was looking at when the application was backgrounded.
- 79. Background Screenshot • Place content clearing code in the state transition methods applicationDidEnterBackground and applicationWillResignActive • The simplest way to clear the screen contents is to set the key window’s hidden property to YES.
- 80. Background Screenshot • Be careful, if there are any other views behind the current view, these may become visible when the key window is hidden. • Other methods: • Manually clearing sensitive info from the current view • Placing the launch image in the foreground • Note: ingoreSnapshotOnNextApplicationLaunch will not prevent the screenshot from being taken
- 81. URL Caching • iOS automatically caches requests and responses for protocols that support caching (e.g. HTTP/HTTPS) and stores them unencrypted in a SQLite database in the app container. • Make sure to configure the server to send the appropriate cache control headers • Cache-Control: no-cache, no-store • Expires: 0 • Pragma: no-cache
- 82. URL Caching • Can also control caching in the client. • For NSURLConnection implement the connection:willCacheResponse: delegate method • For NSURLSession set the URLCache property to NULL
- 83. Logging • Less of an issue since iOS 7 • Pre-iOS 7 any app was able to view the device console and thus any sensitive data that was logged. • Still a good idea to make sure nothing is sensitive is logged. • If you must log sensitive information in development for debugging purposes special care should be taken to ensure that this code is not pushed to production. • One way to do this is to redefine NSLog with a pre-processor macro such as #define NSLog(…)
- 84. Pasteboard • When the Cut or Copy buttons are tapped, a cached copy of the data stored on the device’s clipboard -/private/var/mobile/Library/ Caches/com.apple.UIKit.pboard/pasteboard. • If the application handles sensitive data that may be copied to the pasteboard consider disabling Copy/Paste functionality for sensitive text fields (note this is done by default for password fields)
- 85. Pasteboard • To disable pasteboard operations for sensitive fields subclass UITextView and override the canPerformAction:withSender: method to return NO for actions that you don’t want to allow or just disable the menu completely
- 86. Autocorrect Cache • iOS keeps a binary keyboard cache containing ordered phrases of text entered by the user – /private/var/mobile/Library/Keyboard/ dynamic-text.dat • To avoid writing data to this cache you should turn autocorrect off in text fields whose input should remain private. • To turn autocorrect off, the developer should set textField.autocorrectionType to UITextAutocorrectionTypeNo for all sensitive text fields
- 87. Cryptography • Getting cryptography right in mobile apps is difficult. • The primary challenge is key management. • Most apps fall prey to storing the key with the lock. • Need to use a key derivation function.
- 88. Key Management • Don’t hard code an encryption key in the binary as it can easily be retrieved running strings on the binary. • Storing an encryption key in the Keychain is not secure on compromised devices. • On a compromised device encryption keys can also be retrieved from memory. You should manually allocate memory for encryption keys rather than storing them in Objective-C instance variables. • Wipe keys from memory when not needed.
- 89. Key Management • Use a key derivation function to derive a key to use to encrypt the master key. • Should be based on a secret input such as the user’s password. • Don’t just use a cryptographic hash of the key. • Use a sensible salt such as the identifierForVendor
- 90. Insecure Algorithms • Shouldn’t need to tell this group but • MD5, SHA1, RC4, MD4 algorithms are weak and should not be used
- 91. Custom Encryption Algorithms • Don’t do it.
- 93. Q&A? Twitter: @mgianarakis Blog that hasn’t been updated in years: eightbit.io