CocoaPods, an open-source dependency manager used in over three million applications coded in Swift and Objective-C, left thousands of packages exposed and ready for takeover for nearly a decade – thereby creating opportunities for supply chain attacks on iOS and macOS apps, according to security researchers.
Israeli firm EVA Information Security announced its discovery in a Monday blog post. EVA claims CocoaPods in 2014 migrated all “Pods” – a file describing a project’s dependencies – to a new “Trunk server” on GitHub. That migration saw authorship of all Pods reset, and authors asked 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.
That mess is now known as CVE-2024-38368, which EVA told us has a CVSS score of 9.3. The problem earned that rating because all orphaned Pods were affiliated with a default email address, and a public API for claiming unclaimed Pods was available until late 2023 – with no need to provide any verification of ownership.
To claim a Pod, all an attacker needed to do was transmit a particular CURL request, and voila – they would have free rein to modify a Pod and insert malicious code.
EVA’s researchers wrote that they haven’t seen evidence of this mess having 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 is absolutely conceivable that “thousands to millions” of apps have been exposed to exploitation by the vulnerability.
The fact we’re even aware of this fustercluck is a bit serendipitous, too: The researchers discovered them when performing a red team exercise for a client, not through intentional examination of CocoaPods.
If the EVA team could find them, someone else could have, too.
Have lots of fun: Breach CocoaPods, everyone
A second vulnerability – CVE-2024-38366, CVSS 10.0 – allows for remote code execution on the Trunk server thanks to mail exchange verification using a vulnerable RFC822 Ruby package. By exploiting the fact the aforementioned package executes host commands against a provided email address without proper validation, a trailing bash command can be injected in order to dump session tokens, poison client traffic or even trigger a server shutdown.
Third, there’s a vulnerability in the Trunk server’s own source code – CVE-2024-38367, CVSS 8.2 – that has an interesting exploitation chain relying on standard functionality of email scanning software to steal session validation tokens without the need for user interaction.
CocoaPods authenticates new devices using an email sent to users who request a session, the researchers noted – but authentication doesn’t rely on anything but a client verifying their email address by clicking a link.
“We found that the server will accept a spoofed XFH header and use it explicitly to construct a URL sent to the client for verifying the session,” lamented the researchers. Clicking the link generated by the spoofed XFH header transmits a session token right to the spoofer.
Here’s where the zero-click comes in: Because email scanning services check links to compare them to known phishing templates, the researchers observed that automated tools end up following the link and transmitting the session token on a targeted user’s behalf. Oops.
“We have found that almost every Pod owner is registered with their organizational email on the Trunk server, which makes them vulnerable to our zero-click takeover vulnerability,” warned the EVA team. “It was quite simple to take over almost every organizational Pod account in [a target] system, since 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 owner accounts of some of the most popular CocoaPods packages,” which “we could have used … for highly damaging supply chain attacks that could impact the entire Apple ecosystem.”
As noted above, the CocoaPods team has patched the issues – and appeared to do so months ago – though specifics weren’t widely known until EVA published its research today.
“The worst case scenario is that an attacker could have used this technique to get access to our trunk database,” Orta Therox, a volunteer on the CocoaPods project, wrote in October. “We are wiping all session keys, which ensures no-one other than those with access to their emails can post updates to those Pods.”
CocoaPods maintainers contacted by The Register didn’t 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 found itself in the illustrious company of such damaging exploits as Log4Shell, the recent Polyfill debacle, SolarWinds and others. Luckily, it appears that’s not 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, absence of evidence is not evidence of absence.
The researchers recommend everyone using CocoaPods review their dependencies for orphaned Pods, perform checksum validations on all code downloaded from the CocoaPods Trunk server, review all third-party code, update their CocoaPods installations and generally be more attentive to open source software supply chain risks.
With an estimated 97 percent of all commercial codebases believed to be utilizing open source components, that advice applies to pretty much everyone – CocoaPods user or not. ®