Instead, developer Nikita Popov said in a detailed post, the issue was probably due to a leak of the master.php.net database.
As iTWire reported, the project moved its operations from its own git server to the Microsoft-owned software code repository GitHub after two malicious commits were discovered in the php-srx repository in the name of founder Rasmus Lerdorf and Popov.
PHP is a general-purpose scripting language and the most widely used on the Web, with popular content management systems like WordPress, Drupal and Joomla! all being written using it.
Elaborating on what had happened, Popov said when the first malicious commit was made under Lerdorf's name, the change was reverted and commit access to Lerdorf's account revoked on the assumption that this was an individual account compromise.
"In hindsight, this action didn't really make sense, because there was (at the time) no reason to believe that the push occurred through Rasmus' account in particular," he wrote. "Any account with access to the php-src repository could have performed the push under a false name."
Once the second malicious commit was noticed, Popov said he took a close look at the logs of the project's gitolite installation to try and find out which account had been used to carry out these commits.
But while all adjacent commits were accounted for, no git-receive-pack entries were present for the two malicious commits. This was taken to mean that these two commits bypassed the gitolite infrastructure entirely and hence was interpreted as indicating a server compromise.
"Shortly after that, we made the decision to discontinue git.php.net and make GitHub our primary repository host instead. Retaining our own git infrastructure would have required setting up a new git.php.net server after determining the root cause of the compromise," Popov said.
"This would take a lot of time and disrupt PHP development in the meantime. A basic migration to GitHub could be performed much more quickly, as most repositories were already mirrored there.
"At this point, a lot of development was already going through GitHub anyway, and our own git infrastructure was mostly a security liability and complication to the development workflow, so it was not a hard decision to make the switch."
He said he was unaware at the time that git.php.net (intentionally) supported pushing changes not only via SSH (using the gitolite infrastructure and public key cryptography), but also via HTTPS.
"The latter did not use gitolite, and instead used git-http-backend behind Apache2 Digest authentication against the master.php.net user database," he said. "I'm not sure why password-based authentication was supported in the first place, as it is much less secure than pubkey authentication."
Popov provided an excerpt of the access logs, from which he said it could be determined that the commits were pushed using HTTPS and password-based authentication.
Of the commits, he observed: "It is notable that the attacker only makes a few guesses at usernames, and successfully authenticates once the correct username has been found. While we don't have any specific evidence for this, a possible explanation is that the user database of master.php.net has been leaked, although it is
unclear why the attacker would need to guess usernames in that case."
Popov said a number of changes had been made to beef up security:
- "master.php.net was migrated to a new system (running PHP 8) and renamed to main.php.net at the same time. Among other things, the new system supports TLS 1.2, which means you should no longer see TLS version warnings when accessing this site;
- "The implementation has been moved towards using parameterised queries, to be more confident that SQL injections cannot occur;
- "Passwords are now stored using bcrypt; and
- "Existing passwords were reset (use main.php.net/forgot.php to generate a new one)."
