A remote code execution (RCE) vulnerability in the central CocoaPods server could have potentially impacted up to three million mobile apps that relied on the open source package manager.
Swiftly patched once detected, the serious security flaw had lurked unnoticed since 2015.
Breaching the CocoaPods server would have exposed the keys for the CocoaPods specifications repo and “allowed an attacker to poison any package download”, according to a blog post by security researcher Max Justicz.
CocoaPods, which is built using the Ruby programming language, is used by Swift and Objective-C Cocoa projects and has more than 82,000 libraries.
Supply chain threat
CocoaPods maintainer Orta Therox likened the potential impact of the flaw to that caused by XcodeGhost, a counterfeit version of macOS development environment Xcode that in 2015 compromised a number of apps popular in China.
However, Therox cautioned against exaggerating the downstream threat.
“It’s definitely feasible that over time a poisoned set of specs would affect all apps, but the timescale to do that would be pretty long and it would very likely have been spotted because we use a public git repo to store all of the data which the apps download from,” he told The Daily Swig.
“We don’t host the dependencies code nor the definitions in the place where the exploit occurred.”
He added: “In our case, a poisoned dependency would show as a change in the user’s project which would be pretty easy to inspect and report.”
In his own blog post dissecting the vulnerability, Therox said no evidence of abuse had surfaced – but that “doesn’t mean it hasn’t happened. Six years is a long time.”
‘Why hack just Signal?’
Justicz was probing the iOS source code for encrypted messaging service Signal when he noticed something that could have far-reaching implications: Podfile, which lists Signal’s CocoaPods dependencies.
“Why hack just Signal if we can find a bug that affects every app using CocoaPods?” said the researcher.
Vulnerable validation
Justicz noted that “when you upload a package spec to CocoaPods, it tries to make sure you didn’t accidentally link to a private repository.”
This was done with a server-side validation that, explained Therox, used “the git CLI on trunk using git ls-remote to replicate the same check as a user’s git would, but ls-remote has a parameter –upload-pack which can be used to execute a new shell,” he continued.
“This meant an attacker could create a specially crafted podspec via source, which would trigger the –upload-pack param and execute an arbitrary command on trunk.”
This “gave a possible attacker the ability to read the environment variables, which could be used to write to the CocoaPods/Specs repo and read the trunk database.”
A malicious actor could then potentially obtain session keys that “act like unique passwords to accounts” and which “are used to connect authenticated users to pods”.
Timeline and mitigations
Courtesy of a “great technical write-up”, said Therox, the bug was patched on 19 April, around 10 hours after it was reported and within an hour of Therox starting work on a fix – “which is really cool for a completely volunteer-driven project!” Justicz told The Daily Swig.
Therox said all session keys are being wiped and that “the issue has been patched server-side and does not affect your CocoaPods installation.
“We don’t think the CocoaPods Specs repo has been tampered with,” he added, but tools have been created to validate commits.
Pod authors can verify whether their Pods have had an unexpected release here.
Therox also recommends that they “log in again to [the] trunk again to deploy any new Podspecs”. Automated deployments, he added, “will break, and you will need to pod trunk register again and replace your COCOAPODS_TRUNK_TOKEN”.
Further recommendations
Justicz also recommends that developers “consider vendoring dependencies and reviewing their updates carefully”.
Authors of dependency managers, meanwhile, should ideally treat package contents and version control software as “toxic waste” – or at least use a sandbox like gVisor, which Justicz “couldn’t escape” when, last year, he “found an RCE bug in proxy.golang.org which was shelling out to some vulnerable version control software”.
Source: https://portswigger.net/daily-swig/cocoapods-rce-exploit-exposed-keys-to-repo-used-by-three-million-mobile-apps
