Researcher hijacks popular Packagist PHP packages to get a job

A researcher has hijacked over a dozen Packagist packages – some of which have been installed hundreds of millions of times in their lifetime.

The researcher contacted BleepingComputer and told him that he hoped to get a job by hijacking these packages. And he seems pretty confident that this would work.

Hijacked at least 14 Packagist packages

Yesterday, a researcher using the alias “neskafe3v1” contacted BleepingComputer and said he had taken fourteen Packagist packages, one of which had over 500 million installs.

Packagist is the primary registry of PHP packages that can be installed through Composer, a dependency management tool. Rather than hosting these packages, however, Packagist serves more as a metadata directory that aggregates open-source packages published on GitHub. These packages can then be installed on their computers by developers by running the following Install Composer Command.

The names of the hijacked packages include:

The researcher provided BleepingComputer with evidence showing that on Monday, May 1st, the packagist pages for these packages were modified to point to the researcher’s (fake) repo, rather than the legitimate GitHub repository for each package.

As an example, here is how the Packagist page for acmephp The package appeared on Monday – the GitHub link was changed to the researcher’s repo instead of the authentic one github.com/acmephp/acmephp.

These changes have now been rolled back by the Packagist team and reviewed by BleepingComputer.

The publishing process on Packagist is a bit different than on open source repos like npm or PyPI. Instead of uploading binaries or software versions directly to Packagist.org, a developer simply creates a Packagist.org account and “submits” a link to their GitHub repo for a specific package. Packagist’s crawler then visits the provided repo and aggregates all the data to display on the Packagist page for that package.

When a developer runs Composer using the install or update commands, their Composer instance may first check locally for the presence of the packages. Otherwise, by default, it looks for that package on Packagist and fetches the GitHub URL listed for that package. The contents of the package are then downloaded from this GitHub repo listed on the package’s Packagist page.

This is in stark contrast to how npm or PyPI works – that is, these registries host and distribute software releases directly from their servers.

By changing the Packagist page for each of these packages, the researcher effectively hijacked the installation workflow used in Composer environments. Developers would now get the contents of a package from neskafe3v1is the GitHub repo and not the project’s repository.

To keep the demonstration to a minimum, the researcher simply modified the composer.json file – something like an application manifest – in these packages as follows:

“Pwned by neskafe3v1…. I work on Application Security, Penetration Tester, Cyber ​​Security Specialist.”

To do this, he forked the original project repository, changed the Description field to composer.json, and committed the change to his forked repository. At no point did he re-introduce the changes to the original repository (this would have required additional access and possibly required maintainer review).

Instead, the researcher apparently gained access to the maintainers’ Packagist accounts and changed the GitHub URLs of the listed packages to those of his forked repos. However, he did not reveal the exact method of the kidnapping to BleepingComputer.

When pressed by BleepingComputer to reveal the exact technique the researcher used to hijack these packages, we were told that it was not a zero-day method, but a known technique. However, we were not told whether the hijack was achieved by, for example, compromising credentials, hijacking the maintainer’s email address due to an expired domain, or some other technique:

“As you can see, I’m looking for a job (the message ‘Ищу работу на позиции…’ means ‘I’m looking for a job…’), so I’ll post a report when I’m ready.” was hired by a company,” the researcher told BleepingComputer, likening the entire kidnapping campaign to “an advertisement for me as an employee.”

“Until success comes, there is nothing to talk about.”

Hijacked by credential compromise

In a statement to BleepingComputer, the Packagist team said that no malicious impact on the platform has been observed as a result of this action, while also confirming that the takeover was indeed due to the compromise of the maintainer accounts’ credentials.

“To our knowledge, this was not used for malicious purposes and was limited to some old accounts with weak passwords and missing two-factor authentication,” Packagist.org’s Nils Aderman, who is also one of the original Composer developers, told BleepingComputer .

“All four accounts appear to have used shared passwords that had been leaked in previous incidents on other platforms. Please do not reuse passwords,” warn Packagist administrators.

“On May 2nd at 7:21am UTC, we were notified by Juha Suni that the URL to several Doctrine packages had changed,” the administrators further explain in a blog post published today.

Working with Marco Pivetta aka Ocramius, Packagist admins promptly identified all accessed accounts, disabled access to them, and restored GitHub URLs to their previous values. The restoration work was completed on Tuesday morning.

The researcher also told BleepingComputer that he had not misused the technique to spread malware, but at the same time said he had not informs either Packagist or the package owners about the little experiment – causing quite a stir as to the “ethical” nature of this research.

“Only thing I did – I changed the Description field Composer.json Files,” the researcher said, directing us to evidence such as Git commits.

“I just changed the link from github.com/acmephp/core (original) to… my fork. There is no malware, you can compare the original files with mine. I have not informed anyone about the attack, neither packagist administrators nor package owners.”

In their blog post, Packagist admins urge researchers to responsibly report bugs and vulnerabilities.

“If you are a security researcher and you are aware of or want to research a Packagist.org vulnerability, we encourage you to coordinate testing with us to avoid negative user impact and to responsibly disclose these vulnerabilities.”

“You can reach us at security@packagist.org and we will promptly respond to any inquiries or reports. Of course we provide information and publish details on reported vulnerabilities…”