In wake of PHP Git server attack, developers should employ encryption

In wake of PHP Git server attack, developers should employ encryption


In wake of PHP Git server attack, developers should employ encryption
Laptop with an integrated development environment, showing a file written in the PHP programming language. (PXHERE, CC0, via Wikimedia Commons)

A researcher said Wednesday that two malicious commits that were added to the PHP web development programming language’s official Git server earlier this week may have been prevented if the maintainers had enabled signed commits (encryption) on the server.

For those unschooled in the language of programming, a commit in the Git world is when a source code repository gets refreshed. Malicious commits happen when malicious code gets placed into the refresh. When a programmer cryptographically signs a commit, it’s known as a signed commit.

Asaf Karas, co-founder and CTO of Vdoo, noted that while there’s no silver bullet and security researchers don’t know precisely how the attackers compromised the PHP server, as far as he could tell, the malicious commits used by the PHP server attackers were not signed commits.

“It’s possible to spoof a signed commit, but the attacker would have to either have a vulnerability or a private key from one of the maintainers,” Karas said. “We’re just telling anybody who maintains a Git server to enable the signed commit function on the server, it can prevent a lot of security issues.”

News of the attack raised eyebrows among security researchers because if the malicious commits had not been identified, they would have gone through testing cycles before ultimately being tagged as part of an official release – and nearly 80 percent of websites use PHP.

“It would take some time, but if the backdoor went undetected, it could eventually proliferate out to easily tens of thousands of systems,” said Craig Young, principal security researcher at Tripwire. “The number of compromised systems would primarily depend on how quickly end users could upgrade their PHP environment compared to how quickly the security research community identifies the backdoor.”

Evidently, the malicious commits were discovered after a routine post-commit review. Young said what tipped the developers off was that the malicious commits contained a description which was completely inconsistent with the associated code change. The attacker had labeled one of the two commits as a “typo fix” when in reality it was introducing new code. In this case, the malicious code was rather blatant, but Young said it’s worth noting that an attacker with a more sophisticated backdoor mechanism built across multiple seemingly innocuous code commits might not get detected.

“It was a close call as the malicious code was detected very early and was only introduced into a development version that isn’t widely used in production,” Vdoo’s Karas said. “Moreover, the attackers were not sophisticated in how they changed the code. The changes were noticeable and still contained indicative incriminating strings such as those mentioning the vulnerability broker company Zerodium. One could even hypothesize that this was a provocation attack meant to be detected. In the next attack, the attackers might be much more careful in crafting a code change that could stay hidden long enough for it to reach release versions ultimately installed in production on many real systems.”

Chad Anderson, senior security researcher at Domain Tools, added that this close call never materialized into a full-fledged attack, only because the developers spotted it in this instance.  

“There are half-dozen instances in this year alone where supply chain compromises have led to attackers running arbitrary code on other’s machines — at Apple and Microsoft included,” Anderson said. “That’s why developers need to leverage the tools that GitHub, GitLab and other community sites offer that verify their builds, runs tests on their code, and confirms that an adversary hasn’t injected their own malicious instructions into the code base.”

For its part, the PHP maintainers decided that running their own Git infrastructure has become an unnecessary security risk, so they will discontinue the git.php.net server. Instead, the repositories on GitHub, which were previously only mirrors, will become canonical, explained Nikitia Popov, a core PHP developer. With this change, Popov said from this point on, any code changes should get pushed directly to GitHub rather than the git.php.net server.

DomainTools’ Anderson explained further that Git functions as the version control system PHP uses to have developers collaborate on software they are building. When it operates correctly, it resolves conflicts where one developer adds code over the top of another’s changes, shows every bug fixed as a “diff” that can be replayed through time, and allows for every line of code in that history to show which developer added that line. In contrast, GitHub is the website owned by Microsoft that hosts public and private Git repositories for developers. GitHub has a number of other tools such as code security checks, forums, bug trackers and other community pieces that make working on software together easier.

“In this case PHP was using their own self-hosted Git server,” said Anderson. “That server was compromised and attackers tried to backdoor the code on that server. By moving to GitHub, PHP now has all of the community tools available on that site, as well as additional security checks, testing pipelines and other free items that come with GitHub.



Source link

Please follow and like us:

Leave a Reply

Your email address will not be published. Required fields are marked *