Two malicious commits were made to the PHP web development programming language’s official Git server earlier this week, and all of this could have been prevented assuming the mainteners had enabled signed commits on the server. Signed commits provide encryption, making it a lot more difficult to manipulate or get inside of.
A commit in the Git sphere is when a source code repository gets refreshed. Malicious commits can occur when code gets placed into the refresh, that was not intended to be there by the original developers. When a programmer cryptographically signs a commit, this is what is known as a signed commit.
BREAKING: #PHP Git server is the latest victim of a software supply chain attack in which attackers planted a remote code execution #backdoor in the PHP source code.
PHP powers almost 8 out of 10 sites on the internet, making this upstream attack noteworthy.#opensource #git https://t.co/HOcPB3dSbd pic.twitter.com/yt5nka5xUt
— Ax Sharma (@Ax_Sharma) March 29, 2021
According to Asaf Karas, the co-founder and the CTO of Vdoo, there’s no silver bullet in terms of security. Researchers do not quite know how the attackers compromised the PHP server precisely. The malicious commits used by the PHP server attackers were not signed commits.
Karas had the following to say: “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, 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.”
This news of the attack raised eyebrows across security researchers due to the fact that if the malicious commits had not been identified, they would have gone through a lot of testing cycles before being tagged as part of an official release. Keep in mind that 80% or more of all websites currently online use PHP, as it is the backbone of WordPress.
The malicious commits were discovered after a routine post-commit review, and what tipped the developers off was that the malicious commits actually contained a description that was completely inconsistent with the associated code. In other words, the hackers managed to label one of the two commits as a “typo fix”, while it was introducing new code. The malicious code was blatant, but it’s worth noting that an attacker with a more sophisticated backdoor mechanism that is built across multiple seemingly innocuous code commits could have gone through without detection.
Karas carried on to say the following: “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. 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.”
