Packagist PHP repo supply chain attack: 3 key takeaways

A vulnerability that threatened the security of millions of websites using the PHP scripting language has been patched, according to a security researcher with SonarSource, a Swiss company that develops code quality and security software. Researcher Thomas Chauchefoin explained in a company blog post that the flaw allows an attacker to gain control of Packagist, which is used by the PHP manager named Composer to determine and download software dependencies included by developers in their projects.

Chauchefoin noted that virtually all organizations running PHP code use Composer, which serves two billion software packages every month. More than a hundred million of these requests could have been hijacked to distribute malicious dependencies and compromise millions of servers, he wrote.

By attacking the servers running Packagist, which associates the name of a package with its location, threat actors could force users to download back-doored software dependencies the next time they do a fresh install or an update of a Composer package based on data from 2021. Since Composer is the standard package manager for PHP, Chauchefoin explained, most open source and commercial PHP projects would have been impacted.

The vulnerability was fixed within hours by the maintainers of the affected service, he added, and it's believed it was never exploited in the wild.

Chauchefoin noted that users of the default, official Packagist instance, or Private Packagist, are safe because their public production instances have been patched. For organizations integrating Composer as a library and operating on untrusted repositories, he recommends upgrading to Composer 1.10.26, 2.2.12, or 2.3.5.

Here are key takeaways from the Packagist software supply chain attack.

Get a free SBOM and full supply chain risk analysis report

1. Software repositories: A jackpot for adversaries

Attacks on software repositories are particularly dangerous, observed Henrik Plate, a security researcher at Endor Labs, a dependency management company. "They can enable malware to not only infect single open source projects, but all projects that distribute binary artifacts through the repository," he said.

"Packagist.org, the package repository for PHP packages, hosts a total of 3.6 million binary artifacts for 353 thousand different open source packages," Chauchefoin wrote. "The vulnerability CVE-2022-24828, which has been discovered in the PHP package manager called Composer, could have resulted in remote code execution on packagist.org, with the possible compromise of numerous projects and artifacts hosted on that repository."

That would be a jackpot for adversaries of any kind, no matter if they intend to run highly targeted attacks against a single project or a huge campaign on the entire ecosystem.

Thomas Chauchefoin

The software industry’s dependency on open source and its pervasiveness make it a compelling target for supply chain attacks, he added. Attacking upstream open source projects also has the considerable advantage of spreading out to potentially many downstream consumers, he continued.

The combined attack surface of thousands of open source projects is much bigger than any given vendor’s development infrastructure. If an attacker gets lucky and is able to inject malware into a highly successful open source project, thousands of direct and indirect downstream users can be infected in a snap.

Thomas Chauchefoin

Ken Arora, a distinguished cybersecurity engineer and architect at F5, a multi-cloud application services and security company, said that in addition to infecting downstream targets, compromising repositories can be used to create a foothold for a variety of mischief.

This foothold can be used as a launching pad for lateral movement within the application’s infrastructure.

Ken Arora

Compromised components can also be used to access application protected data, such as database tables and S3 buckets; overriding critical security-relevant configuration files; or be a conduit to open connections to the external internet for data exfiltration, he added.

2. Software supply chain security: Complexity creates challenges

The Packagist vulnerability illustrates a growing problem with software supply chains: complexity, said Ed Moyle, systems and software security director at Drake Software, a tax and accounting solutions maker, and a member of the ISACA Emerging Trends Working Group.

We're already at the point that dependency management has to be automated in many cases to be viable, he said. Package managers and the like are used out of necessity, meaning, in order to ensure that the right modules and the right versions of those modules are where they need to be, automation is required, Moyle explained.

Because of the complexity in managing this, the package manager itself can be a very tempting target. Why? Because you can compromise multiple victims all at once, you can do it in a stealthy way that does not require actively attacking the downstream target, and you can do it in a way for which most organizations will be unprepared.

Ed Moyle

Daniel Kennedy, research director for information security and networking at 451 Research, which is part of S&P Global Market Intelligence, said that hackers aren't alone in exploiting supply chain complexity for inserting undesirable code into open source projects.

Prominent maintainers are adding counterproductive code for reasons of protest around geopolitical issues, he said.

The complexity of some of these components, and the sub-components they use, makes it difficult to see where counterproductive code has been added during an update. Doing a full code review of open source updates typically isn’t feasible for an enterprise, and somewhat defeats the purpose of leveraging open source code in the first place.

Daniel Kennedy

3. The case for SBOMs: Continuous evaluation needed

One way organizations are trying to reduce open source software risks is through the use of a software bill of materials (SBOM), said Ed Skoudis, president of the SANS Technology Institute.

SBOM demands from software vendors a list of software packages and libraries that they used to build their software. "Every organization doesn't have the time or wherewithal to see if every component has issues, but by having that information handy, having that list of ingredients, it pushes the vendors to be open and show what's going into their products," Skoudis said.

A software bill of materials takes a big bite out of the problem.

Ed Skoudis

The key to securing against supply chain attacks on upstream open source components is to carefully select and evaluate the dependencies—not just once, when including them for the first time, but continuously, said Endor Labs' Plate.

Organizations must decide on and monitor a set of key metrics or indicators during the lifecycle of their software dependencies, not just for direct dependencies but also for indirect ones.

Henrik Plate

Ratan Tipirneni, president and CEO of Tigera, a provider of security and observability for containers, Kubernetes and cloud, pointed out that while Log4j was the vulnerability that got everyone’s attention and made national news, over 4,000 high-severity vulnerabilities were announced in 2021. The recent discovery of the high-severity security flaw in the Packagist software repository, further demonstrates severe vulnerabilities continue to be discovered.

As the pace of innovation combined with the use of open source libraries increases, we will continue to see an increase in vulnerabilities and threats, Tipirneni said. "This is an ominous sign for highly constrained security and DevOps teams."

It is nearly impossible for any DevOps or security team to keep up with attackers. To close the security gap, businesses will need to bring the principles of Zero Trust and defense in depth to the entire CI/CD pipeline to actively mitigate risks with a combination of preventive measures and active defense.

Ratan Tipirneni

Image courtesy of Packagist's Twitter page.