by Howard Solomon

Thousands of abandoned PyPI projects could be hijacked: Report

News
04 Sep 20246 mins

Software supply chain attacks could increase by using this newly discovered tactic, say JFrog researchers

Hooded spy in underground hideout trying to steal valuable data by targeting governmental websites with weak security. Espionage specialist doing cyber attacks to gain access to sensitive info
Credit: DC Studio / Shutterstock

A vulnerability in abandoned Python open source repository projects could allow over 20,000 packages of code to be hijacked to spread malware in supply chain attacks.

The warning for developers to be careful using the Python Package Index comes from researchers at JFrog, who discovered a vulnerability in PyPI’s ability to allow contributors to remove and then re-register a package under a different name.

“Unfortunately,” JFrog said in a report released Wednesday, “once a popular project is deleted, attackers can easily hijack the same package name and subsequently infect any user that tries to update that package to the latest version or re-installs it from scratch, which is popular in CI/CD [continuous integration/continuous deployment] machines that run a static pipeline.”

Threat actors have already discovered and are exploiting the hole, said report authors Andrey Polkovnychenko and Brian Moussalli.

On March 30, the new owner of the abandoned ‘pingdomv3’ package released a seemingly benign update, followed on April 12 by another update that included malware. PyPI was notified and the package deleted.

“This attack can be used to hijack 22K existing [abandoned] packages and subsequently lead to tens of thousands of malicious package downloads,” they added in the report.

To blunt that possibility JFrog created a PyPI account called ‘security holding,’ where the most downloaded abandoned packages were transferred. The original folders’ contents were replaced with empty packages.

What’s the risk

What’s the risk? On average, 309 packages are removed from PyPI each month, says the report.

There are lots of reasons a developer may want to delete a project – they’re tired of maintaining it, the package has been re-written by the same developer, or the same functionality has been added to an application’s official libraries or built-in APIs.

Regardless, deleting the package doesn’t kill its name in PyPI. Instead, it becomes immediately available for registration by anyone else. That person could then re-write the package to include malware, hoping to sucker a developer into downloading it, and including it in a legitimate application that would be distributed to unwitting organizations. If so, the threat actor could have a backdoor into the organization.

Because the tactic allows the revival of what a developer hopes is a dead project, JFrog developers call the tactic a Revival Hijack.

Powerful weapon

It’s an “extremely powerful” weapon for attackers, the report said, since it doesn’t require the threat actor to give a similar name to a stolen package, a technique called typo-squatting.

PyPI does have a safeguard, the report noted: A dialog box that warns the original developers about the potential consequences of deleting a project, including making the project name openly available. The developer then has to check off seven boxes showing they understand all the consequences before the project can be deleted.

Another protection is PyPI’s ability to distinguish between the author’s name in the package metadata and the actual user who published the package. This measure helps prevent unauthorized users from falsely assuming the identity of legitimate authors, said the report.

However, in a test when JFrog researchers created, deleted, and then substituted a phony package from a different account, PyPI listed it as a new version of the old package, even though it contained different code.

Researchers from a number of cybersecurity companies have also discovered vulnerabilities in open source code repositories like PyPI, NPM, NuGet and GitHub. Typosquatting public and private packages is one of the major problems. For example, in 2022 Aqua Security described a timing attack that could detect private packages in NPM, allowing a threat actor to then steal the package’s name.

Last year, Sonatype said the number of malicious packages it detected in open source platforms tripled compared to 2022.

In a report released at the beginning of the year, Reversing Labs said that there had been a more than 1,300% increase in threats circulating via open-source package repositories between 2020 and 2023. That included a 400% increase in threats found on the PyPI platform in 2023 alone, the report said. ReversingLabs discovered more than 7,000 instances of malicious PyPI packages in the first nine months of 2023, the vast majority of which were classified as ‘infostealers’.

The worry for CISOs is that their applications can become unwitting carriers of infection. A survey by Checkmarx released in June said 56% of respondents said their applications contain open source software.

In response to emailed questions, Shachar Menashe, JFrog’s senior director of security research, said the company isn’t sure Revival Hijack is a problem in other open source package repositories. But, he added, JFrog knows for certain it isn’t in NPM because that platform doesn’t allow re-registering abandoned packages due to this exact security risk.

“PyPI can follow in NPM’s steps,” he wrote, “and disallow re-registering an abandoned package (or only allow the original maintainer to re-register after deletion). This is an active point of discussion in the Python community on whether this should be implemented.

“The problem is that while this is being discussed, attackers can already use this method to gain code execution on many PyPI users as we’ve demonstrated.”

Advice for CISOs, app leaders

Infosec leaders should warn their staff that a new version of a package can potentially include malicious code, he said, even if the last version of the package was completely fine. Upgrading is dangerous, even on a previously-trusted package, he added.

Before deciding to upgrade a package, scan or inspect the latest version of that package to make sure it is safe, he urged. In addition, JFrog recommends upgrading to a new package version only after that version has existed publicly for at least 14 days, since after that time interval, package hijack attempts have usually been discovered

Exit mobile version