Les premiers résultats de l'analyse d'un incident lié à l'identification de deux commits malveillants dans le référentiel Git d'un projet PHP avec une porte dérobée activée lors de l'envoi d'une requête avec un en-tête User Agent spécialement conçu ont été publiés. Au cours de l'étude des traces des activités des attaquants, il a été conclu que le serveur git.php.net lui-même, sur lequel se trouvait le référentiel git, n'avait pas été piraté, mais que la base de données avec les comptes des développeurs du projet avait été compromise. .
Il est possible que les attaquants aient pu télécharger la base de données des utilisateurs stockée dans le SGBD sur le serveur master.php.net. Le contenu de master.php.net a déjà été migré vers le nouveau serveur main.php.net installé à partir de zéro. Tous les mots de passe des développeurs utilisés pour accéder à l'infrastructure php.net ont été réinitialisés et le processus de modification a été lancé via un formulaire spécial de récupération de mot de passe. Les dépôts git.php.net et svn.php.net restent en lecture seule (le développement a été déplacé vers GitHub).
Après la découverte du premier commit malveillant effectué via le compte de Rasmus Lerdorf, le fondateur de PHP, on a supposé que son compte avait été piraté et Nikita Popov, l'un des principaux développeurs PHP, a annulé les modifications et bloqué les droits de commit pour le compte problématique. Après un certain temps, on s'est rendu compte que le blocage n'avait aucun sens, puisque sans vérification des commits à l'aide d'une signature numérique, tout participant ayant accès au référentiel php-src pouvait apporter une modification en substituant un nom d'auteur fictif.
Ensuite, les attaquants ont envoyé un commit malveillant au nom de Nikita lui-même. En analysant les logs du service gitolite, utilisé pour organiser l'accès aux référentiels, on a tenté de déterminer le participant qui a effectivement effectué les modifications. Malgré l'inclusion de la comptabilisation de tous les commits, il n'y avait aucune entrée dans le journal pour deux modifications malveillantes. Il est devenu clair qu'il y avait une compromission de l'infrastructure, puisque les commits étaient ajoutés directement, en contournant la connexion via gitolite.
Le serveur git.php.net a été rapidement désactivé et le référentiel principal a été transféré vers GitHub. Précipitamment, on a oublié que pour accéder au référentiel, en plus de SSH via gitolite, il existait une autre entrée qui permettait d'envoyer des commits via HTTPS. Dans ce cas, le backend git-http a été utilisé pour interagir avec Git et l'authentification a été effectuée à l'aide du serveur HTTP Apache2, qui a vérifié les informations d'identification en accédant à la base de données hébergée dans le SGBD sur le serveur master.php.net. La connexion était autorisée non seulement avec des clés, mais également avec un mot de passe habituel. L'analyse des journaux du serveur http a confirmé que des modifications malveillantes ont été ajoutées via HTTPS.
Lors de l'étude des journaux, il a été révélé que les attaquants ne se sont pas connectés du premier coup, mais ont d'abord essayé de trouver le nom du compte, mais après l'avoir identifié, ils se sont connectés du premier coup, c'est-à-dire ils connaissaient à l'avance les mots de passe de Rasmus et Nikita, mais ne connaissaient pas leurs identifiants. Si les attaquants ont réussi à accéder au SGBD, on ne sait pas pourquoi ils n'ont pas immédiatement utilisé le bon login qui y est spécifié. Cet écart n'a pas encore reçu d'explication fiable. Le piratage de master.php.net est considéré comme le scénario le plus probable, car ce serveur utilisait un code très ancien et un système d'exploitation obsolète, qui n'avait pas été mis à jour depuis longtemps et présentait des vulnérabilités non corrigées.
Les actions entreprises incluent la réinstallation de l'environnement serveur master.php.net et le transfert des scripts vers la nouvelle version de PHP 8. Le code permettant de travailler avec le SGBD a été modifié pour utiliser des requêtes paramétrées qui compliquent la substitution du code SQL. L'algorithme bcrypt est utilisé pour stocker les hachages de mots de passe dans la base de données (auparavant, les mots de passe étaient stockés à l'aide d'un hachage MD5 peu fiable). Les mots de passe existants sont réinitialisés et vous êtes invité à définir un nouveau mot de passe via le formulaire de récupération de mot de passe. Étant donné que l'accès aux référentiels git.php.net et svn.php.net via HTTPS était lié aux hachages MD5, il a été décidé de laisser git.php.net et svn.php.net en mode lecture seule, et également de déplacer tous les autres dans les référentiels d'extensions PECL sur GitHub, similaires au référentiel PHP principal.
Source: opennet.ru