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/

Peter <confused@nospam.net> wrote:
> 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.

This is very concerning, however the bit you omitted is that these
vulnerabilities were patched late last year.

The most important thing people can do is keep their apps and iOS up to
date. And maybe reconsider using apps that haven't been updated since
October 2023.

It's also worth mentioning that this was a vulnerability explicitly
possible because of the open source model. Had CocoaPods not been available
on github it would have been possible to exploit as easily or at all.

On 2024-07-03, Chris <ithinkiam@gmail.com> wrote:
> Peter <confused@nospam.net> wrote:
>> 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.
>
> This is very concerning, however the bit you omitted is that these
> vulnerabilities were patched late last year.
>
> The most important thing people can do is keep their apps and iOS up
> to date. And maybe reconsider using apps that haven't been updated
> since October 2023.
>
> It's also worth mentioning that this was a vulnerability explicitly
> possible because of the open source model. Had CocoaPods not been
> available on github it would have been possible to exploit as easily
> or at all.

Such level-headed nuance is to be ignored, because: troll.

--
E-mail sent to this address may be devoured by my ravenous SPAM filter.
I often ignore posts from Google. Use a real news client instead.

JR

Using <news:lela2oF7jrrU1@mid.individual.net>, Jolly Roger wrote:

> Such level-headed nuance is to be ignored

Except that he was wrong and even if he had been correct for you to advise
vulnerabilities in open source code should be ignored is just plain stupid.

On 2024-07-03, david <this@is.invalid> wrote:
> Using <news:lela2oF7jrrU1@mid.individual.net>, Jolly Roger wrote:
>
>> Such level-headed nuance is to be ignored
>
> Except that he was wrong

Nothing he said is wrong, and the fact that you trimmed what he said
from your reply shows what a cowardly troll you are, little Arlen.

> and even if he had been correct

He is correct.

> for you to advise vulnerabilities in open source code should be
> ignored

Yet again, you lie - I never said that, which is a matter of record.

> is just plain stupid.

Projection from a stupid zealot.

--
E-mail sent to this address may be devoured by my ravenous SPAM filter.
I often ignore posts from Google. Use a real news client instead.

JR

david <this@is.invalid> wrote:
> Using <news:lela2oF7jrrU1@mid.individual.net>, Jolly Roger wrote:
>
>> Such level-headed nuance is to be ignored
>
> Except that he was wrong

Who was wrong?

> and even if he had been correct for you to advise
> vulnerabilities in open source code should be ignored is just plain stupid.

no-one has suggested that.