Virtually every single Apple device on earth was exposed to a number of critical vulnerabilities through the dependency manager CocoaPods, new research has revealed.
CocoaPods is a popular open-source dependency manager for Swift and Objective-C used by Apple developers to manage external libraries, with around 100,000 libraries used in over three million mobile apps.
EVA Information Security revealed it found several vulnerabilities in CocoaPods that could allow an attacker to claim ownership of potentially thousands of unclaimed pods and execute arbitrary code on the service’s trunk server.
According to the investigation, the vulnerabilities arose in 2014, and were only patched in October 2023, lying dormant for nine years waiting to be exploited.
The first of these vulnerabilities arose after a 2014 migration to a new trunk server left thousands of orphaned packages, meaning the original owner is unknown, although many of them are still being used in other libraries.
This meant attackers could use a public API to claim the pods without any verification required, with almost 2,000 pods still unclaimed by their owners, and waiting to be claimed by threat actors.
These pods could be injected with malicious code and used in supply chain attacks that could compromise potentially millions of iOS and MacOS devices around the world, EVA team warned.
This flaw, CVE-2024-38368, designated a 9.3 on the CVSS, also allowed attackers to remove all owners from any pod, making them available to be claimed by malicious parties too.
The second vulnerability EVA flagged, CVE-2024-38367, is a session hijacking flaw that leverages a loophole in CocoaPods’ authentication process allowing attackers to manipulate the verification process leading to a full takeover of the CocoaPods trunk account.
EVA’s investigation stated that CocoaPods authenticates new devices via email, requiring the user to simply verify their email address by clicking a link, but this functionality could easily be hijacked, the report warned.
“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.” EVA researchers said.
EVA noted that with a few extra steps attackers could turn this into a zero-click account takeover attack. Attackers can rely on the fact that most email servers feature automated phishing detection tools that scan potentially dangerous links.
But when scanning the spoofed CocoaPods validation link, the tools inadvertently transmit the session token to the attacker, which they can use to validate their session and take control over the account and its packages.
Critical flaw could've spelled disaster for Apple devices
Changes to the CocoaPods trunk source code to create a new email verification workflow also created a new attack path, EVA reported, opening the door for the third, and most serious, vulnerability.
Rated 10 on the CVSS, CVE-2024-38366 is a remote code execution (RCE) flaw that would enable an attacker to execute arbitrary code on the trunk server.
A change committed to the trunk source code implementing MX record validation to registered emails, utilizing a third-party ruby gem package rfc-822, which unfortunately has a number of vulnerable validation methods.
As a result, EVA explained an attacker could exploit any of these validation methods to execute commands on the trunk server.
Although the report noted there is no ‘direct’ evidence of any of these bugs being actively exploited in the wild, it reminded readers “evidence of absence is not absence of evidence”, listing a number of mitigation steps organizations can follow to ensure their apps are not compromised.
Developers who have released applications for Apple devices should keep their podfile.lock file synchronized with all CocoaPods developers, ensuring that if a harmful update is committed, developers will not automatically update to it.
Developers using a pod developed internally and only hosted in CocoaPods for mass distribution should perform CRC validation against the one downloaded from the CocoaPods trunk server to guarantee it is the same as the one developed internally.
Finally, EVA recommends caution of very widely used dependencies as they could be the first targets the attackers try to exploit to achieve maximum yield with their attack.
