3 PEAT
GigaOm Names Cobalt an “Outperformer” for Third Consecutive Year in Annual Radar Report for PTaaS.
3 PEAT
GigaOm Names Cobalt an “Outperformer” for Third Consecutive Year in Annual Radar Report for PTaaS.

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:

    Screenshot 2023-09-05 at 1.09.09 PM

  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:
    Screenshot 2023-09-05 at 1.11.26 PM
  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:
Screenshot 2023-09-05 at 1.30.55 PM
  • 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:
Screenshot 2023-09-05 at 1.32.17 PM
  • I used OpenSSL to connect to the legitimate server and retrieve its certificate as shown below:
Screenshot 2023-09-05 at 1.33.09 PM
  • I used the following command to extract the public key from the certificate:

Screenshot 2023-09-05 at 1.34.06 PM

  • 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:

Improper SSL pinning implementation:

 




 

Back to Blog
About Swaroop Yermalkar
Swaroop Yermalkar is a seasoned cybersecurity professional with over 11 years of industry experience. He has been a Cobalt Core Lead Pentester since 2016. In the past, Swaroop has collaborated with organizations such as Philips Healthcare, Khoros, Traveloka, and Persistent Systems, taking on various roles such as Security Engineer and Head of Product Security. Swaroop is the author of the popular book, "Learning iOS Penetration Testing," which offers a comprehensive guide to iOS app security testing and vulnerability assessment. Additionally, Swaroop leads the open-source project OWASP iGoat, an initiative focused on advancing mobile security through practical learning and hands-on experience. Swaroop holds multiple cybersecurity certifications, such as OSCE, OSCP, OSWP, and CREST CRT. More By Swaroop Yermalkar
Learning iOS App Pentesting and Security Part 1
This blog is a three-part series focused on iOS app penetration testing. Swaroop Yermalkar, who is a Core Penetration Tester, shares their experiences and knowledge in various types of pentesting, including mobile app security. The blog aims to provide a comprehensive guide to improving knowledge of iOS security and penetration testing methodologies through real-world case studies.
Blog
Jun 13, 2023
iOS App Pentesting and Security with Real-World Case Studies Part 2
In part 2 of our IOS pentesting series, we will explore two additional case studies. One of them is about a ride-sharing app, and the other is about an E-commerce app. These case studies highlight the risks associated with insecure practices in iOS app development, such as hardcoding credentials and the exploitation of third-party libraries, emphasizing the importance of secure coding, data storage, and access control measures.
Blog
Jun 26, 2023