Une porte dérobée que les chercheurs ont trouvée cachée dans un code open source ciblant quatre entreprises allemandes était l’œuvre d’un testeur d’intrusion professionnel. Le testeur vérifiait la résilience des clients contre une nouvelle classe d’attaques qui exploite les référentiels publics utilisés par des millions de projets logiciels dans le monde. Mais ça aurait pu être mauvais. Très mauvais.
La confusion des dépendances est une nouvelle forme d’attaque de la chaîne d’approvisionnement qui est apparue au premier plan en mars 2021, lorsqu’un chercheur a démontré qu’il pouvait l’utiliser pour exécuter du code non autorisé de son choix sur des réseaux appartenant à Apple, Microsoft et 33 autres sociétés. Le chercheur, Alex Birsan, a reçu 130 000 $ en primes de bugs et en crédits pour avoir développé la nouvelle forme d’attaque.
Quelques semaines plus tard, un autre chercheur a découvert des preuves montrant qu’Amazon, Slack, Lyft, Zillow et d’autres sociétés avaient été la cible d’attaques utilisant la même technique. La diffusion de plus de 200 packages malveillants dans la nature a indiqué que l’attaque conçue par Birsan a séduit les acteurs de la menace du monde réel.
Ce n’est pas la dépendance que vous recherchez
La confusion des dépendances exploite la dépendance des entreprises vis-à-vis du code open source disponible à partir de référentiels tels que NPM, PyPI ou RubyGems. Dans certains cas, le logiciel de l’entreprise se connectera automatiquement à ces sources pour récupérer les bibliothèques de code nécessaires au fonctionnement de l’application. D’autres fois, les développeurs stockent ces soi-disant dépendances en interne. Comme son nom l’indique, la confusion des dépendances fonctionne en incitant une cible à télécharger la bibliothèque depuis le mauvais endroit, une source publique plutôt qu’une source interne.
Pour y parvenir, les pirates parcourent le code JavaScript, les packages internes publiés accidentellement et d’autres sources pour découvrir les noms des dépendances de code stockées en interne par l’organisation ciblée. Les pirates créent alors une dépendance malveillante et l’hébergent sur l’un des référentiels publics. En donnant au paquet malveillant le même nom que le paquet interne et en utilisant un numéro de version supérieur, certaines cibles le téléchargeront automatiquement et mettront à jour le logiciel. Avec cela, les pirates ont réussi à infecter la chaîne d’approvisionnement logicielle sur laquelle les cibles s’appuient et à amener la cible ou ses utilisateurs à exécuter un code malveillant.
Publicité
Au cours des dernières semaines, des chercheurs de deux sociétés de sécurité ont suivi les dépendances de code qui utilisaient des noms de mainteneur et de paquet qui ressemblaient étroitement à ceux qui pourraient être utilisés par quatre entreprises allemandes dans les secteurs des médias, de la logistique et de l’industrie. Les noms de paquet et les noms de responsable correspondants étaient :
- bertelsmannnpm ; bertelsmannnpm@protonmail.com
- boschnodemodules ; boschnodemodules@protonmail.com
- stihlnodemodules ; stihlnodemodules@protonmail.com
- dbschenkernpm ; dbschenkernpm@protonmail.com
Sur la base de ces noms, les chercheurs ont déduit que les packages étaient conçus pour cibler Bertelsmann, Bosch, Stihl et DB Schenk.
À l’intérieur de chaque package se trouvait un code obscurci qui obtenait le nom d’utilisateur, le nom d’hôte et le contenu des fichiers de répertoires spécifiques de la cible et les exfiltrait via des connexions HTTPS et DNS. Le package malveillant installerait alors une porte dérobée qui se rapporterait à un serveur de commande et de contrôle exploité par l’attaquant pour récupérer des instructions, notamment :
- Télécharger un fichier depuis le serveur C2
- Charger un fichier sur le serveur C2
- Évaluer le code Javascript arbitraire
- Exécuter un binaire local
- Supprimer et terminer le processus
- Enregistrez la porte dérobée sur le serveur C2
Les chercheurs de JFrog et ReversingLabs, les deux sociétés de sécurité qui ont découvert indépendamment les packages malveillants, ont rapidement découvert qu’ils faisaient partie de la même famille que les packages malveillants que la société de sécurité Snyk a découverts le mois dernier. Bien que Snyk ait été le premier à repérer les fichiers, il ne disposait pas de suffisamment d’informations pour identifier la cible visée.
Rebondissement
Mercredi, quelques heures seulement avant que JFrog et ReversingLabs ne publient des blogs ici et ici, une boutique de tests d’intrusion nommée Code White s’est attribuée le mérite des packages.
“Tnx pour votre excellente analyse”, a déclaré la société dans un tweet qui s’adressait à Snyk et citait son article de blog du mois dernier. “Et ne vous inquiétez pas, “l’acteur malveillant” est l’un de nos stagiaires 😎 qui a été chargé de rechercher la confusion des dépendances dans le cadre de nos simulations d’attaques continues pour les clients. Pour clarifier vos questions : nous essayons d’imiter des acteurs de menace réalistes pour des clients dédiés dans le cadre de notre service de renseignement de sécurité et nous avons apporté notre « propre » gestionnaire de paquets qui prend en charge le fil et le npm. »
@snyksec Tnx pour votre excellente analyse sur https://t.co/UoshhgaDgx et ne vous inquiétez pas, “l’acteur malveillant” est l’un de nos stagiaires 😎 qui a été chargé de rechercher la confusion des dépendances dans le cadre de nos simulations d’attaques continues pour les clients . (1/2)
— Code White GmbH (@codewhitesec) 10 mai 2022
Dans un message direct, le PDG de Code White, David Elze, a déclaré que le stagiaire de l’entreprise avait créé et publié les packages dans le cadre d’un exercice de test d’intrusion légitime explicitement autorisé par les entreprises concernées.
Publicité
“Nous ne divulguons pas les noms de nos clients, mais plus précisément, je peux confirmer que nous sommes légalement engagés par les sociétés concernées et agissons en leur nom pour simuler ces scénarios d’attaque réalistes”, a déclaré Elze.
L’implication de Code White signifie que les attaques de confusion de dépendance découvertes par Snyk et observées plus tard par JFrog et ReversingLabs n’étaient pas un signe que les exploits réels de ce vecteur se multiplient. Pourtant, ce serait une erreur de penser que cette classe d’attaque n’est jamais utilisée dans la nature et ne le sera plus.
En mars, la société de sécurité Sonatype a découvert des packages malveillants publiés sur npm qui ciblaient Amazon, Slack, Lyft et Zillow. Ces packages ne contenaient aucune clause de non-responsabilité indiquant qu’ils faisaient partie d’un programme de primes de bogues ou d’un exercice bénin de preuve de concept. De plus, les packages ont été programmés pour exfiltrer les informations sensibles des utilisateurs, y compris l’historique de bash et le contenu de /etc/shadow, le répertoire dans lequel les données de mot de passe des utilisateurs Linux sont stockées. Dans certains cas, les packages ouvraient également un shell inversé.
JFrog a également repéré des attaques malveillantes dans la nature, notamment la présence mentionnée précédemment de plus de 200 packages sur npm pour divers projets Azure qui ont volé des informations personnelles sur les ordinateurs des développeurs.
Cela signifie que même si cette dernière découverte était une fausse alerte, des attaques malveillantes de confusion de dépendance se produisent dans la nature. Compte tenu des conséquences désastreuses qui pourraient découler d’un succès, les organisations devraient consacrer du temps à tester leurs systèmes ou utiliser les services d’entreprises comme Snyk, JFrog, ReversingLabs ou Sonatype, qui surveillent toutes les vulnérabilités et les exploits des écosystèmes open source.
