Logo
ScienceStack
Table of Contents
Fetching ...
Sign In

Supply Chain Insecurity: Exposing Vulnerabilities in iOS Dependency Management Systems

David Schmidt, Sebastian Schrittwieser, Edgar Weippl

TL;DR

The paper investigates supply chain insecurity in iOS dependency management, revealing that iOS apps leak internal library names and versions, enabling dependency confusion and potential RCE on developer machines and build servers. It conducts a measurement study on 9,212 apps, finding that a substantial fraction are vulnerable to dependency confusion and that hundreds of libraries and thousands of repositories are at risk of hijacking through abandoned domains or GitHub namespaces. By extending analysis to Cargo, Go modules, npm, pip, and Maven, the authors compare defenses and propose mitigations such as explicit private dependency sources, disabling install-time code execution, enforcing 2FA, and hosting dependencies directly. The findings highlight concrete, actionable threats in mobile software supply chains and offer cross-ecosystem defenses with practical implications for developers and maintainers.

Abstract

Dependency management systems are a critical component in software development, enabling projects to incorporate existing functionality efficiently. However, misconfigurations and malicious actors in these systems pose severe security risks, leading to supply chain attacks. Despite the widespread use of smartphone apps, the security of dependency management systems in the iOS software supply chain has received limited attention. In this paper, we focus on CocoaPods, one of the most widely used dependency management systems for iOS app development, but also examine the security of Carthage and Swift Package Manager (SwiftPM). We demonstrate that iOS apps expose internal package names and versions. Attackers can exploit this leakage to register previously unclaimed dependencies in CocoaPods, enabling remote code execution (RCE) on developer machines and build servers. Additionally, we show that attackers can compromise dependencies by reclaiming abandoned domains and GitHub URLs. Analyzing a dataset of 9,212 apps, we quantify how many apps are susceptible to these vulnerabilities. Further, we inspect the use of vulnerable dependencies within public GitHub repositories. Our findings reveal that popular apps disclose internal dependency information, enabling dependency confusion attacks. Furthermore, we show that hijacking a single CocoaPod library through an abandoned domain could compromise 63 iOS apps, affecting millions of users. Finally, we compare iOS dependency management systems with Cargo, Go modules, Maven, npm, and pip to discuss mitigation strategies for the identified threats.

Supply Chain Insecurity: Exposing Vulnerabilities in iOS Dependency Management Systems

TL;DR

The paper investigates supply chain insecurity in iOS dependency management, revealing that iOS apps leak internal library names and versions, enabling dependency confusion and potential RCE on developer machines and build servers. It conducts a measurement study on 9,212 apps, finding that a substantial fraction are vulnerable to dependency confusion and that hundreds of libraries and thousands of repositories are at risk of hijacking through abandoned domains or GitHub namespaces. By extending analysis to Cargo, Go modules, npm, pip, and Maven, the authors compare defenses and propose mitigations such as explicit private dependency sources, disabling install-time code execution, enforcing 2FA, and hosting dependencies directly. The findings highlight concrete, actionable threats in mobile software supply chains and offer cross-ecosystem defenses with practical implications for developers and maintainers.

Abstract

Dependency management systems are a critical component in software development, enabling projects to incorporate existing functionality efficiently. However, misconfigurations and malicious actors in these systems pose severe security risks, leading to supply chain attacks. Despite the widespread use of smartphone apps, the security of dependency management systems in the iOS software supply chain has received limited attention. In this paper, we focus on CocoaPods, one of the most widely used dependency management systems for iOS app development, but also examine the security of Carthage and Swift Package Manager (SwiftPM). We demonstrate that iOS apps expose internal package names and versions. Attackers can exploit this leakage to register previously unclaimed dependencies in CocoaPods, enabling remote code execution (RCE) on developer machines and build servers. Additionally, we show that attackers can compromise dependencies by reclaiming abandoned domains and GitHub URLs. Analyzing a dataset of 9,212 apps, we quantify how many apps are susceptible to these vulnerabilities. Further, we inspect the use of vulnerable dependencies within public GitHub repositories. Our findings reveal that popular apps disclose internal dependency information, enabling dependency confusion attacks. Furthermore, we show that hijacking a single CocoaPod library through an abandoned domain could compromise 63 iOS apps, affecting millions of users. Finally, we compare iOS dependency management systems with Cargo, Go modules, Maven, npm, and pip to discuss mitigation strategies for the identified threats.
Paper Structure (38 sections, 1 figure, 4 tables)

This paper contains 38 sections, 1 figure, 4 tables.

Table of Contents

  1. Introduction
  2. Dependency Management and Attacks
  3. Dependency Management Systems
  4. Dependency Location
  5. Dependency Ownership
  6. Attack Scenarios
  7. Dependency Confusion
  8. Typo Squatting and Social Engineering
  9. Package Hijacking
  10. iOS Dependency Management
  11. CocoaPods
  12. Dependency Confusion Attacks
  13. Dependency Hijacking
  14. Carthage and SwiftPM
  15. Measurement of Vulnerable iOS Apps
  16. ...and 23 more sections

Figures (1)

  • Figure 1: GitHub displays whether the repository is available or has been retired before creating it. Since we do not create the repository, the URL forwarding remains functional.