The PHP programming language maintainers averted a software supply chain attack when unknown threat actors compromised the self-managed Git server and inserted a backdoor.
The malicious commits were made on May 28, 2021 to a Git repository of a still-in-development version of PHP.
However, PHP contributors Markus Staab, Jake Birchallf, and Michael Voříšek noticed the changes during the post-commit code review.
Supply chain attack targeted Zlib library, turned PHP into a remote web shell
The supply chain attack targeted any server that uses PHP ZLib compression when sending data. Most servers use this functionality on almost all content except images and archives that are already size optimized.
The supply chain attack would have turned PHP into a remote web shell through which the attackers could execute any command without authentication. This is because the malicious attackers would have the same privileges as the web server running PHP.
The backdoor is triggered at the start of a request by checking if the request contains the word “zerodium.” If this condition was met, PHP executes the code in the “User-Agentt” request header.
The header closely resembles the PHP “User-Agent” request for checking for browser properties.
The rest of the request would thus be treated as a command that could be executed on a PHP server using the server’s privileges. This would allow the hackers to run any arbitrary command without the need for further privileges.
Zerodium, the company mentioned in the hack, is a vulnerability broker that buys zero-day vulnerabilities and sells them to government agencies. However, it denied any involvement in the PHP Git server compromise.
Zerodium CEO Chaouki Bekrar accused the researchers of introducing the backdoor and trying to sell it, only to disclose the vulnerability after failing to secure buyers. However, the accusation is preposterous given the lifetime of the backdoor.
The malicious commits were pushed using Rasmus Lerdorf, the PHP project author, and Nikita Popov, a major PHP contributor working at JetBrains names. The attackers described the commits as intended to fix typo on the php-src repository.
Supply chain attack forces the PHP team to discontinue the self-managed Git server
Popov explained that although the team had not established how the intrusion occurred, it points towards a compromise of the git.php.net server rather than a compromise of an individual Git account.
The team said that maintaining their own “Git infrastructure is an unnecessary security risk” and chose to discontinue the git.php.net server making the repositories on Github the canonical copies for future PHP releases.
PHP contributors must also be added as part of the organization on Github and pass the two-factor authentication.
Popov also promised to review the PHP codebase beyond the two malicious commits and invited public alerts for any suspicious behaviors. Users should also check their /etc/zlib/zlib.c files for potentially malicious code especially the presence of zend_eval on any files in the /etc/zlib directory.
The PHP team had implemented a “home-grown” privilege management system called Karma on their Git Server. However, there’s no evidence suggesting that Karma was the source of the Git server compromise.
In 2019, the PHP team temporarily shut down its Git server after discovering that an attacker had maliciously replaced the official PHP Extension and Application Repository (PEAR) with a malicious one.
PHP powers 80% of all websites. Thus, a successful supply chain attack exploiting the language could prove catastrophic.
However, it’s unlikely that the compromise affected any users in the wild. The compromise was possibly executed by hackers who wanted to prove that they could compromise the PHP Git server.
Commenting on the PHP Git server compromise, Craig Young, the principal security researcher at Tripwire, says that self-hosting open-source projects must implement “reject suspicious commits” capabilities because they are more vulnerable to supply chain attacks.
“We are lucky that the malicious commits were detected before reaching production systems,” Young notes. “Had it not been detected, the code could have ultimately poisoned the binary package repositories which countless organizations rely upon and trust.”