In a classic watering hole attack, hackers compromised a well-known, respected high-traffic Website and planted malware in a bid to infect unsuspecting visitors. On Oct. 24, Google began to flag PHP.net as being a site hosting malware, i.e., potentially a watering hole.
PHP.net is the community home for the open-source PHP programming language that powers hundreds of millions of Websites around the world (including this one). Initially, PHP.net administrators claimed that Google was wrong and that it was some kind of false-positive scan for malware.
Within hours, PHP.net administrators realized that in fact multiple PHP servers and domains were compromised. Among the compromised sites are www.php.net, static.php.net, git.php.net and bugs.php.net.
That’s a very big deal with huge implications. Is PHP itself now at risk? What about all the people who visit php.net?
According to PHP.net, malware was served to “a small percentage” of users between Oct. 22 and Oct. 24.
More importantly, PHP.net administrators verified that the core Git repository was not compromised, though the site is currently now in a read-only mode. Git is the version control system used by PHP (and countless other software projects today). If the PHP Git server was compromised, the implication is that malicious code could be inserted into the PHP language itself.
In a way this reminds me of the kernel.org attack from 2011 in which hackers somehow breached the main site behind Linux kernel development. In that case, malware wasn’t being delivered to users, but attackers were likely trying to get at Linux kernel code. It’s an attack that caused some minor delays in Linux kernel development but ultimately was found to be unsuccessful in creating a malware infection. Kernel.org also uses Git as its version control system.
The way that Git works is that it’s a distributed system, making it easy for developers to identify where things come from and when something has been altered. The highly distributed nature also means that there isn’t really a single point of failure in the system either.
So in the case of the PHP.net attack, I personally see little risk in any malware injection into PHP itself as being something that wouldn’t be found quickly. On the other hand, the malware/watering hole attack is a bigger problem in my view. Although PHP itself is not likely at risk, developers who visited the php.net site were potentially compromised.
In response, PHP.net is resetting user passwords and is now also in the process of getting a new SSL certificate for php.net.
In my opinion, the fact that malware got onto the site in the first place means there is a weak spot on php.net in terms of either access control, input validation or code scanning. Perhaps just a single user (perhaps compromised, perhaps maliciously) was able to put a file on the site that wasn’t validated by some form of automated scanner that might have caught the issue. The integrity of a site like php.net relies on developers as much as it does on the server in some cases.
The official post mortem on the incident is expected next week. While this incident is alarming, it’s also reassuring. The PHP.net community has responded rapidly to the issue and the nature of Git limits the risk such that the security integrity of the PHP language is likely still intact.
Sean Michael Kerner is a senior editor at eWEEK and InternetNews.com. Follow him on Twitter @TechJournalist.