PHP Compromised: What WordPress Users Need to Know

Late Sunday night, on March 28, 2021, Nikita Popov, a core PHP committer, released a statement indicating that two malicious commits had been pushed to the php-src git repository. These commits were pushed to create a backdoor that would have effectively allowed attackers to achieve remote code execution through PHP and an HTTP header.

Remote Code Execution makes it possible to issue commands to a server remotely which allows attackers to do things like create new files, steal data on the server, delete files, and essentially take over the affected server by any websites powered by PHP.

In this post, we analyze the compromise and the code pushed to the repository, while also discussing how this affects WordPress.

PHP is Open Source like WordPress

PHP is a language that is open source, which, like WordPress, means that any individual can contribute to its development.

“Anybody who programs in PHP can be a contributing member of the community that develops and deploys it.”

Prior to the compromise, The PHP Group handled all write access to the repository on their own git server http://git.php.net/ using an internal “Karma” system. This Karma system essentially gave contributors different access privileges and allowed them to contribute directly to various resources based on their Karma. A contributor’s Karma also needed to be explicitly requested, and if granted the contributor would be assigned a @php.net account.

Due to yesterday’s compromise, the PHP Group has stated that they will be moving away from their current self-hosted and managed git infrastructure and will be moving to GitHub to turn their currently “mirrored” repositories into “canonical” repositories, which means that all further changes will be tracked and managed in GitHub. The PHP Group has also announced that they will be moving away from the currently managed Karma system and requiring contributors to be a part of the PHP organization on GitHub. They will also require that two-factor authentication be enabled on all accounts with write access to combat password compromises that could lead to unauthorized commits to the repository.

Analysis of the Compromise

On Saturday, March 27, 2021, the first of two commits was pushed to the repository. The first commit had the description of Fixes minor typo. Signed-off-by: Rasmus Lerdorf <rasmus@lerdorf.com> by the committer rlerdorf. This account belongs to Rasmus Lerdorf, a co-author of the PHP language.

The second commit had no description, however, the title was Revert "Revert "[skip-ci] Fix typo"" which reverted the revert of the original commit by rlerdorf, which indicates that the attacker reverted Nikita’s original attempt to revert this back door. This commit was made to look like it was coming from the nikic account. This account belongs to Nikita Popov, a highly respected contributor to the PHP project.

The use of these two individual accounts made it look like the commits were coming from highly trusted contributors and authors, which was done in an attempt to make the commits look authentic and reputable. The attacker also made sure that the changes appeared to be minor fixes to correct a typo in order to hide their intentions.

At first glance it might appear that rlerdorf’s and nikic’s accounts were compromised, however, the PHP group has explicitly stated that they believe the malicious commits were a result of a compromise within their git infrastructure rather than any individual account.

In addition to adding code using trusted committers, the attackers also added a comment in the changes that stated "REMOVETHIS: sold to zerodium, mid 2017" which implied that the exploit was sold to Zerodium, an exploit acquisition company for zero-day vulnerabilities. This may have been intended to trick reviewers into thinking that the compromise occurred due to a leak from the Zerodium company or potential sale of the exploit to the company. However, Chaouki Bekrar, the CEO of Zerodium, released a statement on Twitter denying any involvement in the malicious commits that were pushed to the repository.

The following is a screenshot of the commit that appeared to have come from the rlerdorf account.

The following is a screenshot of the commit that appeared to have come from the nikic account.

The code is the same for both of those attempts. Essentially, the code checks to see if the custom user agent HTTP Header contains the string “zerodium”. If PHP processed a request with this user agent, it would run the function zend_eval_string which could be used to run commands and achieve Remote Code Execution. While the commits were fairly simple, they could have resulted in an enormous amount of damage had they been released in a production version of PHP, considering PHP powers around 80% of websites using server-side programming. Fortunately, these malicious commits were caught fairly quickly and were only in a development version of PHP.

Threat Actor Analysis
In contrast to the SolarWinds compromise we saw back in December of 2020, this appears to have been the work of an individual, potentially a skilled “script kiddie” just looking for some fun or a simple “cybercriminal” that may have wanted to try and sell the exploit if the version of PHP had been pushed to production with the malicious code undetected.

Analyzing the compromise, we can see that the backdoor was not very well concealed, indicating that the attacker may have expected to get caught, or that they didn’t have the skill to conceal it very well. Further, since this was a minor commit with very little concealment, it’s highly unlikely that this was the work of more than a single individual. The lack of complexity and the seemingly ironic use of “zerodium” throughout the backdoor leads us to believe that this attack may have been performed as a high profile prank or as a way to just say they did it.

Does this affect WordPress?

This compromise does not affect any WordPress sites in production. Fortunately, the commits were detected very quickly and were only live for a few hours in a development branch. In a statement released to Bleeping Computer, Nikita Popov said, “The changes were on the development branch for PHP 8.1, which is due to release at the end of the year,” meaning the malicious code was pushed to a branch of PHP that isn’t in production. They also stated that “the changes did not make it into any tags or release artifacts,” indicating that the malicious code was never actually released. This means the compromised version of PHP did not and will never reach your server.

Will the change to GitHub prevent this from happening again?

Moving from a self-hosted repository to GitHub adds some controls that were not available before and offloads some of the security management involved in self-hosting their own git infrastructure that should improve the security posture of the PHP organization’s git management. In addition, a requirement for vetting committers as they are added to the PHP organization should add an additional level of security that should prevent this from occurring again in the future.

As with all supply chain attacks, there are certain risks to any code base. Fortunately, The PHP Group responded swiftly to combat this compromise and took steps to prevent this from happening again in the future which indicates how seriously they take security.

The good news is that these malicious changes were caught quickly by the PHP community, and there are no reports of production sites affected by this malicious code. The open source nature of the PHP community provides the same kind of protection that WordPress also enjoys, ensuring that anomalous code or activities are identified and managed quickly.

Conclusion

In today’s post, we analyzed the PHP compromise that occurred over the weekend providing you with some insights as to what exactly happened. This compromise should have no effect on any WordPress sites as the malicious code was never released into production or contained in any tags or release artifacts. As this story evolves we will continue to keep you updated.