3rd Party Risk Management , Application Security , Breach Notification

Attacker Updates PHP Source Code to Include Backdoor

Open-Source Project Team Says Change Might Trace to White Hat or Script Kiddie
Attacker Updates PHP Source Code to Include Backdoor
Malicious code added to PHP's source code repository included a reference to zero-day vulnerability broker Zerodium.

An attacker added a backdoor to a code repository for the widely used, open-source PHP server-side scripting language, the project's developers have warned.

See Also: Top 50 Security Threats

In a Sunday alert, PHP contributor Nikita Popov said that attackers appear to have infiltrated the project's self-hosted Git server. Git is widely used open-source version-control software.

An attacker made two "malicious Git commits," Popov says in the security alert. Commits refer to adding "safe" code to a project's source code repository so that it will be contained in the next distribution.

Market researcher Web Technology Surveys reports that at least 79% of all websites use PHP.

The flaw appears to have been first spotted by PHP developers, including Michael Voříšek, who were reviewing a code change allegedly added to deal with fixing a typo. But they found that if an attacker sent a PHP-using website an HTTP request that began with "zerodium," it would allow the attacker to execute arbitrary code.

Malicious Addition Excised

As of Monday morning, the code had been rolled back to a previous version that doesn't contain the backdoor. It's unclear so far if the backdoored code was downloaded and added to any public-facing websites by anyone handling beta code. But the last stable release of PHP to be issued, version 8.0.3, was released on March 4, well before the malicious commit was made on Sunday.

Popov, who's also a software developer focusing on PHP for software development firm JetBrains, says one malicious commit was made in his name, and another in the name of PHP co-author Rasmus Lerdorf.

Both say they did not make those commits, and Popov notes that the project team's core members are now investigating. "We don't yet know how exactly this happened, but everything points toward a compromise of the git.php.net server (rather than a compromise of an individual git account)," he says.

"While the investigation is still underway, we have decided that maintaining our own git infrastructure is an unnecessary security risk, and that we will discontinue the git.php.net server," he adds. "Instead, the repositories on GitHub, which were previously only mirrors, will become canonical. This means that changes should be pushed directly to GitHub rather than to git.php.net."

Popov issued the alert after consulting with other team members via a discussion on the PHP support group on Stack Overflow.

"I think this is a priceless opportunity to shut down git.php.net and declare the github repos canonical," he posted.

"Yeah, burn it with fire, having our own git servers complicates everything, it's a time sink in every way," PHP contributor Joe Watkins posted in response. "The facts are, we [expletive] suck at keeping things safe, and should hand over to the professionals."

Popov notes that "previously write access to repositories was handled through our home-grown karma system," whereas now anyone who wants to contribute to code will need to sign up to PHP's GitHub organization. "Membership in the organization requires 2FA to be enabled," he says, meaning anyone who attempts to push code will have to use multifactor authentication to validate their identity.

Zerodium Named in Backdoor

Confusion continues about what the attacker might have been trying to accomplish.

"Code added to the Git source code repository in Popov's name executes PHP code from within the useragent HTTP header, if the string starts with 'zerodium,'" warned developer Michael Voříšek.

The fake commit calls out Zerodium, a Washington-based security firm that specializes in buying and selling zero-day vulnerabilities.

In 2017, a zero-day flaw in the PHP was sold to Zerodium, as noted by Mikko Hypponen, chief research officer at Finnish security firm F-Secure.

In other words, whoever added the code doesn't appear to have been trying to be stealthy.

"It's an odd one, because it's so.... freaking obvious," says a participant on PHP's Stack Overflow chat board. "It's the 'REMOVETHIS: sold to zerodium, mid 2017' which has me confused / concerned. What was sold in 2017?"

"Right, I think it might have been a poorly delivered whitehat, tbqh," responded PHP project developer Sara Golemon, who's served as the release manager for both the 7.2 and current 8.0 branches of PHP, referencing what might have been the efforts of a white hat hacker attempting to do good. "Or an utterly inept skript-kiddie. Hard to tell sometimes."

"That we don't know how we won is not important, every win counts," Watkins posted.

But Chaouki Bekrar, CEO of Zerodium, suggests that one or more attackers had failed to find a zero-day broker who wanted to buy the underlying bug or exploit, "so they burned it for fun."

The malicious additions to the PHP source code had been eliminated by Monday morning, and Popov says a more thorough review of PHP source code is now underway. "We're reviewing the repositories for any corruption beyond the two referenced commits," he says. "Please contact security@php.net if you notice anything."

This story has been updated with Zerodium CEO Chaouki Bekrar's comments.


About the Author

Mathew J. Schwartz

Mathew J. Schwartz

Executive Editor, DataBreachToday & Europe

Schwartz is an award-winning journalist with two decades of experience in magazines, newspapers and electronic media. He has covered the information security and privacy sector throughout his career. Before joining Information Security Media Group in 2014, where he now serves as the executive editor, DataBreachToday and for European news coverage, Schwartz was the information security beat reporter for InformationWeek and a frequent contributor to DarkReading, among other publications. He lives in Scotland.




Around the Network

Our website uses cookies. Cookies enable us to provide the best experience possible and help us understand how visitors use our website. By browsing inforisktoday.eu, you agree to our use of cookies.