Actualités

Un chercheur a utilisé une chaîne d’approvisionnement open source pour briser les géants de la technologie

Par Gabriel, le 12 février 2021 — 5 minutes de lecture
Un chercheur a utilisé une chaîne d'approvisionnement open source pour briser les géants de la technologie

Réaliser un piratage de la chaîne d’approvisionnement open source peut être plus simple que vous ne le pensez.

Le chercheur en sécurité Alex Birsan l’a démontré dans un nouvel article de recherche publié sur Medium Tuesday qui examinait une théorie: la confiance aveugle accordée aux packages open source peut-elle être exploitée par des acteurs malveillants? La réponse est apparue après avoir découvert un moyen d’amener les systèmes d’entreprise à télécharger du code malveillant en copiant ou en «squattant» simplement les noms de packages open source légitimes développés et utilisés en interne par diverses entreprises.

Selon l’article de recherche, Birsan a introduit des paquets malveillants dans les registres open source légitimes pour voir si les entreprises ont accidentellement mis à jour le logiciel et remplacé le vrai paquet privé par le faux. En faisant des recherches, en copiant les noms de fichiers et en téléchargeant le code, il a essentiellement pu pirater des géants de la technologie comme Apple et Microsoft.

Il a surnommé la vulnérabilité «confusion de dépendance».

La découverte a commencé l’été dernier lorsque Birsan et son collègue chercheur en sécurité Justin Gardner ont tenté de pirater PayPal pour une prime de bogue; Gardner a découvert un code source intéressant Node.js trouvé sur GitHub.

« Le code était destiné à une utilisation interne de PayPal et, dans son fichier package.json, semblait contenir un mélange de dépendances publiques et privées – des packages publics de npm, ainsi que des noms de packages non publics, probablement hébergés en interne par PayPal. Ces noms n’existaient pas sur le registre public npm à l’époque », a écrit Birsan.

À partir de là, il a testé la possibilité de télécharger sa propre version « malveillante » du package Node privé dans le registre NPM pour voir si PayPal téléchargerait par erreur sa version – même si le package Node original a été développé en interne. Birsan a trouvé que la technique fonctionnait et il pouvait exécuter du code arbitraire et exfiltrer les données des serveurs PayPal qui avaient installé son faux package NPM.

Birsan a ensuite répété la technique avec d’autres logiciels open source, notamment Python et Ruby et leurs registres respectifs, PyPI (Python Package Index) et RubyGems. L’étape suivante consistait à rechercher des packages privés développés en interne par les plus grandes entreprises du monde, notamment Apple, Microsoft, Tesla, Netflix et Yelp. Selon l’article de recherche, cette recherche a révélé que de nombreux autres noms de packages privés pour ces entreprises pouvaient être trouvés sur GitHub, ainsi que « à l’intérieur de packages internes qui avaient été publiés accidentellement – et même dans des messages sur divers forums Internet ».

« Cependant, de loin le meilleur endroit pour trouver des noms de paquetages privés s’est avéré être … à l’intérieur de fichiers JavaScript », a écrit Birsan. « Apparemment, il est assez courant que les fichiers package.json internes, qui contiennent les noms des dépendances des projets JavaScript, soient incorporés dans des fichiers de script publics pendant leur processus de construction, exposant les noms de packages internes. »

Impact sur les entreprises

Selon l’article de recherche, Birsan a détecté ce type de vulnérabilité au sein de plus de 35 organisations, y compris les entreprises mentionnées précédemment. «La grande majorité des entreprises concernées appartiennent à la catégorie des plus de 1000 employés, ce qui reflète très probablement la prévalence plus élevée de l’utilisation de la bibliothèque interne au sein des grandes organisations», a écrit Birsan.

La «confusion des dépendances» a un impact sur les entreprises car, souvent, le système exécutant le package open source ne sait pas quels fichiers sont internes et lesquels ne le sont pas. Par conséquent, il télécharge l’ensemble du package et lorsque la nouvelle version est disponible, il s’assure que tous les fichiers publics et privés sont les dépendances correctes. Birsan a déclaré que les systèmes d’entreprise acceptaient les derniers packages avec une confiance aveugle pour diverses raisons.

«Qu’il s’agisse d’erreurs ponctuelles commises par les développeurs sur leurs machines, de serveurs de build internes ou cloud mal configurés, ou de pipelines de développement systémiquement vulnérables, une chose était claire: squatter les noms de packages internes valides était une méthode presque infaillible pour entrer dans le les réseaux de certaines des plus grandes entreprises de technologie, obtenant l’exécution de code à distance et permettant éventuellement aux attaquants d’ajouter des portes dérobées pendant les builds », a écrit Birsan.

La sécurité de la chaîne d’approvisionnement pour les logiciels commerciaux et open source est devenue une préoccupation majeure à la suite de l’attaque de la chaîne d’approvisionnement de SolarWinds. Lors de cet incident, les acteurs des États-nations ont passé des mois à effectuer des reconnaissances avant de planter une porte dérobée dans les mises à jour logicielles de la plate-forme SolarWinds Orion, qui ont été fournies à des milliers de clients SolarWinds l’année dernière, y compris Microsoft.

Bien que Birsan ait mené cette recherche avant le piratage de SolarWinds, cela souligne une fois de plus l’importance de sécuriser la chaîne d’approvisionnement.

Gabriel

Gabriel

La tech va chaque jour plus vite et il peut-être difficile de suivre cette thématique. Grâce à mes articles, j'espère vous faire ressortir les sujets importants et intéressants afin de ne rien louper cette actualité toujours en pleine agitation.

Commentaires

Laisser un commentaire

Votre commentaire sera révisé par les administrateurs si besoin.