iOS is a widely used platform and in the previous article Getting Started with iOS Penetration Testing (Part 1), we discussed basic concepts of the iOS platform, different attack scenarios in static analysis and touched on the basic concepts to get started with the iOS penetration testing.
In this article, we will focus on a more advanced approach and continue solving other challenges available in our test application DVIA-v2, some important tools, and also look at the OWASP Mobile Top 10. This article will give you good knowledge to confidently perform a penetration test on an iOS application.
Introduction to OWASP Mobile Top 10
The OWASP Mobile Top 10 is a list curated from research and feedback that identifies types of security risks faced by mobile applications. The current version of OWASP Mobile Top 10 at the time of writing this blog is OWASP Mobile Top 10 2016.
M1: Improper Platform Usage
The first category in the list of OWASP Mobile Top 10 covers the aspects where an attacker can abuse the security control features provided by the iOS platform. In addition, sometimes due to failure in the proper implementation of platform features, multiple security issues could arise.
There are multiple components that are required to be analyzed under this category such as Biometric Authentication, Keychain, Platform Permission, etc.
Some of the general risks that occur under this category are:
- Bypassing Local Biometric (Touch/Face ID) Authentication [Explained in Part-1]
- Excessive Permissions
- Poorly Configured/Weak Permissions
M2: Insecure Data Storage
The iOS applications often store some data locally in different components. There is a chance of getting sensitive data stored in the local storage that could be exploited if an attacker has access to the physical device of the user.
Some of the general risks that occur under this category are:
- Sensitive Data Stored in Plist
- Sensitive Data Stored in UserDefaults
- Sensitive Data Stored in Keychain
- Sensitive Data Stored in Core Data
- Sensitive Data Stored in Webkit Caching
- Sensitive Data Stored in Realm
- Sensitive Data Stored in Couchbase Lite
- Sensitive Data Stored in YapDatabase
- URL caching (both request and response);
- Keyboard press caching
- Copy/Paste buffer caching
- Insecure Logging
- Background Screen Caching
- Analytics data sent to 3rd parties.
Most of the above-mentioned test cases were discussed in part-1 of the series.
M3: Insecure Communication
The iOS application communications on a client-server architecture. Due to improper/weak implementation of the communication standards such as communication over HTTP, an attacker can attempt to steal sensitive information over unencrypted checks, perform Man-in-the-Middle or attempt to analyze the request/response by capturing them with proxy tools such as Burp Suite.
Some of the general risks that occur under this category are:
- Lack/Bypass-able SSL Pinning
- Communication over HTTP [Unencrypted Communication]
- Plain-Text Submission of Sensitive Information
- Logging Sensitive information in the Logs
M4: Insecure Authentication
When an application fails to properly perform the authentication checks or allows an attacker to manipulate the login/authentication requests to gain access to the victim user’s account, it is generally considered under the Insecure Authentication category.
Some of the general risks that occur under this category are:
- Guessable/Weak/Default Credentials
- Authentication Bypass using attack such as Injection Attacks
M5: Insufficient Cryptography
The iOS applications tend to store the user data or utilize the user data in different client-server requests. Due to a lack of strong cryptography, an attacker may attempt to access the data that is encrypted using the weak cryptographic method and gain hold of sensitive information.
Some of the general risks that occur under this category are:
- Stealing App and User Data
- Accessing Encrypted Files
- Accessing Encrypted Client-Server Request Endpoints
M6: Insecure Authorization
The insecure authentication and insecure authorization are usually two checks which cause confusion. This attack talks about abusing the weak implementation of user authorization checks to perform attacks out of the user’s privilege and access level.
Some of the general risks that occur under this category are:
- IDOR
- Privilege Escalation
- Direct Request
M7: Client Code Quality
Due to the poor code quality, often, an attacker may attempt to pass the crafted inputs to function calls made within an app in an attempt to execute them or observe the application’s behaviour. It may lead to some mal-function and exploitable scenarios in the application.
Some of the general risks that occur under this category are:
- Format String Vulnerabilities
- Buffer Overflows
- Remote Code Execution
- Memory Exhaustion
M8: Code Tampering
If the application does not implement the code tampering checks, an attacker may attempt to modify the application code and inject malicious code such as a backdoor and distribute it using App Store and other methods that could lead to stealing sensitive information and comprising the user’s device as well.
Some of the general risks that occur under this category are:
- Malware Injection
- Stealing Sensitive Data
- Persistent Backdoor
M9: Reverse Engineering
The reverse engineering approach involves analyzing the binary and it’s code using tools such as Hopper, otool, IDA Pro in order to understand the application’s code patterns, various function implementation and performing bypass/attacks using runtime & dynamic instrumentation approaches.
One of the common examples is to analyze the implementation of SSL Pinning logic and understand the functions that are responsible for pinning checks and using tools such as Frida to bypass it by writing a custom logic script.
M10: Extraneous Functionality
In general, before pushing an application to production, the development team keeps code to have easy access to the backend server, create logs to analyze errors or carry staging information and testing details. This code is extraneous to the functioning of the app. Basically, It has no use for the intended use once the app is in production and it is required only during the development cycle.
In certain cases, this code can carry information related to databases, user details, user permissions, API endpoints, etc. or disable functionalities like two-factor authentication.
Since we are now aware of the common security vulnerabilities that are often found in the iOS application, next we will be looking at some of the attack vectors using the DVIA-v2 application and also attempt to see how API analysis looks for the APIs originated from iOS devices.
It is recommended to read the attack description for each section provided in the application to understand the scenario we will be exploiting.
Sensitive Information in Memory
- Launch the DVIA-v2 application and navigate to the Sensitive Information in the Memory section.
