Malicious commits found in PHP code repository: What you need to know

Malicious commits found in PHP code repository: What you need to know

You’ve probably heard that PHP’s Git repository was recently compromised, allowing backdoors to be added to the code located there. You may also be wondering what that means, what a supply chain attack is, and how you could be affected. Read on and we’ll lead you though a straightforward description of this attack’s many moving parts.

What is a supply chain attack?

This is where an attacker compromises something a project or organisation depends on. In the world of modern software development, where third-party code is reused on a massive scale, it often means compromising something used by lots of other organisations, which can result in the compromise of everyone else further down the chain too.

The bigger the target they snag initially, the wider the reach as the attack slides downstream. This can be very messy to sort out afterwards as news of the attack slowly comes to light over time. It’s a win for attackers, as organisations can’t typically build everything they need themselves. Third-party tools and software will come into play eventually and if one of them is compromised by attackers, everything that uses or includes them is affected.

In this case, attackers going after PHP, which is used the world over, would qualify as a potentially huge supply chain attack.

What is Git?

Git is a version control system which tracks changes to your file(s) over a period of time. It makes this rather cumbersome process much more straightforward thanks to its repository. You can roll back changes if you make a mess of things, move files around, merge contributions from others, and so on.

That may sound a bit confusing, but don’t worry. A very basic comparison would be the page history view on Wikipedia, where you can see all changes made from creation of the page onward. If you understand how that works, then you’ll grasp how Git allows you to outline the who’s and what’s of edits made, the file reversions, the ability for different developers to work on projects in a non-chaotic fashion, and so on.

Put simply, it’s really good and very handy for all sorts of projects.

What is PHP?

PHP is something you almost certainly run into all the time. PHP, created in 1994, is a scripting language which is ideal for web development. It’s also incredibly popular. If something went wrong with or for PHP in terms of malicious actions, that could be quite bad.

As it happens…

A backdoor was added to the PHP code repository, which is definitely up there in the “quite bad” stakes. The PHP team aren’t sure how it happened yet.

What did the attackers do?

Remember the Wikipedia mention earlier? You know how some pages attract trolls and an edit war with defacements and roll-backs is the end result? A similar thing happened here. The malicious code additions were made by someone disguising their alteration as a typo fix, under the name of the creator of PHP.

The rogue code allowed for backdoor access into websites running the non-legit version of the code. It was removed, put back, and removed again some time later.

As a result of this attack, the PHP team are making some changes to how they operate moving forward. According to PHP’s Nikita Popov, “everything points towards a compromise of the server”, meaning that the computer that Git was running on was compromised, rather than individuals’ Git accounts. So, like much of the rest of the world, the team is moving its code to GitHub:

While investigation is still underway, we have decided that maintaining our own git infrastructure is an unnecessary security risk, and that we will discontinue the server. Instead, the repositories on GitHub, which were previously only mirrors, will become canonical.

Contributors will also have to be part of the PHP organization on GitHub, which requires two-factor authentication.

This will hopefully make it much more difficult for something like this to happen again.

Am I affected?

According to ZDNet’s reporting, the commits (changes) were caught in the nick of time. As a result, users shouldn’t be affected. The PHP team are also digging into everything available, to ensure no other dubious alterations were made without anybody realising.

In short, you’re likely fine. The story is still developing, so it’d be wise to keep an eye on the news for the next few weeks. As for the attack itself? Opinion is split in some quarters as to how malicious it was intended to be. Although the commits were done in a way to suggest they wanted to stay hidden, it was almost inevitable they’d be found. Some folks have suggested a zero day was publicly “burnt” (used up) to warn of the danger of such a technique. Others maintain it was flat out malicious, end of story.

Whatever the truth of the story, it’ll be fascinating to see how things pan out. A little less excitement for stories related to code keeping 79% of websites ticking over would be a nice status quo to go back to.