{"id":1231,"date":"2021-04-08T23:27:35","date_gmt":"2021-04-08T21:27:35","guid":{"rendered":"https:\/\/parlonstechs.com\/all\/?p=1231"},"modified":"2021-04-08T23:27:36","modified_gmt":"2021-04-08T21:27:36","slug":"compromission-du-code-php-les-responsables-de-php-blament-desormais-une-fuite-de-la-base-de-donnees-utilisateurs-master-php-netplutot-quun-probleme-avec-le-serveur-lui-meme","status":"publish","type":"post","link":"https:\/\/parlonstechs.com\/all\/2021\/04\/08\/compromission-du-code-php-les-responsables-de-php-blament-desormais-une-fuite-de-la-base-de-donnees-utilisateurs-master-php-netplutot-quun-probleme-avec-le-serveur-lui-meme\/","title":{"rendered":"Compromission du code PHP : les responsables de PHP bl\u00e2ment d\u00e9sormais une fuite de la base de donn\u00e9es utilisateurs master.php.netPlut\u00f4t qu’un probl\u00e8me avec le serveur lui-m\u00eame"},"content":{"rendered":"\n
\"Les<\/figure>\n\n\n\n

Un pirate informatique a compromis le serveur utilis\u00e9 pour distribuer le langage de programmation PHP et a ajout\u00e9 une porte d\u00e9rob\u00e9e au code source qui aurait rendu les sites Web vuln\u00e9rables \u00e0 une prise de contr\u00f4le compl\u00e8te, ont d\u00e9clar\u00e9 des membres du projet open source. Deux mises \u00e0 jour transmises au serveur PHP Git au cours du week-end du 27 mars ont ajout\u00e9 une ligne qui, si elle \u00e9tait ex\u00e9cut\u00e9e par un site Web aliment\u00e9 par cette version d\u00e9tourn\u00e9e de PHP, aurait permis aux visiteurs sans autorisation d’ex\u00e9cuter le code de leur choix. Les commits malveillants ont donn\u00e9 au code la capacit\u00e9 d’injection de code aux visiteurs qui avaient le mot \u00ab\u00a0zerodium\u00a0\u00bb dans un en-t\u00eate HTTP.<\/strong><\/p>\n\n\n\n

\"\"\/<\/figure>\n\n\n\n

Les commits ont \u00e9t\u00e9 effectu\u00e9s dans le repo php-src sous les noms de compte de deux d\u00e9veloppeurs PHP bien connus, Rasmus Lerdorf et Nikita Popov.<\/p>\n\n\n\n

Suite \u00e0 la compromission, Popov a expliqu\u00e9 que les responsables de PHP avaient conclu que leur infrastructure Git autonome repr\u00e9sentait un risque de s\u00e9curit\u00e9 inutile. En cons\u00e9quence, ils ont d\u00e9cid\u00e9 d’arr\u00eater le serveur git.php.net et de faire de GitHub la source officielle des d\u00e9p\u00f4ts PHP. \u00c0 l’avenir, toutes les modifications du code source PHP seront effectu\u00e9es directement sur GitHub plut\u00f4t que sur git.php.net.<\/p>\n\n\n\n

Le mainteneur de PHP Nikita Popov a publi\u00e9 une mise \u00e0 jour concernant la fa\u00e7on dont le code source a \u00e9t\u00e9 compromis et le code malveillant ins\u00e9r\u00e9, bl\u00e2mant une fuite de base de donn\u00e9es utilisateur plut\u00f4t qu’un probl\u00e8me avec le serveur lui-m\u00eame.<\/p>\n\n\n\n

L’\u00e9quipe pensait \u00e0 l’origine que le serveur h\u00e9bergeant le r\u00e9f\u00e9rentiel avait subi une effraction, mais dans un nouveau message, Popov a d\u00e9clar\u00e9 : \u00ab Nous ne pensons plus que le serveur git.php.net a \u00e9t\u00e9 compromis. Cependant, il est possible que la base de donn\u00e9es des utilisateurs master.php.net ait fuit\u00e9 \u00bb. Aussi, master.php.net a \u00e9t\u00e9 migr\u00e9 vers un nouveau syst\u00e8me main.php.net.<\/p>\n\n\n\n

Voici des d\u00e9tails donn\u00e9s par Popov sur la progression de l’enqu\u00eate :<\/p>\n\n\n\n

\u00ab Lorsque le premier commit malveillant a \u00e9t\u00e9 fait sous le nom de Rasmus, ma r\u00e9action initiale a \u00e9t\u00e9 d’annuler le changement et de r\u00e9voquer l’acc\u00e8s de commit pour le compte de Rasmus, en supposant qu’il s’agissait du piratage d\u2019un compte individuel. R\u00e9trospectivement, cette action n’avait pas vraiment de sens, car il n’y avait (\u00e0 ce moment) aucune raison de croire que le push<\/em> se produisait \u00e0 travers le compte de Rasmus en particulier. Tout compte ayant acc\u00e8s au r\u00e9f\u00e9rentiel php-src aurait pu effectuer le push<\/em> sous un faux nom.<\/p>\n\n\n\n

\u00ab Lorsque le deuxi\u00e8me commit malveillant a \u00e9t\u00e9 effectu\u00e9 sous mon propre nom, j’ai examin\u00e9 les journaux de notre installation gitolite, afin de d\u00e9terminer quel compte \u00e9tait r\u00e9ellement utilis\u00e9 pour effectuer le push<\/em>. Cependant, alors que tous les commits adjacents \u00e9taient pris en compte, aucune entr\u00e9e git-receive-pack pour les deux commits malveillants n’\u00e9tait pr\u00e9sente, ce qui signifie que ces deux commits ont compl\u00e8tement contourn\u00e9 l’infrastructure gitolite. Cela a \u00e9t\u00e9 interpr\u00e9t\u00e9 comme une preuve probable d’une compromission du serveur.<\/p>\n\n\n\n

\u00ab Peu de temps apr\u00e8s, nous avons pris la d\u00e9cision d’arr\u00eater git.php.net et de faire de GitHub notre h\u00f4te de r\u00e9f\u00e9rentiel principal \u00e0 la place. Conserver notre propre infrastructure Git aurait n\u00e9cessit\u00e9 la configuration d’un nouveau serveur git.php.net apr\u00e8s avoir d\u00e9termin\u00e9 la cause premi\u00e8re de la compromission. Cela prendrait beaucoup de temps et perturberait le d\u00e9veloppement PHP entre-temps. Une migration de base vers GitHub pourrait \u00eatre effectu\u00e9e beaucoup plus rapidement, car la plupart des r\u00e9f\u00e9rentiels y \u00e9taient d\u00e9j\u00e0 mis en miroir. \u00c0 ce stade, une grande partie du d\u00e9veloppement passait d\u00e9j\u00e0 par GitHub de toute fa\u00e7on, et notre propre infrastructure Git \u00e9tait principalement un probl\u00e8me de s\u00e9curit\u00e9 et une complication pour le flux de travail de d\u00e9veloppement, donc ce n’\u00e9tait pas une d\u00e9cision difficile de faire le changement.<\/p>\n\n\n\n

\u00ab Ce que je ne savais pas \u00e0 ce moment-l\u00e0, c’est que git.php.net supportait (intentionnellement) les changements de push non seulement via SSH (en utilisant l’infrastructure gitolite et la cryptographie \u00e0 cl\u00e9 publique), mais aussi via HTTPS. Ce dernier n’utilisait pas gitolite, mais utilisait \u00e0 la place git-http-backend derri\u00e8re l’authentification Apache2 Digest par rapport \u00e0 la base de donn\u00e9es utilisateur master.php.net. Je ne sais pas pourquoi l’authentification par mot de passe a \u00e9t\u00e9 prise en charge en premier lieu, car elle est beaucoup moins s\u00e9curis\u00e9e que l’authentification par cl\u00e9 publique.<\/p>\n\n\n\n

\u00ab Sur la base des journaux d’acc\u00e8s, nous pouvons d\u00e9terminer que les validations ont bien \u00e9t\u00e9 transmises en utilisant HTTPS et l’authentification par mot de passe.<\/p>\n\n\n\n

\u00ab Il est \u00e0 noter que l’attaquant ne fait que quelques suppositions sur les noms d’utilisateur et s’authentifie avec succ\u00e8s une fois que le nom d’utilisateur correct a \u00e9t\u00e9 trouv\u00e9. Bien que nous n’ayons aucune preuve sp\u00e9cifique \u00e0 ce sujet, une explication possible est que la base de donn\u00e9es des utilisateurs de master.php.net a fuit\u00e9, bien que l’on ne sache pas pourquoi l’attaquant aurait besoin de deviner les noms d’utilisateur dans ce cas \u00bb.<\/p>\n\n\n\n

Les actions qui ont \u00e9t\u00e9 prises<\/strong><\/p>\n\n\n\n

Les mesures prises \u00e0 pr\u00e9sent incluent la r\u00e9initialisation de tous les mots de passe et la modification du code pour utiliser des requ\u00eates param\u00e9tr\u00e9es, afin de se prot\u00e9ger contre les attaques par injection SQL.<\/p>\n\n\n\n

L’utilisation de requ\u00eates param\u00e9tr\u00e9es est la meilleure pratique recommand\u00e9e depuis de nombreuses ann\u00e9es, et le fait que du code qui ne le fait pas fonctionne depuis si longtemps au c\u0153ur de l’infrastructure de code source PHP montre \u00e0 quel point un code h\u00e9rit\u00e9 non s\u00e9curis\u00e9 peut persister pendant de longues p\u00e9riodes dans une organisation si elle fonctionne et ne pose pas de probl\u00e8mes \u00e9vidents.<\/strong><\/p>\n\n\n\n

Le syst\u00e8me master.php.net, qui est utilis\u00e9 pour l’authentification et diverses t\u00e2ches de gestion, ex\u00e9cutait du code tr\u00e8s ancien sur un tr\u00e8s ancien syst\u00e8me d’exploitation \/ version PHP, donc une sorte de vuln\u00e9rabilit\u00e9 ne serait pas terriblement surprenante. Les mainteneurs ont apport\u00e9 un certain nombre de modifications pour augmenter la s\u00e9curit\u00e9 de ce syst\u00e8me :<\/p>\n\n\n\n