Tard dimanche soir, le 28 mars 2021, Nikita Popov, un committer PHP de base, a publié une déclaration indiquant que deux commits malveillants avaient été poussés vers le php-src référentiel git. Ces commits ont été poussés pour créer une porte dérobée qui aurait effectivement permis aux attaquants de réaliser l’exécution de code à distance via PHP et un en-tête HTTP.

L’exécution de code à distance permet d’émettre des commandes à un serveur à distance, ce qui permet aux attaquants de faire des choses comme créer de nouveaux fichiers, voler des données sur le serveur, supprimer des fichiers et essentiellement prendre le contrôle du serveur affecté par tout site Web alimenté par PHP.

Dans cet article, nous analysons le compromis et le code poussé vers le référentiel, tout en discutant de la manière dont cela affecte WordPress.

PHP est Open Source comme WordPress

PHP est un langage open source, ce qui, comme WordPress, signifie que tout individu peut contribuer à son développement.

«Quiconque programme en PHP peut être un membre contributeur de la communauté qui le développe et le déploie.»

Avant le compromis, 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 un système interne «Karma». Ce système de Karma donnait essentiellement aux contributeurs différents privilèges d’accès et leur permettait de contribuer directement à diverses ressources en fonction de leur Karma. Le Karma d’un contributeur devait également être explicitement demandé, et s’il était accordé, le contributeur se verrait attribuer un @php.net Compte.

En raison du compromis d’hier, le groupe PHP a déclaré qu’il s’éloignerait de son infrastructure git auto-hébergée et gérée actuelle et passerait à GitHub pour transformer ses référentiels actuellement «en miroir» en référentiels «canoniques», ce qui signifie que tous les modifications ultérieures seront suivies et gérées dans GitHub. Le groupe PHP a également annoncé qu’il allait s’éloigner du système Karma actuellement géré et exiger des contributeurs qu’ils fassent partie de l’organisation PHP sur GitHub. Ils exigeront également que l’authentification à deux facteurs soit activée sur tous les comptes avec accès en écriture pour lutter contre les compromissions de mot de passe qui pourraient conduire à des validations non autorisées dans le référentiel.

Analyse du compromis

Le samedi 27 mars 2021, le premier des deux commits a été poussé vers le référentiel. Le premier commit avait la description de Fixes minor typo. Signed-off-by: Rasmus Lerdorf <rasmus@lerdorf.com> par le commetteur rlerdorf. Ce compte appartient à Rasmus Lerdorf, co-auteur du langage PHP.

Le deuxième commit n’avait pas de description, cependant, le titre était Revert "Revert "[skip-ci] Fix typo"" qui a annulé le retour de la validation d’origine par rlerdorf, ce qui indique que l’attaquant a annulé la tentative initiale de Nikita de revenir sur cette porte dérobée. Ce commit a été conçu pour donner l’impression qu’il provenait du nikic Compte. Ce compte appartient à Nikita Popov, un contributeur très respecté du projet PHP.

L’utilisation de ces deux comptes individuels donnait l’impression que les commits provenaient de contributeurs et d’auteurs hautement fiables, ce qui a été fait dans le but de rendre les commits authentiques et réputés. L’attaquant s’est également assuré que les modifications semblaient être des corrections mineures pour corriger une faute de frappe afin de masquer ses intentions.

À première vue, il pourrait sembler que rlerdorf‘le sable nikicLes comptes de ont été compromis, cependant, le groupe PHP a explicitement déclaré qu’il pensait que les commits malveillants étaient le résultat d’un compromis au sein de leur infrastructure git plutôt que d’un compte individuel.

En plus d’ajouter du code à l’aide de committers de confiance, les attaquants ont également ajouté un commentaire dans les modifications qui indiquaient "REMOVETHIS: sold to zerodium, mid 2017" ce qui impliquait que l’exploit avait été vendu à Zerodium, une société d’acquisition d’exploit pour les vulnérabilités zero-day. Cela pouvait avoir pour but de tromper les critiques en leur faisant croire que le compromis était dû à une fuite de la société Zerodium ou à une vente potentielle de l’exploit à la société. Cependant, Chaouki Bekrar, le PDG de Zerodium, a publié une déclaration sur Twitter refusant toute implication dans les commits malveillants qui ont été poussés vers le référentiel.

Ce qui suit est une capture d’écran du commit qui semble provenir du rlerdorf Compte.

