CocoaPods, an open-source dependency manager used in more than 3 million applications coded in Swift and Objective-C, has had thousands of packages exposed and primed for compromise for nearly a decade, creating opportunities for supply chain attacks on iOS and macOS apps, security researchers say.
Israeli firm EVA Information Security announced its discovery in a blog post on Monday. EVA alleges that in 2014, CocoaPods migrated all “Pods” – a file describing a project’s dependencies – to a new “Trunk server” on GitHub. The migration reset the authorship of all Pods, and authors asked to reclaim their work.
Some did not, and at the time of writing there were still 1,870 Pods unclaimed by their owners, meaning they were orphaned and inaccessible.
That mess is now known as CVE-2024-38368, which EVA told us has a CVSS score of 9.3. The issue received that rating because all of the orphaned Pods were connected to a standard email address, and a public API for claiming unclaimed Pods was available until the end of 2023 – without any ownership verification having to be provided.
To claim a Pod, an attacker simply had to send a certain CURL request and there you go – they would have free rein to modify a Pod and insert malicious code.
EVA’s researchers wrote that they’ve seen no evidence that this mess has been exploited. But given the billions of iOS devices in use—and the fact that apps from Meta, Apple, Microsoft, TikTok, Amazon, and others have been found to be using vulnerable Pods—it’s entirely possible that “thousands to millions” of apps were exposed to exploitation of the vulnerability.
The fact that we even know about this nonsense is actually quite a coincidence: the researchers discovered it while conducting a red team exercise for a client, not by purposefully examining the CocoaPods.
If the EVA team could find them, someone else could have too.
Enjoy Breach CocoaPods, everyone
A second vulnerability – CVE-2024-38366, CVSS 10.0 – allows remote code execution on the Trunk server via mail exchange authentication using a vulnerable RFC822 Ruby package. By exploiting the fact that the aforementioned package executes host commands against a provided email address without proper validation, a trailing bash command can be injected to dump session tokens, poison client traffic, or even trigger a server shutdown.
Third, there is a vulnerability in the Trunk server’s native source code – CVE-2024-38367, CVSS 8.2 – that has an interesting exploit chain that relies on standard functionality of email scanning software 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. However, authentication doesn’t rely on anything other than a client verifying its 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 authenticate the session,” the researchers complained. Clicking on the link generated by the forged XFH header sends a session token directly to the spoofer.
This is 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 eventually follow the link and send the session token on behalf of an intended user. Oops.
“We discovered that almost every Pod owner is registered with their organizational email address on the Trunk server, making them vulnerable to our zero-click takeover vulnerability,” the EVA team warned. “It was quite easy to take over almost every organizational Pod account in [a target] system, because their email security solutions actively scan every link sent to their inbox.”
The researchers noted that they actually used the method “to take over the owner accounts of some of the most popular CocoaPods packaging,” which “we could have used … for highly damaging supply chain attacks that could impact the entire Apple ecosystem.”
As noted above, the CocoaPods team fixed the issues – and appeared to have done so months ago – although the details weren’t publicly known until EVA published its investigation today.
“The worst-case scenario is that an attacker could have used this technique to gain access to our trunk database,” Orta Therox, a volunteer with the CocoaPods project, wrote in October. “We wipe all session keys, which ensures that no one but those with access to their emails can post updates to those Pods.”
CocoaPods administrators contacted by The register did not respond to questions prior to publication.
Another open source security warning
“The vulnerabilities discovered in CocoaPods provide 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 malicious exploits such as Log4Shell, the recent Polyfill debacle, SolarWinds, and others. Fortunately, that does not appear to be the case, but it is impossible to know for sure.
“While there is no direct evidence that these vulnerabilities are being exploited in the wild,” the EVA researchers noted, the absence of evidence is not evidence of absence.
The researchers advise anyone using CocoaPods to check the dependencies of abandoned Pods, perform checksum validation on all code downloaded from the CocoaPods Trunk server, review all third-party code, update their CocoaPods installations, and generally pay more attention to risks in the open-source software supply chain.
With an estimated 97 percent of all commercial codebases expected to use open source components, that advice applies to virtually everyone – CocoaPods user or not.®