Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Peter 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: 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/