Support technique
Documentation
Connexion
Nous contacter
Attaques de la chaîne d'approvisionnement en matière de cybersécurité à l'initiative du propriétaire
Joao Correia
23 septembre 2022 - Évangéliste technique
Les attaques contre la chaîne d'approvisionnement se présentent sous toutes les formes et tous les aspects. Un exemple est la prise de contrôle de comptes légitimes pour déployer un code malveillant dans des bibliothèques largement utilisées. Un autre exemple est le déploiement de modifications pendant la compilation grâce à des outils malveillants.
Nous pourrions continuer - pensez au contenu mal étiqueté destiné à tromper les utilisateurs imprudents, ou aux fichiers supplémentaires ajoutés qui modifient le comportement des applications.
Cependant, une autre attaque particulièrement malveillante de la chaîne d'approvisionnement, perpétrée par le véritable propriétaire du code ou le développeur original derrière le code, est en train d'apparaître - et elle s'avère incroyablement perturbatrice.
Une nouvelle menace dangereuse pour la chaîne d'approvisionnement
Ce vecteur d'attaque est apparu au début de l'année 2022, lorsque des développeurs se sont rendu compte que deux bibliothèques très largement utilisées ("faker.js" et "colors.js") avaient été modifiées pour inclure du code sans rapport avec l'intention initiale de ces bibliothèques.
Pire encore, le code "supplémentaire" cassait les applications qui en dépendaient en créant une boucle infinie dans le code. Le code de ces bibliothèques étant ouvert et hébergé dans des dépôts publics, il a été possible d'analyser les commits et d'identifier qui avait ajouté ce code malveillant.
La communauté des développeurs a été déconcertée de constater que le code avait été ajouté par le développeur original.
Apparemment mécontent de ne pas pouvoir monétiser le temps qu'il a consacré au développement du code, et de voir que celui-ci était utilisé par de nombreux développeurs, le développeur a décidé de saboter ses propres bibliothèques.
Un sabotage qui touche des millions de personnes
Cela peut sembler n'être rien - c'est le code du développeur, après tout. Mais pour replacer les choses dans leur contexte, les bibliothèques concernées ont fait l'objet d'un total de 25 millions de téléchargements... non pas pendant leur durée de vie utile, mais chaque semaine.
La politique de l'open source et la façon dont l'open source est monétisé - y compris les mesures qu'un développeur peut prendre pour y remédier - est vraiment un article entier en soi, et les opinions peuvent varier énormément. Mais, pour des raisons évidentes, le contrecoup de l'altération par un développeur d'un code utilisé par des millions de personnes a été immense.
En fait, GitHub, où le code est hébergé, a suspendu le compte du développeur (bien que GitHub l'ait rétabli quelques jours plus tard). Le développeur affirmait avoir des centaines de projets, pas seulement dans ces deux bibliothèques, mais bien sûr, les deux bibliothèques en question ont un public immense.
Une action malveillante ayant un impact réel sur les développeurs
Les bibliothèques ont fini par être interdites de distribution, le code a été annulé et de nouvelles bibliothèques ont été créées pour remplacer la fonctionnalité.
Pour les développeurs utilisant ces bibliothèques, cela signifiait un travail supplémentaire de vérification du code, de mise à jour et de modification des dépendances. Les actions d'un individu ont entraîné des tests supplémentaires et toutes les autres tâches nécessaires pour garantir la bonne exécution du logiciel. D'innombrables heures de travail ont été consacrées à la réponse à un acteur malveillant, heures qui auraient pu être utilisées de manière plus productive ailleurs.
C'était une action délibérée d'un seul développeur qui a affecté des milliers d'applications. Mais il y a d'autres situations où ce n'est pas délibéré, mais cela vient néanmoins de la source, le développeur. Ou, du moins, du compte du développeur.
Un serveur git compromis
Quelques mois plus tard, en mars, le serveur git contenant le code du langage de programmation de serveur web le plus populaire, PHP, a été compromis. Oui, vous avez bien lu, le dépôt git officiel de l'équipe PHP a été altéré.
Les attaquants ont réussi à modifier le code source de PHP 8.1 et à introduire des commits malveillants dans le système sous le couvert de "corrections de fautes de frappe", qui cachaient un code malveillant qui, s'il était intégré avec succès dans la base de code PHP, se diffuserait dans des millions de déploiements PHP et créerait une porte dérobée dans des millions de sites Web et de services Internet écrits en PHP.
Comment cela s'est-il produit ? Git est un outil formidable, mais il présente un défaut : il est possible de signer des engagements de code en se faisant passer pour quelqu'un d'autre. Une autre personne examinant les modifications du code peut alors être amenée à penser que les modifications ont été faites par, disons, le développeur principal du projet.
Le résultat est que tout examen peut reposer en grande partie sur la confiance - la confiance que la bonne personne a édité le code et apporté des modifications acceptables. Les examens peuvent donc être moins rigoureux, ce qui permet à un code malveillant de passer sous le radar sans être détecté.
Et il ne s'agit pas seulement de PHP...
Le code malveillant ajouté à PHP 8.1 a été détecté et les modifications ont été rejetées, de sorte que le code ne s'est jamais retrouvé dans la base de code PHP que des millions de personnes utilisent chaque jour. Pourtant, le problème qu'il a créé a conduit l'équipe à passer de son propre dépôt git à GitHub.
En mai, la bibliothèque ctx de Python de Python et la bibliothèque phpass de PHP ont toutes deux été compromises lors d'une opération qui, selon l'attaquant, était simplement "à des fins de recherche"une affirmation qu'il a été impossible de prouver ou d'infirmer.
Dans une série d'étapes alambiquées, l'attaquant a pris le contrôle des dépôts de ces bibliothèques en usurpant l'identité des développeurs originaux - en prenant des adresses électroniques qui n'existaient plus, puis en demandant la récupération des mots de passe pour ces comptes, et en créant de faux domaines pour valider la propriété des domaines expirés.
Les hôtes du référentiel ont ainsi été trompés pour que l'attaquant, qui se faisait passer pour le développeur original ayant perdu l'accès à son propre code, puisse administrer le référentiel. L'attaquant a ensuite inclus du code de vol d'informations d'identification dans ces bibliothèques, y compris des informations d'identification AWS. Il était également impossible de vérifier les affirmations de l'attaquant selon lesquelles toutes les informations d'identification recueillies avaient été supprimées.
Les acteurs de la menace investissent massivement dans les attaques visant la chaîne d'approvisionnement
Ces exemples mettent en lumière la nécessité de réagir rapidement aux menaces qui pèsent sur la chaîne d'approvisionnement en codes. La menace qui pèse sur les chaînes d'approvisionnement en code n'est pas nouvelle en soi. Cependant, les attaques auxquelles nous assistons ces derniers temps sont différentes car le temps investi va bien au-delà du délai habituel d'exécution des attaques, qui est de quelques jours ou semaines.
Les derniers exemples de compromissions impliquent un temps énorme pour exécuter la compromission. À bien des égards, il s'agit d'un exemple beaucoup plus grave d'attaque de la chaîne d'approvisionnement, frappant au cœur d'un code qui est - aveuglément - utilisé par des millions d'organisations dans le monde.
Autre point qui rend l'affaire plus sérieuse : il faut tenir compte de la grande quantité de travail nécessaire pour changer les versions des bibliothèques afin de répondre à un compromis. Les nouvelles bibliothèques nécessitent un temps considérable pour être exécutées, testées et déployées chaque fois qu'un tel événement se produit.
C'est là qu'un service comme Support étendu du cycle de vie pour PHP et Extended Lifecycle pour Python peuvent être utiles. TuxCare fournit rapidement des mises à jour de sécurité pour les problèmes au niveau du langage et pour les modules associés, ce qui permet de combler les failles créées par certaines des attaques que nous avons décrites plus rapidement et avec moins de travail que les autres solutions.
