3 million iOS and macOS apps were exposed to potent supply-chain attacks

reader comments

22

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 “pods”—CocoaPods lingo for individual code packages—dependent apps typically incorporate them automatically through app updates, typically with no interaction required by end users.

Code injection vulnerabilities

“Many applications can access a user’s 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 imaginable—ransomware, 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 attacker’s 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:

The researchers could instead change the URL to lead to their own server:

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.