XPost: misc.phone.mobile.iphone, comp.sys.mac.system, uk.telecom.mobile

A near inconceivable number of Apple iPhone & macOS apps have been exposed
to critical vulnerabilities in a popular dependency manager for over 10
Years such that over three million CocoaPods-built iOS and macOS apps have
been vulnerable for over a decade, unbeknownst to Apple & its test teams.
The CocoaPods platform contained a trio of serious exploited iOS and macOS 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, CVE-2024-38368, earned a critical 9.3, and
an 8.2 was given to the session verification-hijacking issue CVE-2024-38367
- just to name a few of the vulnerabilites that slipped right by Apple
testing for more than a decade as if Apple testers are as blind as a bat.

"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."

The CocoaPods dependency manager is found in over a hundred thousand
libraries used in more than three million mobile apps on iOS & macOS.

CocoaPods facilitates the integration of third-party code into programs by providing open-source libraries. When a library is updated, apps that use
it automatically receive the most recent updates.

CocoaPods is a platform that developers in Apple's ecosystem use to add and manage external libraries (called "pods"). It sports over a hundred
thousand libraries used by more than three million apps, including the most popular ones in the world such as 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 a bona fide money pit given Apple never thought to test for this vulnerability in more than a decade.

The exploit gives hackers instant access to private content, credit card numbers, medical records, and other sensitive app data. The information is
then exploited for ransomware, fraud, blackmail, corporate espionage, and
other nefarious activities.

The weaknesses are associated with an unreliable email verification system
that verifies the identity of developers for specific pods or libraries.

The vulnerabilities allowed any malicious actor to insert malicious code
into many of the most popular iOS and MacOS applications.

An attacker using the vulnerabilities could easily have infected almost
every Apple device, leaving tens of thousands of organizations vulnerable
to catastrophic financial and reputational damage. One vulnerability
detailed by E.V.A's researchers could enabled zero-day attacks against supposedly secure macOS infrastructure (which was insecure 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, which proved
many times over how poorly Apple handles the testing of their own products.

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.

https://www.techtimes.com/articles/306292/20240703/iphone-mac-applications-exposed-cyberattacks-10-years-report-claims.htm
https://siliconangle.com/2024/07/02/decade-long-cocoapods-vulnerabilities-exposed-apple-users-potential-security-risks/
https://www.darkreading.com/cloud-security/apple-cocoapods-bugs-expose-apps-code-injection
https://www.theregister.com/2024/07/02/cocoapods_vulns_supply_chain_potential/

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)