We are normally informed about supply chain hacks like this one from sources such as US-CERT (Homeland Security), DoD ARCYBER, SANS and the like. Official sources like these are important to follow to stay current, but yesterday we saw one happen more or less in real time.
On May 24th, 2022, we heard about an emerging issue and scrambled to investigate a phpass exploit that was only lurking on Twitter and Reddit. This supply chain attack injected malicious code which sends two hardcoded AWS environment variables to a heroku app where the attacker can mine them.
What follows is a quick rundown of what we’ve learned about this exploit as well as how you can determine if you are affected and remediate if necessary.
In August 2021, hautelook's PHPass - a library that implemented portable password hashing - was suddenly deleted from GitHub along with the hautelook organization without any notice or any word from the original developers. Many projects that relied on this functionality were forced to quickly find a replacement - including Concrete - while other projects that hadn't been updated since August likely still require this library to this day.
Packagist.com is the main repository of libraries that are installable via Composer, a tool for PHP that lets developers automatically include specific versions of dependencies. PHPass was registered in Packagist and set to auto-update any time the GitHub repository changes, even long after the PHPass repository and hautelook organization were deleted.
On May 19th, 2022 a malicious user discovered the hautelook organization name was no longer restricted and available for registration. This user created a new account with the name "hautelook" and created a repository named "phpass". Since this repository had the exact same URL as the original official PHPass that was deleted back in August, Packagist was happy to begin tracking the repository as if it had never been deleted.
On that same day, around 7:00am PST, that malicious user committed a copy of the old official PHPass repository, added some code to collect AWS credentials, and tagged a release that included this malicious code. Almost immediately, Packagist noticed the change and began serving the new release as if it were from the original hautelook PHPass repository deleted months ago.
On May 24th, 2022, administrators of Packagist were alerted to the malicious release and took steps to resolve the issue by deleting the malicious version and sending people to a different fork of PHPass which had no malicious code. In order to be affected by this, a developer would have had to not update dependencies for the entire time the PHPass package was deleted, then suddenly update dependencies between May 19th and May 24th. Additionally, the malicious code only checked for two hardcoded environment variables "AWS_ACCESS_KEY_ID" and "AWS_SECRET_ACCESS_KEY", so the attack would only be effective against stacks configured with both of these environment variables.
With the web being powered by many different libraries that include one another, you can think of building software as a supply chain of sorts. Very few (if any) developers write their code from absolute scratch. Including the latest versions of libraries required to make their software work is important, and that’s what Packagist and Composer let you easily do.
The challenge with this type of automated build process is, if a library becomes compromised, it can quickly work its way into thousands of different web applications without being noticed which is what happened here. In this specific case, systems are only compromised if they run `composer update` and only if they did NOT run `composer update` at all in the prior 9 months but DID run it in the 5 days the issue was present
We recommend updating your phpass if you've updated this package during the affected 5 days, and consider replacing PHPass with the built in password hashing functionality in PHP.
We believe Packagist and GitHub could both take steps to prevent this sort of attack in the future. If Packagist were to disable auto-update when it detects a repository has been deleted, or if GitHub were to make it more difficult to take over account names and possible to rename accounts without the potential for a third party taking over the account, this sort of incident could have been avoided.
If you happen to find any vulnerabilities in the Concrete CMS core (whether they are being actively exploited or not), please report them to Concrete CMS’ HackerOne program or, if unable to do so, via security@concretecms.org. Concrete’s vulnerability management program triages all reports and remediates them according to the CVSS v 3.1 score the Concrete security team assigns. Since we are an open-source project, you are highly encouraged to submit a pull request to fix any vulnerability you report!
We instituted a CVE program with the release of Concrete CMS 8.5.4 and are committed to obtaining CVEs for each Concrete vulnerability remediated for supported Concrete versions.