PHP project site hacked, served malware

Visitors to PHP.net were served JavaScript malware last week. The site admins have removed the actual threats, but the method by which the site was breached is still not known
Written by Larry Seltzer, Contributor

PHP.net, the home site for the PHP open source web site scripting language, was hacked last week and served malware to some users.


The initial reports came after Google's Safe Browsing system began flagging the site as malicious. PHP creator Rasmus Lerdorf initially claimed these were false positives, but the evidence soon bore out Google's analysis.

The site admins put out an initial analysis of the incident the same day. The servers which were flagged were taken down and the services running on them were moved to new servers which the admins claim are secure. They say that the cause of the breach is not yet known, and they have provided no further information on the cause.

They also say they have verified that the source code repository for PHP was not compromised, but that it was possible the attackers had access to the site's SSL private key. They therefore revoked the certificates and thereby closed off SSL access to the site.

They restored SSL access the next day with what they called a new certificate. This certificate was issued on June 2 of this year. Perhaps it's not new, but just known not to be compromised. [UPDATE: The PHP Group, which runs PHP.net, has told us that the certificate is in fact new, but that the validity dates of the old one were left in place.]

Johannes Ullrich from the SANS Technology Institute takes this opportunity to point out the superiority of code signing over file hashes for authentication and integrity verification of files. Code signing allows users to verify the integrity and authenticity of files using a signed cryptographic hash and the public key of the signer. The private key with which the file is signed needn't - and in fact, shouldn't - be kept on the same system as the file itself. But a simple file hash necessarily needs to be on the same system as the file.

If the attackers actually had access to the SSL key, it indicated that they had root access. If so, they had access to the hashes as well as the file, and could have changed both.

The site admins promise a more complete post-mortem analysis, probably this week.

Editorial standards