Saturday, October 19, 2024

PyPI Vulnerability Exposes Thousands of Packages to Compromise Risks

Thousands of applications that utilize open source software packages from the Python Package Index (PyPI) may be at risk of hijacking and subversion by malicious actors, potentially leading to significant supply chain attacks that could impact a larger number of downstream organizations and users.

This warning comes from threat researchers at jFrog, who discovered that the pingdomv3 package – part of the widely used Pingdom API for website monitoring, owned by SolarWinds – was targeted using a new technique termed “Revival Hijacking.” This technique was identified while the team was monitoring the open source ecosystem and is akin to typosquatting, where attackers exploit common misspellings to register harmful domains.

In the case of the pingdomV3 package, an undisclosed threat actor exploited a PyPI feature that allows the name of a deleted package to become immediately available for reuse. Essentially, this allows the package to be “revived” and hijacked for malicious purposes.

Brian Moussali, the malware research team leader at jFrog, emphasized the dangers of the Revival Hijack technique for three primary reasons. First, it does not rely on users making mistakes when installing malicious packages, unlike typosquatting. Second, the practice of regularly updating packages is prevalent among developers, who often perceive it as low-risk, even though this isn’t always accurate. Third, many CI/CD systems are configured to automatically install package updates.

Moussali stated, “Revival Hijack is not merely a theoretical threat – our research team has already observed it being exploited in real-world situations. By exploiting a vulnerability in how removed packages are dealt with, attackers can take over existing packages and integrate them into target systems without altering the user’s workflow.” He urged users to remain vigilant, noting that the attack surface for PyPI is continually expanding, and proactive measures are essential to protect both individuals and the broader PyPI community.

Moussali and colleague Andrey Polkovnichenko estimated that approximately 120,000 removed PyPI packages could potentially be hijacked. Excluding those with fewer than 100,000 downloads, newer packages, or those that are obviously unsafe still results in a significant figure exceeding 22,000. With an average of 309 PyPI packages being removed each month, there is a constant influx of potential new targets for attackers exploiting the Revival Hijack technique.

What Happened to pingdomV3?
In the case of pingdomV3, the original owner had last updated the package in April 2020 and did not provide any further updates until March 27, 2024, when they advised users to avoid the package due to its abandonment. After the package was removed on March 30, a user registered the name almost immediately, publishing a new version and claiming it was a redevelopment, misleadingly linking to a non-existent GitHub repository. On April 12, jFrog’s automated scanners flagged suspicious activity when the new package owner introduced a Base64-obfuscated payload, prompting further investigation. The package was ultimately removed by PyPI on April 12, and its name has since been prohibited from use.

The payload appeared to be a Python trojan designed to check if it was running in a Jenkins CI environment, where it would perform an HTTP GET request to an attacker’s URL. The jFrog team could not ascertain further details about the payload, suggesting the attacker may have aimed to delay their attack or limit it to specific IP ranges. Regardless, the malicious intent was ultimately thwarted.

In an effort to combat the potential risk, Moussali and Polkovnichenko took action by hijacking some of the most downloaded abandoned packages and replacing them with empty, benign versions labeled as 0.0.0.1 to avoid unintentional installs through automated updates. After a few days, they found that their empty packages had been downloaded over 200,000 times. While it is unclear how many of these had been successfully exploited by a malicious actor, Moussali stated it is “very safe to say” that the majority would have been.

PyPI’s Response
According to jFrog, PyPI has considered implementing a policy change regarding deleted packages that would eliminate this vulnerability, but no decision has been made after two years of discussions. While PyPI does inform users that deleted package names will be released for new registrations and prevents the deletion of specific package versions, experts like Moussali argue that the potential impact of the Revival Hijack technique necessitates more decisive action.

He advocated for PyPI to enforce a stricter policy that fully prohibits the reuse of package names and urged users to approach upgrades to new versions carefully.

Henrik Plate, a security researcher at Endor Labs, also highlighted that the risk associated with this issue is real and correlates with the popularity of the package. The risk is likely lower for packages that have been deleted for an extended period, as developers would have had time to adjust their dependencies. He noted that the swift revival of the pingdomV3 package may indicate that attackers were monitoring package deletions on PyPI.

Reviving deleted packages is an acknowledged concern. The taxonomy of supply chain attack vectors underlined by Endor Labs includes this as a known risk, emphasizing the need for stricter security measures for package repositories, in line with recommendations from OpenSSF. For defenses, he suggested that using internal package registries can help shield developers by maintaining a mirror of open source packages even if they are deleted. However, internal registries must be configured to rigorously vet new package versions for potential malicious content.