Un pirate informatique a compromis le serveur utilisé pour distribuer le langage de programmation PHP et a ajouté une porte dérobée au code source qui aurait rendu les sites Web vulnérables à une prise de contrôle complète, ont déclaré des membres du projet open source. Deux mises à jour transmises au serveur PHP Git au cours du week-end du 27 mars ont ajouté une ligne qui, si elle était exécutée par un site Web alimenté par cette version détournée de PHP, aurait permis aux visiteurs sans autorisation d’exécuter le code de leur choix. Les commits malveillants ont donné au code la capacité d’injection de code aux visiteurs qui avaient le mot « zerodium » dans un en-tête HTTP.
Les commits ont été effectués dans le repo php-src sous les noms de compte de deux développeurs PHP bien connus, Rasmus Lerdorf et Nikita Popov.
Suite à la compromission, Popov a expliqué que les responsables de PHP avaient conclu que leur infrastructure Git autonome représentait un risque de sécurité inutile. En conséquence, ils ont décidé d’arrêter le serveur git.php.net et de faire de GitHub la source officielle des dépôts PHP. À l’avenir, toutes les modifications du code source PHP seront effectuées directement sur GitHub plutôt que sur git.php.net.
Le mainteneur de PHP Nikita Popov a publié une mise à jour concernant la façon dont le code source a été compromis et le code malveillant inséré, blâmant une fuite de base de données utilisateur plutôt qu’un problème avec le serveur lui-même.
L’équipe pensait à l’origine que le serveur hébergeant le référentiel avait subi une effraction, mais dans un nouveau message, Popov a déclaré : « Nous ne pensons plus que le serveur git.php.net a été compromis. Cependant, il est possible que la base de données des utilisateurs master.php.net ait fuité ». Aussi, master.php.net a été migré vers un nouveau système main.php.net.
Voici des détails donnés par Popov sur la progression de l’enquête :
« Lorsque le premier commit malveillant a été fait sous le nom de Rasmus, ma réaction initiale a été d’annuler le changement et de révoquer l’accès de commit pour le compte de Rasmus, en supposant qu’il s’agissait du piratage d’un compte individuel. Rétrospectivement, cette action n’avait pas vraiment de sens, car il n’y avait (à ce moment) aucune raison de croire que le push se produisait à travers le compte de Rasmus en particulier. Tout compte ayant accès au référentiel php-src aurait pu effectuer le push sous un faux nom.
« Lorsque le deuxième commit malveillant a été effectué sous mon propre nom, j’ai examiné les journaux de notre installation gitolite, afin de déterminer quel compte était réellement utilisé pour effectuer le push. Cependant, alors que tous les commits adjacents étaient pris en compte, aucune entrée git-receive-pack pour les deux commits malveillants n’était présente, ce qui signifie que ces deux commits ont complètement contourné l’infrastructure gitolite. Cela a été interprété comme une preuve probable d’une compromission du serveur.
« Peu de temps après, nous avons pris la décision d’arrêter git.php.net et de faire de GitHub notre hôte de référentiel principal à la place. Conserver notre propre infrastructure Git aurait nécessité la configuration d’un nouveau serveur git.php.net après avoir déterminé la cause première de la compromission. Cela prendrait beaucoup de temps et perturberait le développement PHP entre-temps. Une migration de base vers GitHub pourrait être effectuée beaucoup plus rapidement, car la plupart des référentiels y étaient déjà mis en miroir. À ce stade, une grande partie du développement passait déjà par GitHub de toute façon, et notre propre infrastructure Git était principalement un problème de sécurité et une complication pour le flux de travail de développement, donc ce n’était pas une décision difficile de faire le changement.
« Ce que je ne savais pas à ce moment-là, c’est que git.php.net supportait (intentionnellement) les changements de push non seulement via SSH (en utilisant l’infrastructure gitolite et la cryptographie à clé publique), mais aussi via HTTPS. Ce dernier n’utilisait pas gitolite, mais utilisait à la place git-http-backend derrière l’authentification Apache2 Digest par rapport à la base de données utilisateur master.php.net. Je ne sais pas pourquoi l’authentification par mot de passe a été prise en charge en premier lieu, car elle est beaucoup moins sécurisée que l’authentification par clé publique.
« Sur la base des journaux d’accès, nous pouvons déterminer que les validations ont bien été transmises en utilisant HTTPS et l’authentification par mot de passe.
« Il est à noter que l’attaquant ne fait que quelques suppositions sur les noms d’utilisateur et s’authentifie avec succès une fois que le nom d’utilisateur correct a été trouvé. Bien que nous n’ayons aucune preuve spécifique à ce sujet, une explication possible est que la base de données des utilisateurs de master.php.net a fuité, bien que l’on ne sache pas pourquoi l’attaquant aurait besoin de deviner les noms d’utilisateur dans ce cas ».
Les actions qui ont été prises
Les mesures prises à présent incluent la réinitialisation de tous les mots de passe et la modification du code pour utiliser des requêtes paramétrées, afin de se protéger contre les attaques par injection SQL.
L’utilisation de requêtes paramétrées est la meilleure pratique recommandée depuis de nombreuses années, et le fait que du code qui ne le fait pas fonctionne depuis si longtemps au cœur de l’infrastructure de code source PHP montre à quel point un code hérité non sécurisé peut persister pendant de longues périodes dans une organisation si elle fonctionne et ne pose pas de problèmes évidents.
Le système master.php.net, qui est utilisé pour l’authentification et diverses tâches de gestion, exécutait du code très ancien sur un très ancien système d’exploitation / version PHP, donc une sorte de vulnérabilité ne serait pas terriblement surprenante. Les mainteneurs ont apporté un certain nombre de modifications pour augmenter la sécurité de ce système :
Popov a expliqué : « auparavant, les mots de passe étaient stockés dans un format compatible avec l’authentification HTTP Digest (essentiellement un simple hachage md5), qui était nécessaire pour l’authentification HTTP sur git.php.net et svn.php.net. Comme git.php.net a été rendu en lecture seule à la suite de cet incident, nous avons décidé de rendre svn.php.net en lecture seule également, et ainsi supprimer le besoin de stocker les mots de passe dans un format non sécurisé. Seule une petite poignée d’extensions PECL utilisaient encore le serveur SVN ».
« Il est probable que certaines choses ne fonctionnent plus pendant la migration », a noté Popov qui a indiqué que tout problème observé devrait lui être signalé.
Source : Nikita Popov
