CocoaPods: Almost every Apple device vulnerable to flaws in dependency manager

Flaws were patched last October, having existed for 9 years

CocoaPods, an open-source dependency manager used in over three million applications, has been found to contain several vulnerabilities that could allow malicious actors to claim ownership of thousands of unclaimed "pods" (libraries) and insert malicious code into many popular iOS and macOS apps, according to a report by EVA Security.

So ubiquitous is CocoaPods that, by exploiting these vulnerabilities, an attacker could potentially infect almost every Apple device, the researchers said.

CocoaPods is a dependency manager for Swift and Objective-C projects. As such, it is used to manage all the component parts used when building mobile applications, allowing developers to verify and authenticate the modules they are using.

The vulnerabilities in CocoaPods

The vulnerabilities in CocoaPods stem from a migration in 2014 to a new "Trunk" server, which left thousands of packages "orphaned", with their original owners unidentified. The public API endpoint for claiming pods was still open nine years later, meaning that anyone could claim these orphaned pods without any verification. In addition, an insecure email verification process and a vulnerable Ruby package could have allowed attackers to execute arbitrary code on the Trunk server and manipulate or replace the packages being downloaded.

"By spoofing an HTTP header and taking advantage of misconfigured email security tools, attackers could execute a zero-click attack that grants them access to a developer's account verification token," EVA Security researchers Reef Spektor and Eran Vaknie wrote in a blog post. "This would allow attackers to change packages on the CocoaPods server and result in supply chain and zero-day attacks."

EVA Security reported its discovery to the CocoaPods project, which patched the dependency manager in October 2023.

There is no direct evidence of any of these vulnerabilities being exploited in the wild. However, the researchers note that the absence of evidence is not evidence of absence. The size of the CocoaPods ecosystem, which contains 100,000 libraries, combined with the length of time the vulnerabilities have been available to attackers, means there is certainly no guarantee they have not been used.

The vulnerabilities could even have been exploited to control CocoaPods itself and any published package, with potential access to sensitive data.

"By taking ownership of a part of the iOS/macOS app supply chain ... an attacker would have free rein to access millions of mobile apps and the hundreds of millions of people that use them," the researchers write.

Indeed, the potential impact of these vulnerabilities is enormous, as CocoaPods is the most popular choice among iOS developers. Many of the potentially affected artefacts are dependencies for projects maintained by companies including Google, GitHub, Amazon and Dropbox.

Mitigation

As a first step, developers are advised to review the dependency lists and package managers used in their applications and validate third-party libraries themselves. They should make sure the software is kept updated and avoid using orphaned libraries (EVA identified 1,866 orphaned pods), unmaintained packages, or those without a clear owner. In addition, they should ensure all developers using CocoaPods are using the same version of the packages. They should perform regular security code scans to detect secrets and malicious code on all external libraries, especially CocoaPods. A full list of suggested measures is provided on EVA Security's website.

The vulnerabilities in CocoaPods may have been fixed, but they serve as a timely reminder of the precarious nature of the software supply chain, which is increasingly a target for malicious actors. Third-party software components are present in virtually all applications, both closed- and open-source, and attacks can be extremely hard to detect.

Recent research suggests that defences such as SBOMs, code scanning and restricting access to repositories are not always implemented effectively.