Summary: A popular dependency manager for Apple apps, CocoaPods, has been found to have serious vulnerabilities, making it a prime target for hackers.
Threat Actor: Hackers targeting the CocoaPods platform.
Victim: Apple app developers using the CocoaPods platform.
Key Point:
- CocoaPods is a widely used platform by Apple app developers to add and manage external libraries.
- The platform contains over 100,000 libraries used by millions of apps, making it an attractive target for hackers.
- Recent reports have revealed serious vulnerabilities in CocoaPods, including a critical remote code execution (RCE) opportunity.
- These vulnerabilities pose a significant threat to the security of Apple apps and their users.
A near inconceivable number of Apple apps have been exposed to critical vulnerabilities in a popular dependency manager for years now.
CocoaPods is a platform that developers in Apple’s ecosystem use to add and manage external libraries (called “pods”). It sports 100,000+ libraries used by more than three million apps, including the most popular ones in the world. A quick search on its website reveals packages relating to Instagram, X, Slack, AirBnB, Tinder, and Uber, to name just a few. This makes the pods prime targets for hackers, and the CocoaPods platform — should it contain some underlying, platform-wide vulnerability — a bona fide money pit.
Indeed, as revealed by E.V.A Information Security in a report on Monday, it turns out that the CocoaPods platform did contain a trio of serious vulnerabilities. The most severe of them — CVE-2024-38366, a remote code execution (RCE) opportunity — was assigned a critical 10 out of 10 CVSS rating. Another remarkable bug caused by pods without owners, CVE-2024-38368, earned a critical 9.3, and an 8.2 was given to the session verification-hijacking issue CVE-2024-38367.
“The impact of this is enormous,” says E.V.A CEO and co-founder Alon Boxiner. “You can’t describe it in words. We don’t even know how to accumulate the numbers [of affected apps] because of CocoaPods’ vast usage.”
CocoaPods Mishandled APIs for a Decade
CocoaPods was first developed and released in 2011. Its current woes can be traced to 2014, when it replaced a GitHub-based authentication system with a new “Trunk” server, which thereafter doubled as the platform’s centralized repository and distribution platform.
Though Trunk promised benefits to security, scalability, and developer quality of life, the migration process was awkward. For example, shockingly, ownership over all pods was reset.
“As part of the integration, some API’s were exposed — including a front-end Web page — to let business owners that were authenticated via their GitHub account claim their own pods,” recalls Reef Spektor, E.V.A vice president of research. In other words, users reclaimed their pods by simply calling dibs.
Many authors didn’t reclaim their pods at all. Thousands of dependencies were left “orphaned.” Over time still more were abandoned, as authors reneged on their ownership. Thousands of pods remain ownerless today.
The rub? The public API endpoint for claiming pods was still available nine years later.
Anyone in possession of this knowledge could have, at any point from 2014 to 2023, claimed anyone else’s pod for themselves, modified it however they wished, and pushed that modification to any Apple apps that use it.
What reasonable app would rely on an abandoned pod? It turns out: many, sometimes without noticing simply because it’s a dependency of yet another pod. E.V.A found evidence of orphaned pods in documentation for apps like Facebook, Safari, Microsoft Teams, TikTok, Snapchat, and many more.
Remarkably, this wasn’t even the most severe bug they found.
Max-Severity RCE Bug Tied to RubyGem
Ironically, CocoaPods’ worst vulnerability lay with an open source component it incorporated back in 2014 for validating user email addresses.
Thanks to some vulnerable methods in the RubyGem package rfc-22, an attacker could have injected arbitrary malicious code into the address field during Trunk’s account validation process. The server would unknowingly run their arbitrary code, granting them carte blanche.
At this stage, Spektor explains, “I have complete access to the Trunk service — every owner, every pod, unclaimed, claimed, it doesn’t really matter. I can take full ownership over them if I want to, I can edit them at runtime. So, for example, someone publishes a pod, and in the server I can hook to the pod specification and alter it to add malicious code. And that wouldn’t really be visible externally.”
The type of malicious code such an attacker could silently add to a pod would be limitless, and this is just one way they could take advantage of such access. They could use such access to shut down Trunk entirely, or steal session tokens from pod owners or CocoaPods itself.
Needle in a Haystack
There’s no clear evidence that attackers have exploited any of the issues uncovered by the researchers and patched by CocoaPods in October.
It’s worth noting, however, that the easily concealable nature of software supply chain bugs, combined with the sheer number of pods at risk for so long, would provide ample cover to anyone who has done so.
Finding a CocoaPods exploit over the past decade would make finding a needle in a haystack seem easy, but that hasn’t happened. So instead, E.V.A recommends that any developers of apps that have relied on pods prior to last October (read: almost all Apple apps) should pursue six steps for remediation such as checking for orphaned pods and thoroughly reviewing all third-party code dependencies.
Dark Reading has also reached out to Apple for comment.
“CocoaPods is a perfect example of why we should take care of supply chain risk,” Boxiner says. “It’s not only about how you develop what you develop, but you also have dependencies [which can be] blind spots.”
Source: https://www.darkreading.com/cloud-security/apple-cocoapods-bugs-expose-apps-code-injection
“An interesting youtube video that may be related to the article above”