Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Peter <confused@nospam.net>
Newsgroups: misc.phone.mobile.iphone,comp.sys.mac.system,uk.telecom.mobile,comp.mobile.ipad
Subject: Almost every iOS & macOS app has had huge vulnerabilities for over a decade
Date: Wed, 3 Jul 2024 06:38:38 +0100
Organization: -
Lines: 111
Message-ID: <v62o4t$22b9c$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Injection-Date: Wed, 03 Jul 2024 07:38:38 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="8bee8f85c8102c44ba79eb2024792999";
	logging-data="2174252"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19EcLS6adfGzdCucdUcSMrJ"
Cancel-Lock: sha1:C5yUjERvT2l5ex2yXnGQB0APG/0=
X-Newsreader: Forte Agent 3.3/32.846
X-No-Archive: yes
Bytes: 7177

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/