CocoaPods, an open-source dependency manager used in over three million applications coded in Swift and Objective-C, left thousands of packages exposed and ready for takeover for nearly a decade - thereby creating opportunities for supply chain attacks on iOS and macOS apps, according to security researchers.
Israeli firm EVA Information Security announced its discovery in a Monday blog post.
That migration saw authorship of all Pods reset, and authors asked to reclaim their work.
And at the time of writing 1,870 Pods remained unclaimed by their owners, leaving them orphaned - and accessible.
The problem earned that rating because all orphaned Pods were affiliated with a default email address, and a public API for claiming unclaimed Pods was available until late 2023 - with no need to provide any verification of ownership.
To claim a Pod, all an attacker needed to do was transmit a particular CURL request, and voila - they would have free rein to modify a Pod and insert malicious code.
EVA's researchers wrote that they haven't seen evidence of this mess having been exploited.
The fact we're even aware of this fustercluck is a bit serendipitous, too: The researchers discovered them when performing a red team exercise for a client, not through intentional examination of CocoaPods.
If the EVA team could find them, someone else could have, too.
A second vulnerability - CVE-2024-38366, CVSS 10.0 - allows for remote code execution on the Trunk server thanks to mail exchange verification using a vulnerable RFC822 Ruby package.
By exploiting the fact the aforementioned package executes host commands against a provided email address without proper validation, a trailing bash command can be injected in order to dump session tokens, poison client traffic or even trigger a server shutdown.
Third, there's a vulnerability in the Trunk server's own source code - CVE-2024-38367, CVSS 8.2 - that has an interesting exploitation chain relying on standard functionality of email scanning software to steal session validation tokens without the need for user interaction.
CocoaPods authenticates new devices using an email sent to users who request a session, the researchers noted - but authentication doesn't rely on anything but a client verifying their email address by clicking a link.
Clicking the link generated by the spoofed XFH header transmits a session token right to the spoofer.
Here's where the zero-click comes in: Because email scanning services check links to compare them to known phishing templates, the researchers observed that automated tools end up following the link and transmitting the session token on a targeted user's behalf.
As noted above, the CocoaPods team has patched the issues - and appeared to do so months ago - though specifics weren't widely known until EVA published its research today.
CocoaPods maintainers contacted by The Register didn't respond to questions before publication.
As a supply chain attack, this CocoaPods vulnerability could have found itself in the illustrious company of such damaging exploits as Log4Shell, the recent Polyfill debacle, SolarWinds and others.
The researchers recommend everyone using CocoaPods review their dependencies for orphaned Pods, perform checksum validations on all code downloaded from the CocoaPods Trunk server, review all third-party code, update their CocoaPods installations and generally be more attentive to open source software supply chain risks.
With an estimated 97 percent of all commercial codebases believed to be utilizing open source components, that advice applies to pretty much everyone - CocoaPods user or not.
This Cyber News was published on packetstormsecurity.com. Publication date: Tue, 02 Jul 2024 15:13:05 +0000