À la fin du mois dernier la nouvelle a éclaté qu'un pirate informatique avait compromis le serveur utilisé pour distribuer le langage de programmation PHP et ajouté une porte dérobée au code source Cela aurait laissé les sites Web vulnérables à une prise de contrôle complète, ont déclaré les membres du projet open source.
Le problème a été soulevé dans deux mises à jour envoyées au serveur PHP Git pendant le week-end du 27 mars au cours duquel ils ont ajouté une ligne qui, si elle était gérée par un site Web alimenté par cette version piratée de PHP, aurait permis à des visiteurs non autorisés d'exécuter le code de leur choix.
Les commits malveillants ont donné au code la possibilité d'injecter du code dans les visiteurs qui avaient le mot «zerodium» dans un en-tête HTTP. Les commits ont été faits dans le dépôt php-src sous les noms de compte de deux développeurs PHP bien connus, Rasmus Lerdorf et Nikita Popov.
Après les fiançailles, Popov a expliqué que les responsables de PHP ont conclu que leur infrastructure Git indépendant cela représentait un risque de sécurité inutile.
En conséquence, a décidé de fermer le serveur git.php.net et de faire de GitHub la source officielle à partir de référentiels PHP. À l'avenir, toutes les modifications apportées au code source PHP seront effectuées directement sur GitHub au lieu de git.php.net.
Le mainteneur de PHP Nikita Popov a publié une mise à jour sur la façon dont le code source a été compromis et un code malveillant a été inséré, accusant 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 été piraté, 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 de l'utilisateur master.php.net ait été divulguée ». De plus, master.php.net a été migré vers un nouveau système main.php.net.
Voici les détails que Popov a donnés sur l'avancement de l'enquête:
«Lorsque la première confirmation malveillante a été faite sous le nom de Rasmus, ma première réaction a été d'annuler le changement et de révoquer l'accès à la confirmation du compte de Rasmus, en supposant qu'il s'agissait d'un piratage de compte individuel. Avec le recul, cette action n'avait pas vraiment de sens, car aucune poussée ne se produisait à travers le compte de Rasmus en particulier. Tout compte ayant accès au référentiel php-src aurait pu soumettre sous un faux nom.
«Lorsque le deuxième commit malveillant a été effectué sous mon propre nom, j'ai regardé nos journaux d'installation gitolite pour déterminer quel compte était réellement utilisé pour soumettre. Cependant, même si tous les commits adjacents ont été pris en compte, il n'y avait pas d'entrées git-receive-pack pour les deux commits malveillants, 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.
Les actions qui ont maintenant été entreprises incluent la réinitialisation de tous les mots de passe et modifiez le code pour utiliser des requêtes paramétrées pour 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 fonctionne pas depuis si longtemps au cœur de l'infrastructure de code source PHP montre à quel point le code hérité n'est pas sécurisé dans une organisation s'il fonctionne. et ne pas causer de problèmes évidents.
Le système master.php.net, qui est utilisé pour l'authentification et diverses tâches d'administration, J'utilisais du code très ancien sur une très ancienne version / OS de PHP, donc une sorte de vulnérabilité ne serait pas très surprenante. Les responsables de la maintenance ont apporté un certain nombre de modifications pour accroître la sécurité de ce système:
- master.php.net a été migré vers un nouveau système (exécutant PHP 8) et main.php.net a été renommé en même temps. Entre autres choses, le nouveau système est compatible 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 garantir 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).
source: https://externals.io