When the second malicious commit was made under my own name, I reviewed the
logs of our gitolite installation, in order to determine which account was
actually used to perform the push. However, while all adjacent commits were
accounted for, no git-receive-pack entries for the two malicious commits
were present, which means that these two commits bypassed the gitolite
infrastructure entirely. This was interpreted as likely evidence of a
server compromise.
This to me reads like a very good defense of git-receive transparency logs. It would make it any malicious pushes towards the repository tamper evident, along with any omissions, with who, when and where. I don’t know if anyone else has deployed it yet but kernel.org has done so for their repositories.
Assuming they did properly quote the values before inserting them into the SQL string (a big assumption), I find it actually much sadder they were apparently running on an outdated OS and PHP version and not using proper password hashing.
A lot of PHP’s infra are made of quite old applications before best practice was as common as it should be. People were too busy and no one was sponsoring the boring work of keeping these kinds of things up to date.
The master.php.net system, which is used for authentication and various
management tasks, was running very old code on a very old operating system
/ PHP version
Previously, passwords were stored in a format compatible with HTTP Digest
authentication (essentially a plain md5 hash),
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.
To me, guessing usernames is an indication for some kind of credential stuffing.
This to me reads like a very good defense of
git-receivetransparency logs. It would make it any malicious pushes towards the repository tamper evident, along with any omissions, with who, when and where. I don’t know if anyone else has deployed it yet but kernel.org has done so for their repositories.https://korg.docs.kernel.org/gitolite/transparency-log.html
https://git.kernel.org/pub/scm/infra/transparency-logs/gitolite/git/
I have some intentions to try do the same when Arch Linux moves from svn to git in the future.
I find it sad that this is done only now…
Assuming they did properly quote the values before inserting them into the SQL string (a big assumption), I find it actually much sadder they were apparently running on an outdated OS and PHP version and not using proper password hashing.
A lot of PHP’s infra are made of quite old applications before best practice was as common as it should be. People were too busy and no one was sponsoring the boring work of keeping these kinds of things up to date.
Whelp that tells a lot already.
To me, guessing usernames is an indication for some kind of credential stuffing.