Part 3: Learning iOS App Pentesting and Application Security with Real-World Case Studies

Welcome to part three of a blog series on iOS Application Security, where we delve into real-world case studies to better understand the vulnerabilities and challenges present in iOS applications. 

In Part 1 and Part 2 of this learning IOS pentesting series, we explored the pitfalls of hardcoding secrets within apps and the potential consequences of such mistakes. Additionally, we examined the risks associated with the insecure integration of third-party libraries and frameworks. 

In part 3, we’ll dive into the consequences of using insecure third-party libraries and the adverse effects of improper SSL pinning implementation. 

Join us as we uncover best practices and strategies to mitigate these threats and enhance the security of iOS applications.

Case Study 5: IOS App Exploitation Through Insecure Third-Party Library

Problem

A fitness-tracking iOS application that allows users to track their workouts, monitor their progress, and share achievements with their friends.  The development team utilized several third-party libraries and frameworks while building the application. However, they did not adequately vet these third-party components, leading to the integration of a library with a known security vulnerability.

Steps Followed

1. I downloaded the iOS app and decrypted it using reverse engineering tools. After analyzing the application source code, I discovered the usage of multiple third-party libraries and frameworks.
2. I researched these libraries and found that one of them had a known security vulnerability that had not been patched in the version used in the application.
3. I exploited the vulnerability in the insecure library, which allowed me to execute arbitrary code within the app's context, potentially leading to unauthorized actions, data manipulation, or application crashes.
4. As a proof of concept, I demonstrated how an attacker could use the vulnerability to access sensitive user data, such as workout history, personal information, and location data.
5. I reported my findings to the fitness tracking company, providing details on the insecure library and the vulnerability it introduced.
   

Practical Steps

You can conduct static analysis on iOS applications using tools such as MobSF.

• For example, here is a screenshot showcasing the results of a static analysis performed on an older version of iGoat's IPA file using MobSF:
  
  
  
  

1. After identifying the vulnerable library, I researched the specific vulnerability and discovered that it was susceptible to a JSON object deserialization attack. This vulnerability allowed an attacker to execute arbitrary code within the application’s context by crafting a malicious JSON object.
2. To exploit the vulnerability, I crafted a malicious JSON object with a custom payload designed to perform unauthorized actions. For example, I could create a payload that reads sensitive user data from the app's local storage and sends it to a remote server:
   
3. I needed to inject the malicious JSON object into the app to execute the payload. I observed that the app fetched workout data from its backend server in JSON format. I then used a man-in-the-middle (MITM) attack to intercept the communication between the application and the backend server, replacing the legitimate workout data with my crafted malicious JSON object.
4. When the app parsed the malicious JSON object using the insecure library, the custom payload was executed within the app's context. As a result, the app reads sensitive user data, such as workout history, personal information, and location data, and sends it to the attacker's remote server.
5. I documented these steps, demonstrated the proof of concept, and reported my findings to the fitness tracking company.

Impact

Upon learning about the vulnerability, the fitness tracking company's security team took immediate action to secure their app. They updated the insecure library to a patched version, audited all third-party components for security vulnerabilities, and implemented a stricter vetting process for future integrations.

Important Lessons

• Thoroughly vet and review all third-party libraries and frameworks before integrating them into an app, ensuring they have a strong security track record.
• Keep all third-party components up to date, applying security patches promptly to prevent known vulnerabilities from being exploited.
• Use SCA tools to find & mitigate vulnerabilities in open-source packages.

Case Study 6: Exploit A Dating App Through Improper Implementation Of SSL Pinning

Problem

A popular dating app allowed users to communicate and share personal information with potential matches securely. The developers attempted to implement SSL pinning to protect users' data during transit. 

The developers hardcoded the public key of the server's certificate but did not properly check the issuer of the certificate, i.e., the intermediate CA and the root CA. This means that the app only verified if the public key matched with the hardcoded value, without ensuring that the certificate was signed by a trusted CA. So, due to improper implementation, the app remained vulnerable to man-in-the-middle (MITM) attacks.

Steps Followed

1. I downloaded the dating app and decrypted it using reverse engineering tools. Upon analyzing the app's source code, I discovered that SSL pinning was implemented. However, a critical flaw rendered it ineffective.
2. The flawed implementation involved hardcoding the certificate's public key in the app, but the app failed to validate the entire certificate chain properly. This left the app susceptible to MITM attacks using a rogue certificate that had the same public key.
3. I set up a rogue server with a self-signed certificate that used the same public key as the legitimate server. I then performed a MITM attack to intercept and modify the traffic between the app and the dating platform's server.
4. By exploiting the improper SSL pinning implementation, I gained access to sensitive user data such as personal information, private messages, and location data.
5. As a proof of concept, I demonstrated how an attacker could compromise user accounts, manipulate their data, or even launch targeted attacks using intercepted information.
6. I reported my findings to the dating app's developers, providing details on the improper SSL pinning implementation and the vulnerabilities it introduced.

Practical Steps

• Below is the public key from the server's certificate which is hardcoded it into the app's source code:
  

• When the app establishes a secure connection with the server, it receives the server's certificate during the SSL/TLS handshake process.
• Instead of properly validating the certificate chain (including the root CA and intermediate CAs), the app only checks if the public key in the received certificate matches the hardcoded value:

• I used OpenSSL to connect to the legitimate server and retrieve its certificate as shown below:
  

• I used the following command to extract the public key from the certificate:

• Then I created a rouge private key, and rouge certificate and completed setting up the rogue server.

Impact

Upon learning about the vulnerability, the dating app's security team took immediate action to secure the app. They fixed the SSL pinning implementation by properly validating the entire certificate chain.

Important Lessons

• Properly implement SSL pinning to ensure the app only communicates with trusted servers using a valid SSL certificate, protecting against MITM attacks.
• Regularly perform security audits and vulnerability assessments to identify and fix potential weaknesses in the app and associated infrastructure.

IOS Pentesting References

Insecure third-party libraries:

• OWASP Mobile Top 10: M8 - Insecure Component Integration
• CWE-1173: Insecure Use of Third-Party Code Libraries

Improper SSL pinning implementation:

• OWASP Mobile Top 10: M3 - Insecure Communication
• SSL Pinning: What Is It and How to Implement It Correctly