Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
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.
During the post-commit code review, however, Markus Staab, Jake Birchallf, and Michael Voek, all of whom contributed to PHP, saw the changes.
An attack on the supply chain went after the Zlib library and turned PHP into a remote web shell.
The supply chain attack was aimed at any server that sends data using PHP ZLib compression. Most servers use this feature for almost all content, except for images and archives that are already optimized for size.
With the supply chain attack, PHP would have become a remote web shell that the attackers could use to run any command without logging in. This is because the attackers would have the same rights as the PHP-running web server.
At the beginning of a request, the backdoor is opened by checking to see if the word “Zerodium” is in the request. PHP runs the code in the “User-Agent” request header if this condition is met.
The header looks a lot like the “User-Agent” request that PHP uses to check for browser properties.
The rest of the request would then be treated as a command that could be run on a PHP server using the server’s privileges. This would let the hackers run any command they wanted without needing any other permissions.
Zerodium, the company mentioned in the hack, is a vulnerability broker. It buys zero-day vulnerabilities and sells them to government agencies. But it denied having anything to do with the PHP Git server hack.
Zerodium CEO Chaouki Bekrar said that the researchers put in the backdoor and tried to sell it, but when they couldn’t find buyers, they revealed the vulnerability. But the accusation is crazy, given how long the backdoor has been there.
Rasmus Lerdorf, the creator of the PHP project, and Nikita Popov, a major PHP contributor who works at JetBrains, both had their names used to push the malicious commits. The attackers said that the changes to the php-src repository were made to fix a typo.
Because of a supply chain attack, the PHP team has to stop running its own Git server.
Popov said that the team hadn’t figured out how the hack happened yet, but the evidence points to the git.php.net server being broken into rather than a single Git account.
The team said that keeping their own “Git infrastructure” was an unnecessary security risk, so they shut down the git.php.net server and made the repositories on Github the official copies for future PHP releases.
PHP contributors must also be added to the organization on Github and pass the two-factor authentication.
Popov also said that he would look at the PHP codebase beyond the two malicious changes, and he asked the public to let him know about any strange behavior. Users should also check their /etc/zlib/zlib.c files for potentially harmful code, especially if any files in the /etc/zlib directory have the zend eval command.
On their Git Server, the PHP team had put in place a “home-grown” system for managing privileges called Karma. But there is no evidence that Karma was the reason why the Git server was hacked.
In 2019, the PHP team temporarily shut down its Git server after finding out that an attacker had replaced the official PHP Extension and Application Repository (PEAR) with a malicious one.
PHP powers 80% of all websites. So, a successful supply chain attack that takes advantage of the language could be very bad.
But it’s not likely that any users in the wild were affected by the breach. Hackers may have done this because they wanted to show that they could break into the PHP Git server.
Craig Young, the chief security researcher at Tripwire, says that self-hosted open-source projects need to have the ability to “reject suspicious commits” because they are more likely to be attacked through the supply chain.
“It’s a good thing that the bad commits were found before they got to production systems,” says Young. “If it hadn’t been found, the code could have poisoned the binary package repositories, which are used and trusted by many organizations.”
READ MORE ARTICLES:
