CocoaPods, an open-source dependency manager used in over three million apps coded in Swift and Objective-C, left thousands of packages exposed and ready to be taken for nearly a decade—creating opportunities for malicious attacks supply chain in iOS and macOS apps, according to security researchers.
Israeli firm EVA Information Security announced its discovery in a blog post on Monday. EVA claims that CocoaPods in 2014 migrated all “Pods” — a file that describes a project’s dependencies — to a new “trunk server” on GitHub. In that migration, the authorship of all Pods was restored and the authors asked to reclaim their work.
Some did not, and at the time of writing, 1,870 Pods remained unclaimed by their owners, leaving them orphaned – and accessible.
This mess is now known as CVE-2024-38368, which EVA told us has a CVSS score of 9.3. The issue earned that rating because all orphaned Pods were linked to a default email address, and a public API for claiming undeclared Pods was available until the end of 2023 – without the need to provide any ownership verification.
To claim a Pod, all an attacker had to do was broadcast a special CURL request and voila – they would have a free hand to modify a Pod and inject malicious code.
The EVA researchers wrote that they have seen no evidence that this mess has been exploited. But given the billion-plus iOS devices in use — and the fact that apps from Meta, Apple, Microsoft, TikTok, Amazon and others have been found to use vulnerable Pods — it’s entirely conceivable that “thousands to millions” of apps have been exposed to exploitation from the vulnerability.
The fact that we’re even aware of this fustercluck is also a bit strange: The researchers discovered them while conducting a red team exercise for a client, not through deliberate examination of CocoaPods.
If the EVA team could find them, someone else could too.
Have a lot of fun: Hack CocoaPods, everyone
A second vulnerability – CVE-2024-38366, CVSS 10.0 – allows remote code execution on the Trunk server thanks to mail exchange verification using a vulnerable RFC822 Ruby package. By exploiting the fact that the aforementioned package executes host commands against a given email address without proper authentication, a bash command can be injected at the bottom to discard session tokens, poison client traffic, or even cause a server shutdown.
Third, there is a vulnerability in the source code of the Trunk server – CVE-2024-38367, CVSS 8.2 – that has an interesting exploit chain that relies on standard email scanning software functionality to steal session authentication tokens without having need for user interaction.
CocoaPods authenticates new devices using an email sent to users requesting a session, the researchers noted — but authentication doesn’t rely on anything other than a customer verifying their email address by clicking a link.
“We found that the server will accept a forged XFH header and use it explicitly to construct a URL sent to the client for session verification,” the researchers complain. Clicking the connection established by the forged XFH header transmits a session token directly to the spoofer.
That’s where zero-click comes in: Because email scanning services check links to compare them to known phishing templates, researchers have noticed that automated tools end up following the link and transmitting the session token on behalf of a target user. Oops.
“We have discovered that almost every Pod owner is registered with their organizational email on the Trunk server, which makes them vulnerable to our zero-click retrieval vulnerability,” the EVA team warned. “It was quite simple to get almost any organizational Pod account [a target] system, as their email security solutions are actively scanning every link sent to their inboxes.”
The researchers noted that they actually used the method “to take over the accounts of the owners of some of the most popular CocoaPods packages,” which “we could have used … for very damaging chain attacks supply chain that could affect the entire Apple ecosystem.”
As mentioned above, the CocoaPods team has fixed the issues – and appears to have done so months ago – although the specifics were not widely known until EVA published its research today.
“The worst case scenario is that an attacker could have used this technique to access our trunk database,” Orta Therox, a volunteer on the CocoaPods project, wrote in October. “We’re deleting all session keys, which ensures that no one other than those with access to their emails can post updates to those Pods.”
CocoaPods maintainers contacted by registry 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 reliance 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 been found in the notable company of such malicious exploits as Log4Shell, the recent Polyfill debacle, SolarWinds and others. Fortunately, that doesn’t seem to be the case – but it’s impossible to know for sure.
“While there is no direct evidence of any of these vulnerabilities being exploited in the wild,” the EVA researchers noted, lack of evidence is not proof of absence.
The researchers recommend that everyone using CocoaPods review their dependencies for orphaned Pods, perform checksum verifications on all code downloaded from the CocoaPods Trunk server, review all third-party code, update their installations of CocoaPods and generally be more mindful of open source software supply chain risks.
With around 97 percent of all commercial codebases believed to use open source components, this advice applies to almost everyone – CocoaPods user or not. ®