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

The researcher contacted BleepingComputer stating that by hijacking these packages he hopes to get a job. And, he seems pretty confident that it would work.

At least 14 hacked Packagist packages

Yesterday, a researcher with the pseudonym “neskafe3v1” contacted BleepingComputer saying he had taken over fourteen Packagist packages, one of which had over 500 million installs.

Packagist is the main registry for PHP packages that can be installed through Composer, a dependency management tool. Rather than hosting these packages, Packagist serves more as a metadata repository that aggregates open source packages published on GitHub. These packages can then be installed by developers on their machines by running the composer installation order.

Names of hacked packages include:

The researcher provided evidence to BleepingComputer demonstrating that on Monday, May 1, the Packagist pages for these packages were changed to point to the researcher’s (fake) repository, as opposed to the legitimate GitHub repository for each package.

As an example, here’s how the Packagist page for acmephp The package appeared on Monday, with its GitHub link replaced with the researcher’s repository instead of the genuine one. github.com/acmephp/acmephp.

These changes have now been reverted by the Packagist team, as verified by BleepingComputer.

The publishing process on Packagist is a bit different than open source repositories like npm or PyPI. A developer, instead of uploading binaries or software releases directly to Packagist.org, simply creates a Packagist.org account and “submits” a link to their GitHub repository for a particular package. The Packagist crawler then visits the provided repository and aggregates all the data to display on the Packagist page for that package.

When a developer runs Composer with ‘install’ or ‘update’ commands, his Composer instance can first check for the presence of the packages locally, otherwise it is default search on Packagist for this package and retrieve the GitHub URL listed for this package. The package contents are then downloaded from this GitHub repository listed on the package’s Packagist page.

This is in stark contrast to how npm or PyPI work, i.e. these registries host and distribute software releases directly from their servers.

By modifying 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 neskafe3v1‘s GitHub repository, rather than the project’s repository.

To keep the demonstration to a minimum, the researcher simply modified the composer.json file, something akin to an application manifest, in these packages to read:

“Pwned by neskafe3v1…. Ищу работу на позиции Application Security, Penetration Tester, Cyber ​​​​Security Specialist.”

He did this by forking the original project repository, modifying the “description” field in composer.json, and committing the change to his forked repository. At no time did it merge the changes into the original repository (that would have required additional access and possibly invited scrutiny from maintainers).

Instead, the researcher apparently gained access to the maintainers’ Packagist accounts and replaced the GitHub URLs of the listed packages with those of his forked repositories. But, he did not reveal the exact method used to hijack to BleepingComputer.

When BleepingComputer was pressed to reveal the exact technique the researcher used to hijack these packages, we were told it was not zero day but a known technique. But we weren’t told whether the hijacking was achieved by, for example, compromising credentials, taking control of manager email address due to expired domainor another technique:

“As you can see, I am looking for a job (this message ‘Ищу работу на позиции…’ means ‘I am looking for a job…’), so I will disclose a report after I am hired by a company”, the researcher told BleepingComputer, likening the entire hacking campaign to “an advertisement of myself as an employee.”

“As long as there is no success, there is nothing to say.”

Hacked via Credential Compromise

In a statement to BleepingComputer, the Packagist team said that no malicious impact has been observed so far on the platform as a result of this action while confirming that the takeover was indeed the result of a compromise of the manager’s account credentials.

“To our knowledge, this was not used for malicious purposes and was limited to a few old accounts with insecure passwords and missing 2-factor authentication,” said Nils Aderman of Packagist.org, who is also one of the original Composer developers, at BleepingComputer. .

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

“On May 2, at 7:21 UTC, we were informed by Juha Suni of the URL change to several Doctrine packages,” the administrators further explain in a blog post published today.

Working alongside Marco Pivetta aka Ocramius, Packagist admins quickly identified all accessed accounts, disabled their access, and restored GitHub URLs to their old values. The restoration effort was completed Tuesday morning.

The researcher also told BleepingComputer that he did not abuse the technique to distribute malware, but at the same time said he had not informed either Packagist or package owners of the little experiment, which raises eyebrows about the “ethical” nature of this research.

“The only thing I did – I changed the ‘description’ field in composer.json files,” the researcher said pointing 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 tell the original files from mine. I did not inform anyone about the attack, neither the Packagist administrators nor the package owners.”

In their blog post, the admins of Packagist ask researchers to report bugs and vulnerabilities responsibly.

“If you are a security researcher and know of a Packagist.org vulnerability or would like to research Packagist.org, we ask that you please coordinate testing with us to avoid negative user impact. and to disclose these vulnerabilities. responsibly.”

“You can reach us at security@packagist.org and we respond quickly to any inquiries or reports. We of course provide credits and publish details of reported vulnerabilities…”