Critical security flaws left millions of Apple devices at the mercy of hackers – and no one noticed for almost a decade

Virtually every Apple device in the world has been exposed to a series of critical security flaws via the CocoaPods dependency manager, according to new research.

CocoaPods is a popular open-source dependency manager for Swift and Objective-C that Apple developers use to manage external libraries. It has used about 100,000 libraries in over three million mobile apps.

EVA Information Security has revealed that it has discovered several vulnerabilities in the CocoaPods service that could allow an attacker to take ownership of thousands of unregistered containers and execute arbitrary code on the service’s main server.

According to the investigation, the vulnerabilities appeared in 2014 and were not patched until October 2023, lying dormant for nine years, waiting to be exploited.

The first of these vulnerabilities appeared in 2014 after a migration to a new trunk server left thousands of orphaned packages. This means that their original owner is unknown, although many of them are still used in other libraries.

This meant that attackers could leverage the public API to take over resources without any verification, while almost 2,000 resources were still unclaimed by their owners and waiting to be taken over by attackers.

The EVA team warns that these containers could be injected with malicious code and used in supply chain attacks that could potentially compromise millions of iOS and macOS devices worldwide.

This defect, CVE-2024-38368marked with CVSS 9.3, also allowed attackers to remove all owners from any container, making them susceptible to takeover by malicious actors.

The second vulnerability flagged by EVA, CVE-2024-38367, is a session hijacking vulnerability that exploits a flaw in the CocoaPods authentication process. It allows attackers to manipulate the authentication process, leading to complete takeover of the CocoaPods master account.

EVA’s investigation found that CocoaPods authenticates new devices via email, requiring the user to merely confirm their email address by clicking a link. However, the report warns that this functionality can be easily compromised.

“We found that the server will accept a fake XFH header and use it explicitly to construct a URL that is sent to the client to verify the session,” EVA researchers said.

EVA noted that with a few extra steps, attackers could turn this into a no-click account takeover attack. Attackers can rely on the fact that most email servers have automated phishing detection tools that scan for potentially dangerous links.

However, when scanning the fake CocoaPods verification link, these tools inadvertently send the attacker a session token that can be used to verify the session and take control of the account and its packages.

Critical Flaw Could Have Spelled Disaster for Apple Devices

Changes to the CocoaPods source code to create a new email verification workflow also created a new attack path, opening the door to the third and most serious vulnerability, EVA said.

Rated 10 on CVSS, CVE-2024-38366 is a remote code execution (RCE) vulnerability that allows an attacker to execute arbitrary code on the trunk server.

The change made to the source code implements MX record validation for registered email addresses using an external Ruby Gem package (rfc-822), which unfortunately contains a number of vulnerable validation methods.

As a result, as EVA explained, an attacker can use any of these validation methods to execute commands on the trunk server.

While the report notes that there is no “direct” evidence that any of these bugs are being actively exploited in the wild, it reminds readers that “evidence of absence does not mean absence of evidence,” listing a number of mitigation steps organizations can take to ensure their applications are not compromised.

Developers who have released apps for Apple devices should ensure that the podfile.lock file is synced with all CocoaPods development files. This way, if a malicious update is released, developers will not automatically update to it.

Developers using a module developed internally and hosted on CocoaPods solely for mass distribution purposes should perform CRC validation against the module downloaded from the CocoaPods server to ensure it is the same as the internally developed module.

Finally, EVA recommends caution with commonly used dependencies as they may become the first targets that attackers will try to exploit to achieve maximum profits.