Getting Started with iOS Penetration Testing (Part 2)

March 18, 2022

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:

  1. Bypassing Local Biometric (Touch/Face ID) Authentication [Explained in Part-1]
  2. Excessive Permissions
  3. 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:

  1. Sensitive Data Stored in Plist
  2. Sensitive Data Stored in UserDefaults
  3. Sensitive Data Stored in Keychain
  4. Sensitive Data Stored in Core Data
  5. Sensitive Data Stored in Webkit Caching
  6. Sensitive Data Stored in Realm
  7. Sensitive Data Stored in Couchbase Lite
  8. Sensitive Data Stored in YapDatabase
  9. URL caching (both request and response);
  10. Keyboard press caching
  11. Copy/Paste buffer caching
  12. Insecure Logging
  13. Background Screen Caching
  14. 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:

  1. Lack/Bypass-able SSL Pinning
  2. Communication over HTTP [Unencrypted Communication]
  3. Plain-Text Submission of Sensitive Information
  4. 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:

  1. Guessable/Weak/Default Credentials
  2. 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:

  1. Stealing App and User Data
  2. Accessing Encrypted Files
  3. 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:

  1. IDOR
  2. Privilege Escalation
  3. 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:

  1. Format String Vulnerabilities
  2. Buffer Overflows
  3. Remote Code Execution
  4. 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:

  1. Malware Injection
  2. Stealing Sensitive Data
  3. 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

  1. Launch the DVIA-v2 application and navigate to the Sensitive Information in the Memory section.
  1. Now, run the fridump tool on the application to extract the information from memory
    Tool:https://github.com/Nightbringer21/fridump
    Command: python fridump.py –usb -s DVIA-v2
  2. Open the Strings.txt file and search for sensitive information such as passwords and observe that the sensitive information was found in the application memory.

Webview Issues

  1. Launch the DVIA-v2 application and navigate to the Webview Issues section.
  2. In the Input Field provide a malicious cross-site scripting payload such as <img src=x onerror=alert(1)>
  3. Observe that the webview unsafely rendered the input and resulted in Cross-Site Scripting (XSS).

Anti Hooking/Debugging

An interesting approach using Ghidra to bypass the Anti Hooking and Debugging controls is nicely explained in the following blog:https://philkeeble.com/ios/reverse-engineering/iOS-Anti-Anti-Hooking/

Side Channel Data Leakage

App Screenshot

  1. Launch the DVIA-v2 application and navigate to Side Channel Data Leakage > App Screenshot.
  2. Add Some Information in the input field and background the application
  3. Open Filza and Navigate to /var/mobile/Containers/Data/Application/DVIA-v2/Library/SplashBoard/Snapshots
  4. Open the SceneId and observe that the screenshot is present containing the information.

Pasteboard

  1. Launch the DVIA-v2 application and navigate to Side Channel Data Leakage >Pasteboard
  2. Hook the application using objection and run the following commands:
    objection -g DVIA-v2 explore
    ios pasteboard monitor
  3. Now, add some input in the input box, copy it and observe that the content is visible on the objection console.

Cookies

  1. Launch the DVIA-v2 application and navigate to Side Channel Data Leakage >Cookies
  2. Hook the application using objection and run the following commands:
    objection -g DVIA-v2 explore
    ios cookies get
  3. Observe that the cookies containing username and password are accessible.

Runtime Manipulation

  1. Launch the DVIA-v2 application and navigate to Side Channel Data Leakage >Runtime Manipulation
  2. Hook the application using objection and run the following commands:
    objection -g DVIA-v2 explore
    ios hooking search classes login
  3. Observe that a total of 27 Classes are returned and the class LoginValidate looks interesting.
  1. Now run the following command: ios hooking watch class LoginValidate
  2. Observe that the two highlighted methods were returned.
  1. Now in the application, press the Login Method 1 button and the method isLoginValidated from the class LoginValidate is getting called.
  2. Now run the following command to watch this method: ios hooking watch method “+[LoginValidate isLoginValidated]” — dump-args — dump-return
  3. Now. press the Login Method button again and observe the output as shown in the below image
  1. Now run the following command to bypass the restrictions: ios hooking set return_value “+[LoginValidate isLoginValidated]” true
  1. Press the Login Method 1 button and observe the Success Message.

Binary Protection

  1. Launch MobSF and perform a static analysis on the DVIA-v2 IPA file
  2. Observe that the multiple insecure binary APIs are supported.

Since API penetration testing is a separate topic, we won’t dig into it for this blog. However, this GitHub repository contains great tips and tricks on performing interesting attacks on the APIs: https://github.com/arainho/awesome-api-security

There are many tools are available for performing different analyses on the iOS application and the following GitHub repository contains some useful tools and resources: https://github.com/ansjdnakjdnajkd/iOS

End Notes

In this article, we discussed multiple attack scenarios and other important things to keep in mind while performing iOS penetration testing. With this, it comes to the end of the iOS penetration testing series. In the near future, we will keep this blog post updated to include more relevant information. We hope you enjoy reading this blog and learned something new. Happy Hacking!

Please note that this blog is written for education purpose only and we do not endorse any malicious activities.

🤘 START HUNTING ON YESWEHACK!