A remote code execution vulnerability identified on the central CocoaPods server could have allowed an attacker to poison any package download, security researcher Max Justicz reveals.
A dependency manager for Swift and Objective-C Cocoa projects, CocoaPods has more than 82,000 libraries and is being used in over 3 million applications. The tool is built using Ruby and can be used with the default Ruby on macOS.
The identified vulnerability, Justicz explains, resides in a function designed to check that, when a package spec was uploaded to CocoaPods, it was not linking to a private repository.
In short: the manner in which the function checked the contents of a flag could have allowed an attacker to serve tailored content and abuse it to run commands.
The vulnerability was disclosed to CocoaPods on Monday, and a patch was deployed server-side on the same day.
“The exploit is a combination of un-sanitized user input getting through to a git call param which can be used to send remote payloads,” CocoaPods developer Orta Therox explains.
Successful exploitation of the flaw, he notes, could lead to the execution of arbitrary shell commands on the server, thus allowing an attacker to read environment variables and write to the CocoaPods/Specs repo or even read the trunk database.
While the patch was deployed server-side and CocoaPods installations were not affected, developers would still need to log in to the central repository of Podspecs (trunk) again and deploy any new Podspecs.
The change also breaks automated deployments to CocoaPods and requires developers to replace their COCOAPODS_TRUNK_TOKEN. This, however, ensures that no one else has access to one’s pods.
The vulnerability was introduced in 2015 but, despite the long time during which the flaw resided on the server, the CocoaPods team doesn’t believe that the CocoaPods Specs repo has been tampered with. Furthermore, they say, there’s no proof that anyone has exploited the issue in the manner described by Justicz.
“However, just because it hasn’t been proved, doesn’t mean it hasn’t happened. 6 years is a long time. The worst case scenario is that an attacker could have used this technique to get access to our trunk database,” Therox notes.
While the trunk database contains email addresses that are already public, it also contains session keys, which could be used to allow unauthenticated users to connect to pods. Thus, CocoaPods is deleting all session keys, to prevent pod compromise.
“From the side of our investigation, we cannot automatically detect if someone has deployed a poisoned copy of a Pod,” Therox notes.
Related: Library Dependencies and the Open Source Supply Chain Nightmare
Related: Software Dependencies Exposed Microsoft, Apple to High-Impact Attacks
Related: GitHub Helps Developers Keep Dependencies Secure via Dependabot
More from Ionut Arghire
- Former Ubiquiti Employee Who Posed as Hacker Pleads Guilty
- Atlassian Warns of Critical Jira Service Management Vulnerability
- Exploitation of Oracle E-Business Suite Vulnerability Starts After PoC Publication
- Google Shells Out $600,000 for OSS-Fuzz Project Integrations
- F5 BIG-IP Vulnerability Can Lead to DoS, Code Execution
- Flaw in Cisco Industrial Appliances Allows Malicious Code to Persist Across Reboots
- HeadCrab Botnet Ensnares 1,200 Redis Servers for Cryptomining
- Malicious NPM, PyPI Packages Stealing User Information
Latest News
- US Downs Chinese Balloon Off Carolina Coast
- Microsoft: Iran Unit Behind Charlie Hebdo Hack-and-Leak Op
- Feds Say Cyberattack Caused Suicide Helpline’s Outage
- Big China Spy Balloon Moving East Over US, Pentagon Says
- Former Ubiquiti Employee Who Posed as Hacker Pleads Guilty
- Cyber Insights 2023: Venture Capital
- Atlassian Warns of Critical Jira Service Management Vulnerability
- High-Severity Privilege Escalation Vulnerability Patched in VMware Workstation