Ce qui suit est une capture d’écran du commit qui semble provenir du nikic Compte.

Le code est le même pour ces deux tentatives. Essentiellement, le code vérifie si l’en-tête HTTP de l’agent utilisateur personnalisé contient la chaîne «zerodium». Si PHP traitait une requête avec cet agent utilisateur, il exécuterait la fonction zend_eval_string qui pourrait être utilisé pour exécuter des commandes et réaliser l’exécution de code à distance. Bien que les commits soient assez simples, ils auraient pu entraîner d’énormes dégâts s’ils avaient été publiés dans une version de production de PHP, étant donné que PHP alimente environ 80% des sites Web utilisant la programmation côté serveur. Heureusement, ces commits malveillants ont été détectés assez rapidement et n’étaient que dans une version de développement de PHP.

Analyse des acteurs de la menace
Contrairement à la Le compromis SolarWinds nous l’avons vu en décembre 2020, cela semble avoir été le travail d’un individu, potentiellement un «script kiddie» qualifié, à la recherche de plaisir ou d’un simple «cybercriminel» qui aurait peut-être voulu essayer de vendre l’exploit si la version de PHP avait été mis en production sans que le code malveillant ne soit détecté.

En analysant le compromis, nous pouvons voir que la porte dérobée n’était pas très bien dissimulée, indiquant que l’attaquant pouvait s’attendre à se faire prendre, ou qu’il n’avait pas la compétence pour la dissimuler très bien. De plus, comme il s’agissait d’un engagement mineur avec très peu de dissimulation, il est très peu probable que ce soit le travail de plus d’un individu. Le manque de complexité et l’utilisation apparemment ironique de «zerodium» tout au long de la porte dérobée nous amène à croire que cette attaque peut avoir été réalisée comme une farce de haut niveau ou comme un moyen de simplement dire qu’ils l’ont fait.

Cela affecte-t-il WordPress?

Ce compromis n’affecte aucun site WordPress en production. Heureusement, les commits ont été détectés très rapidement et n’ont été actifs que quelques heures dans une branche de développement. Dans une déclaration publiée à Bleeping Computer, Nikita Popov a déclaré: «Les changements concernaient la branche de développement de PHP 8.1, qui devrait sortir à la fin de l’année», ce qui signifie que le code malveillant a été poussé vers une branche de PHP qui n’est pas en production. Ils ont également déclaré que «les modifications n’avaient pas été transformées en balises ou en artefacts de publication», indiquant que le code malveillant n’avait jamais été publié. Cela signifie que la version compromise de PHP n’a pas et n’atteindra jamais votre serveur.

La modification de GitHub empêchera-t-elle que cela se reproduise?

Le passage d’un référentiel auto-hébergé à GitHub ajoute des contrôles qui n’étaient pas disponibles auparavant et décharge une partie de la gestion de la sécurité impliquée dans l’auto-hébergement de leur propre infrastructure git qui devrait améliorer la posture de sécurité de la gestion git de l’organisation PHP. De plus, une exigence de vérification des committers lors de leur ajout à l’organisation PHP devrait ajouter un niveau de sécurité supplémentaire qui devrait empêcher que cela ne se reproduise à l’avenir.

Comme pour toutes les attaques de la chaîne d’approvisionnement, il existe certains risques pour toute base de code. Heureusement, le groupe PHP a réagi rapidement pour lutter contre ce compromis et a pris des mesures pour éviter que cela ne se reproduise à l’avenir, ce qui indique à quel point il prend la sécurité au sérieux.

La bonne nouvelle est que ces modifications malveillantes ont été détectées rapidement par la communauté PHP, et il n’y a pas de rapports de sites de production affectés par ce code malveillant. La nature open source de la communauté PHP offre le même type de protection que WordPress bénéficie également, garantissant que le code ou les activités anormales sont identifiés et gérés rapidement.

Conclusion

Dans l’article d’aujourd’hui, nous avons analysé le compromis PHP qui s’est produit au cours du week-end, vous fournissant des informations sur ce qui s’est exactement passé. Ce compromis ne devrait avoir aucun effet sur les sites WordPress car le code malveillant n’a jamais été mis en production ni contenu dans des balises ou des artefacts de publication. Au fur et à mesure que cette histoire évolue, nous continuerons à vous tenir au courant.



Source link