‘Almost Every Apple Device’ Vulnerable to CocoaPods • The Register

CocoaPods, an open-source dependency manager used in over three million apps written in Swift and Objective-C, has left thousands of packages vulnerable to compromise for nearly a decade — opening up supply-chain attacks on iOS and macOS apps, according to security researchers.

Israeli firm EVA Information Security announced its findings in a blog post Monday. EVA says CocoaPods migrated all of its “Pods” — a file describing a project’s dependencies — to a new “Trunk server” on GitHub in 2014. As a result of that migration, the authorship of all Pods was reset, and the authors were asked to recover their work.

Some of these were not granted permission and at the time of writing 1,870 Pods have not been claimed by their owners and have therefore been left orphaned – and have become available.

This mess is now known as CVE-2024-38368, which has a CVSS score of 9.3 according to EVA. The issue received this rating because all orphaned Pods were associated with a default email address, and a public API for claiming unclaimed Pods was available until the end of 2023 – without requiring proof of ownership.

To take over a Pod, the attacker only had to send a specific CURL request and Please – they could freely modify the Pod and insert malicious code.

EVA researchers wrote that they have seen no evidence that this mess has been exploited. But given the more than 1 billion 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 entirely possible that “thousands to millions” of apps have been exposed to this flaw.

The fact that we’re aware of this confusion at all is also a bit surprising: The researchers discovered it while performing red-team exercises for a client, not by intentionally examining CocoaPods.

If the EVA team managed to find them, someone else can too.

Have fun: Breach CocoaPods, everyone

The second vulnerability – CVE-2024-38366, CVSS 10.0 – allows remote code execution on the Trunk server by verifying mail exchanges using a vulnerable Ruby RFC822 package. Taking advantage of the fact that the aforementioned package executes host commands on the provided email address without proper validation, a final bash command can be injected to dump session tokens, poison client traffic, or even cause the server to shut down.

Third, there is a vulnerability in the Trunk server source code – CVE-2024-38367, CVSS 8.2 – that presents an interesting exploit chain that leverages standard email scanning software features to steal session verification tokens without requiring user interaction.

The researchers noted that CocoaPods authenticates new devices via an email sent to users who requested a session – but the authentication relies on nothing more than the 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 that is sent to the client to verify the session,” the researchers lamented. Clicking on a link generated by the spoofed XFH header sends a session token directly to the impersonator.

This is where zero-click comes in: Because email scanning services check links to compare them to known phishing templates, researchers have observed automated tools ending up following the link and sending a session token on behalf of the target user. Oops.

“We found that almost every Pod owner has their business email registered on Trunk’s server, making them vulnerable to our no-click takeover vulnerability,” the EVA team warned. “It was fairly easy to take over almost every business Pod account on the (target) system because their email security solutions actively scan every link sent to their inbox.”

The researchers noted that they actually used this method “to compromise the accounts of some of the most popular CocoaPods package owners,” which “we could use … for highly damaging supply chain attacks that could impact the entire Apple ecosystem.”

As mentioned above, the CocoaPods team has patched the issues — and apparently did so months ago — though the details weren’t widely known until EVA released its research today.

“The worst-case scenario is that an attacker could use this technique to gain access to our trunk database,” Orta Therox, a volunteer at the CocoaPods project, wrote in October. “We erase all session keys, which ensures that no one other than those with access to their emails will be able to post updates to these Pods.”

CocoaPods maintainers have been contacted Register did not respond to questions prior to publication.

Another open source security warning

“The discovered CocoaPods vulnerabilities are 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 be in the distinguished company of such malicious exploits as Log4Shell, the recent Polyfill debacle, SolarWinds, and others. Fortunately, it appears that this is not the case – but there is no way to know for sure.

“While there is no direct evidence that any of these vulnerabilities are being exploited in the wild,” EVA researchers noted, lack of evidence is not evidence of absence.

Researchers recommend that all CocoaPods users check for orphaned Pod dependencies, check the checksums of all code downloaded from the CocoaPods Trunk server, review all third-party code, update their CocoaPods installations, and generally be more vigilant about threats related to the open-source software supply chain.

With an estimated 97 percent of all commercial codebases using open source components, this advice applies to virtually everyone – whether or not they are a CocoaPods user. ®