Comment: Critical Packagist Vulnerability Opened Door for PHP Supply Chain Attack

Code security company SonarSource has published details on a severe vulnerability impacting Packagist, which could have been abused to mount supply chain attacks targeting the PHP community. Packagist is the default repository for PHP dependency manager Composer, aggregating public PHP packages that can be installed using Composer. Each month, Composer is used to download more than 2 billion packages. According to Sonar’s security researchers, the recently identified vulnerability could have been used to hijack over 100 million requests to distribute malicious dependencies, leading to the potential compromise of millions of servers. More information: https://www.securityweek.com/critical-packagist-vulnerability-could-have-allowed-php-supply-chain-attack

Subscribe
Notify of
guest

1 Expert Comment
Newest
Oldest Most Voted
Inline Feedbacks
View all comments
Mike.mcGuire
Mike.mcGuire , Senior Security Solutions Manager
InfoSec Expert
October 7, 2022 10:47 am

A critical vulnerability, numbered CVE-2022-24828 by the NVD, has been identified in a crucial component of the PHP supply chain. The vulnerability affects Composer, which is the biggest PHP package manager, and its official package repository, Packagist. Making this vulnerability so severe is the nature of the exploit, which allows attackers to take control of the server distributing information about PHP packages, in turn forcing users to unknowingly download malicious dependencies and packages. What makes this vulnerability so unique is that it affects an organisation’s SDLC or build-chain, and not the application itself. It other words, this vulnerability could be used by attackers to exploit the methods used to produce software, rather than the software itself. At this time, there is no reason to believe that successful exploits have taken place, and Composer maintainers have already patched the issue.

While we can all rejoice over the fact that there have been no known exploits, we should use this vulnerability as a stark reminder of the complexity and long tail of modern software supply chains, with which comes unique risks. The concept of a secure software supply chain is not new, and we’ve been taking steps to secure the dependencies we use for quite some time now. But, as attackers adapt, and reliance on third-party and open source code increases, we need to adapt as well. This does not mean we should stop managing the dependencies we use, instead we need to think more about these dependencies; think beyond identifying them, and consider where they’re coming from, how and why they’re being chosen, who has access to these decisions, and what happens should you miss something during those checks.

The value of a complete software supply chain risk management program is made apparent by vulnerabilities such as this one. By maintaining precise details and inventories of an SDLC, such as the tools involved, languages used, and dependencies leveraged, organisations can quickly assess their exposure when vulnerabilities like this are flagged. Whether a vulnerability affects the SDLC like CVE-2022-24828 does, or finds its way into an application, it’s the visibility of the software supply chain that enables organisations to stay alert, act accordingly, and build in necessary redundancies to reduce risk to comfortable levels.

Last edited 1 month ago by mike.mcGuire
Information Security Buzz
1
0
Would love your thoughts, please comment.x
()
x