CocoaPods vulnerabilities reported today could allow malicious actors to take over thousands of unclaimed pods and insert malicious code into many of the most popular
iOS and MacOS applications, potentially affecting "almost every Apple device."
E.V.A Information Security researchers found that the three vulnerabilities in the open source CocoaPods dependency manager were present in applications provided by Meta (Facebook, Whatsapp), Apple (Safari, AppleTV, Xcode), and Microsoft (Teams); as well as in
TikTok, Snapchat, Amazon, LinkedIn, Netflix, Okta, Yahoo, Zynga, and many more.
The
vulnerabilities have been patched, yet the researchers still found 685 Pods βthat had an explicit dependency using an orphaned Pod; doubtless there are hundreds or thousands more in proprietary codebases.β
The widespread issue is further evidence of the vulnerability of the software supply chain. The researchers
wrote that they often find that 70-80% of client code they review βis composed of open-source libraries, packages, or frameworks.β
The CocoaPods Vulnerabilities
The newly discovered vulnerabilities β one of which (CVE-2024-38366) received a 10 out of 10 criticality score β actually date from a May 2014 CocoaPods migration to a newΒ 'Trunkβ server, which leftΒ
1,866 orphaned pods that owners never reclaimed.
The other two CocoaPods vulnerabilities (CVE-2024-38368 and CVE-2024-38367) also date from the migration.
For CVE-2024-38368, the researchers said that in analyzing the source code of the βTrunkβ server, they noticed that all orphan pods were associated with a default CocoaPods owner, and the email created for this default owner was unclaimed-pods@cocoapods.org. They also noticed that the public API endpoint to claim a pod was still available, and the API βallowed anyone to claim orphaned pods without any ownership verification process.β
βBy making a straightforward curl request to the publicly available API, and supplying the unclaimed targeted pod name, the door was wide open for a potential attacker to claim any or all of these orphaned Pods as their own,β wrote Reef Spektor and Eran Vaknin.
Once they took over a Pod, an attacker would be able to manipulate the source code or insert malicious content into the Pod, which βwould then go on to infect many downstream dependencies, and potentially find its way into a large percentage of Apple devices currently in use.β
Earlier in 2014, a change was committed to the CocoaPods βTrunkβ source code implementing MX record validation for registered emails. The changes created a new attack path that was identified by analyzing the registration flow, resulting in the CVE-2024-38366 vulnerability. The changes created a new verification process for the user-provided email address using the third-party Ruby gem package rfc-822, which can be attacked in a few ways, potentially resulting in attacks that could βdump pod ownersβ session tokens, poison clientβs traffic or even shut down the server completely.β
In CVE-2024-38367, the researchers found they could spoof XFH headers to
engineer a zero-click account takeover by defeating email security boundaries.
βUsing this method, we managed to take over the owner accounts of some of the most popular CocoaPods packages,β the researchers said. βPotentially we could have used these accounts for highly damaging supply chain attacks that could impact the entire Apple ecosystem.β
DevOps Teams: Get to Work
While the vulnerabilities have been patched, the work for developers and DevOps teams is just getting started.
Developers and DevOps teams that have used CocoaPods in recent years - particularly before October 2023 - "should verify the integrity of open source dependencies used in their application code,β the E.V.A researchers said.
βThe vulnerabilities we discovered could be used to control the dependency manager itself, and any published package.β
Downstream dependencies could mean that thousands of applications and millions of devices were exposed over the last few years, and close attention should be paid to software that relies on orphaned CocoaPod packages that do not have an owner assigned to them.
Developers and organizations should review dependency lists and package managers used in their applications, validate checksums of third-party libraries, perform periodic scans to detect malicious code or suspicious changes, keep software updated, and limit use of orphaned or unmaintained packages.
"Dependency managers are an often-overlooked aspect of software supply chain security," the researchers wrote. "Security leaders should explore ways to increase governance and oversight over the use these tools."