The Sonar R&D team discovered a new attack vector in the PHP supply chain. Read about their findings and how to prevent and patch these code vulnerabilities.
Join the DZone community and get the full member experience.
Supply chain attacks are a hot topic for development organizations today. Last year, in the largest ever software supply chain attack, a backdoor infected 18,000 SolarWinds customers. Earlier this year, a security researcher was able to breach Apple, Microsoft, PayPal, and other tech giants using a new supply chain attack technique.
The underlying design exploited by these attacks is that all modern software is built on top of other third-party software components, often without clear visibility of all the downloaded packages. And while reusing many components allows to speed up the development process, infecting the supply chain is a very effective and subtle attack vector to compromise many organizations at once.
While supply chains can take different forms, one of them is significantly more impactful: by gaining access to the servers distributing these third-party software components, threat actors can alter them to obtain a foothold in the systems of their users.
One year after our first publication about a critical vulnerability in the PHP supply chain (read more in PHP Supply Chain Attack on Composer), the Sonar R&D team uncovered a new critical vulnerability in similar components. It allowed taking control of the server distributing information about existing PHP software packages, and ultimately compromising every organization that uses them.
In this publication, I present our findings in the biggest PHP package manager, Composer, and its official package repository Packagist. I explain how the discovered code vulnerability works in theory, how it affected Packagist, and how we could demonstrate it on both a test instance and the real one. I will also look at how these code vulnerabilities can be prevented and how the maintainers patched this particular one.
The attack we demonstrate in this publication allowed us to execute arbitrary commands on the server running the official instance of Packagist. Composer uses this service to fetch the metadata associated with a given package and its dependencies. Every month, around 2 billion software dependencies are downloaded with Composer from Packagist, among which at least 100 million of these installs require fetching metadata from Packagist.
The security of these backend services is critical: they perform the association between the name of a package and where the package manager should download it from, so compromising them would allow attackers to force users to download backdoored 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, most open-source and commercial PHP projects would have been impacted.
You are already safe if you are using the default, official Packagist instance or Private Packagist. I responsibly disclosed our findings, and maintainers patched it on the public production instances within hours.
If you integrate Composer as a library and operate on untrusted repositories, upgrade at least to Composer 1.10.26, 2.2.12, or 2.3.5 to benefit from the security patches for CVE-2022-24828.
Now, let’s dive into the technical details of this new finding to see what we can learn. As you’ll see, there is a direct link between what we documented in PHP Supply Chain Attack on Composer: I will first summarize what my team and I did a year ago, show how one of our approaches leads to a dead end, and finally see how we could reuse the same exploitation technique that we introduced last year.
My team and I’s previous work on CVE-2021-29472 provided us with insights on interesting attack surfaces. Even though I reviewed the patches fixing CVE-2021-29472, I could have missed something, and getting back on them is relevant.
The vulnerability my team and I identified occurred in the implementation of VcsDriver sub-classes: one driver exists for every supported Version Control System (hence the name) like Git, Mercurial, Subversion, etc.
