CocoaPods, an open-source dependency manager used in more than three million apps coded in Swift and Objective-C, left thousands of packages exposed and ready to be supported for nearly a decade — creating opportunities for supply chain attacks on iOS and macOS apps, security researchers say.
Israeli company EVA Information Security announced its discovery in a blog post published Monday. EVA claims that CocoaPods migrated all “Pods” (a file describing a project’s dependencies) to a new “Trunk server” on GitHub in 2014. This migration resulted in resetting the authorship of all Pods and asking authors to reclaim their work.
Some didn’t, and at the time of writing, 1,870 Pods remained unclaimed by their owners, leaving them orphaned – and accessible.
This issue is now known as CVE-2024-38368, which EVA says has a CVSS score of 9.3. The issue got this rating because all orphaned Pods were affiliated with a default email address, and a public API to claim unclaimed Pods was available until the end of 2023, without requiring any ownership verification.
To claim a Pod, all an attacker had to do was pass a particular CURL request, and There – they would have complete freedom to modify a Pod and insert malicious code.
EVA researchers wrote that they have not seen evidence that this flaw has been exploited. But given the billion iOS devices in use and the fact that apps from Meta, Apple, Microsoft, TikTok, Amazon, and others use vulnerable Pods, it is entirely conceivable that “thousands, if not millions” of apps have been exposed to exploitation of this vulnerability.
The fact that we’re aware of this phenomenon is also somewhat coincidental: the researchers discovered it during a red team exercise for a customer, not through any intentional examination of CocoaPods.
If the EVA team could find them, someone else could have too.
Have fun: Breach CocoaPods, everyone
A second vulnerability – CVE-2024-38366, CVSS 10.0 – allows remote code execution on the Trunk server through email exchange verification using a vulnerable RFC822 Ruby package. By exploiting the fact that the aforementioned package executes host commands on a provided email address without proper validation, a terminating bash command can be injected to drain session tokens, poison client traffic, or even trigger a server shutdown.
Third, there is a vulnerability in the Trunk server source code – CVE-2024-38367, CVSS 8.2 – that has an interesting exploit chain that leverages standard email parsing software functionality to steal session validation tokens without requiring user interaction.
CocoaPods authenticates new devices using an email sent to users who request a session, the researchers noted — but the authentication relies on nothing more than a customer verifying their email address by clicking a link.
“We found that the server accepts a forged XFH header and explicitly uses it to construct a URL that is sent to the client to verify the session,” the researchers lamented. Clicking on the link generated by the forged XFH header sends a session token directly to the forger.
That’s where zero-click comes in: As email analysis services check links against known phishing patterns, researchers have observed that automated tools end up following the link and transmitting the session token on behalf of a targeted user. Oops.
“We found that almost all Pod owners are registered with their corporate email address on the Trunk server, making them vulnerable to our zero-click takeover vulnerability,” the EVA team warned. “It was quite simple to take control of almost all organizational Pod accounts in a (target) system, as their email security solutions actively scan every link sent to their inboxes.”
The researchers noted that they actually used this method “to take control of the owner accounts of some of the most popular CocoaPods packages,” which “we could have used… for extremely damaging supply chain attacks that could impact the entire Apple ecosystem.”
As noted above, the CocoaPods team fixed the issues – and appears to have done so months ago – although the details weren’t widely known until EVA published its research today.
“The worst case scenario would be that an attacker used this technique to gain access to our trunk database,” wrote Orta Therox, a CocoaPods volunteer, in October. “We wipe all session keys, which ensures that no one other than those who have access to their email can post updates to these Pods.”
CocoaPods officials contacted by The register did not respond to questions before publication.
Another Open Source Security Warning
“The vulnerabilities discovered in CocoaPods serve as an important reminder of the risks associated with relying on open source code and third-party dependencies,” the researchers wrote – a message we’ve heard often in recent years.
As a supply chain attack, this CocoaPods vulnerability could have fallen into the same illustrious category as such damaging exploits as Log4Shell, the recent Polyfill debacle, SolarWinds, and others. Fortunately, it appears that this is not the case, but it is impossible to be sure.
“While there is no direct evidence that any of these vulnerabilities are being exploited in the wild,” the EVA researchers noted, absence of evidence is not proof of absence.
The researchers recommend that anyone using CocoaPods check their dependencies for orphaned Pods, perform checksum validations on all code downloaded from the CocoaPods Trunk server, verify all third-party code, update their CocoaPods installations, and generally be more mindful of open source software supply chain risks.
With about 97% of all commercial codebases expected to use open source components, this advice applies to almost everyone, CocoaPods user or not. ®