Il s'agit du premier épisode d'une série d'articles sur les types d'attaques de la chaîne d'approvisionnement logicielle les plus répandus : ceux qui utilisent (abusivement) un registre public de composants logiciels, destinés à projets open source pour télécharger des artefacts qui pourraient être partagés avec d'autres utilisateurs. Lorsque les méchants y publient des logiciels malveillants, en utilisant le registre comme moyen de distribution de logiciels malveillants, nous sommes confrontés à une attaque de la chaîne d'approvisionnement lorsque les organisations victimes installent ou exécutent le composant logiciel infecté.
Pour simplifier la discussion, nous parlerons de progiciels:, composants sous forme emballée produits par des tiers. Cela inclut non seulement les composants utilisés par les gestionnaires de packages comme NPM ou Poetry, mais également composants du système d'exploitation y compris les bibliothèques et les binaires exécutables, images de conteneurs, et des machines virtuelles, ou extensions d'outils Pour les outils de développement, de compilation et de déploiement. Nous avons vu des paquets malveillants partout. Les cybercriminels n'y voient pas d'inconvénient : ils apprécient les alternatives offertes par les infrastructures logicielles modernes et utilisent le registre et l'outil qui correspondent le mieux à leurs objectifs. N'oubliez donc pas que les paquets logiciels sont un raccourci pour les images de conteneurs, les paquets binaires, les dépôts open source et les extensions ou plugins de toutes sortes (IDE, CI/CD systèmes, outils de construction). Tous sont régulièrement attaqués.
La série comportera 5 épisodes :
- Quel est le problème avec les packages Open Source ? C'est le thème de cet article. Pourquoi les criminels de toutes sortes publient-ils des packages malveillants ? Pourquoi devrais-je m’inquiéter ?
- Anatomie des packages malveillants : quelles sont les tendances ? Dans cet épisode, nous nous concentrons sur la menace que nous surveillons avec notre système MEW, jour après jour. Avec un bruit de fond important dû à un grand nombre de paquets malveillants utilisant le typosquatting ou la confusion des dépendances, un plus petit pourcentage d'attaques est beaucoup plus insidieuse et présente un plus grand risque. Comment le comportement des mauvais acteurs concernant le système d’exploitation a-t-il changé dans un passé récent ? Quels sont les chiffres ? Quelles sont les tactiques, techniques et procédures utilisées, ainsi que les actions nuisibles observées ?
- Protection contre les packages malveillants Open Source : ce qui ne fonctionne (pas)La plupart des professionnels de la sécurité ont des idées sur la façon de gérer cette menace. Nous avons entendu des responsables de la sécurité affirmer sans hésitation que SCA Les outils vous indiquent déjà si une version de package est malveillante. Ils utilisent également des composants logiciels connus et hautement évalués, où tout logiciel malveillant serait rapidement détecté et supprimé. Ils utilisent des versions mineures/correctifs ouvertes pour obtenir automatiquement des correctifs de vulnérabilités, ce qui constitue la méthode recommandée pour réduire les risques liés aux dépendances open source, conformément au principe « correctif précoce, correctif fréquent ». Dans cet épisode, nous examinerons pourquoi ces idées fausses sont erronées et comment elles contribuent à la popularité de ce mécanisme d'attaque et à un risque considérable pour les organisations. Nous conclurons par ce qui fonctionne et quels sont les efforts et les ressources nécessaires.
- Packages malveillants open source : l'approche Xygeni. Dans cet épisode, nous présentons la stratégie que nous suivons chez Xygeni pour notre système Malware Early Warning (MEW). Comment ce système à plusieurs étapes fonctionne-t-il en temps réel lorsqu'une nouvelle version du package est publiée, comment les preuves sont capturées à partir de différentes sources, comment le tri est effectué, quels critères de classification suivons-nous et pourquoi une analyse manuelle est encore nécessaire pour confirmer la nature d'un package candidat malveillant ? Comment les commentaires de nos équipes internes et du registre aident le système à tirer les leçons des preuves recueillies antérieurement afin de réduire au minimum les faux positifs. Nous et nous expliquerons comment nous aidons NPM, GitHub, PyPI et d'autres infrastructures clés des écosystèmes open source à réduire le temps d'attente..
- Exploiter l'Open Source : à quoi s'attendre des méchants. La série se termine en se concentrant sur les actions les plus récentes adoptées par les adversaires pour rendre les attaques plus furtives, plus difficiles à détecter, plus ciblées contre des secteurs spécifiques et pour tirer davantage d'avantages de cette classe d'attaques. Les attaques de ransomware seront-elles lancées à l’aide de ce véhicule ? Comment les méchants exploitent-ils les outils d’IA pour diffuser des packages malveillants plus sophistiqués ? Les projets les plus populaires sont-ils en danger ? Il s’agit de donner aux lecteurs une idée de cette course aux armements et de ce à quoi s’attendre à court terme (second semestre 2024) et à moyen terme (2025). Nous apprendrons comment des attaques comme la récente Porte dérobée XZ-Utils, ou l'attaque des vivants de la terre contre constructeur d'électrons en mars 2024 montrent qu’il faut rester vigilant sur l’évolution des adversaires.
Ouvrons la scène avec le premier épisode : que se passe-t-il avec les packages open source malveillants ?
Quel est le problème avec les packages Open Source ?
Ces dernières années, des malfaiteurs de toutes sortes ont utilisé des registres de logiciels open source pour livrer des comportements malveillants. Ces activités sont aussi anciennes que l’open source, mais leur fréquence a explosé au cours des trois dernières années.
Publication de composants malveillants dans des registres publics (attaques basées sur les dépendances) est une guérilla asymétrique que les acteurs malveillants utilisent pour distribuer des logiciels malveillants, en tirant parti de la confiance que les organisations accordent aux composants open source provenant de développeurs inconnus (rappelez-vous le dépendance xkcd bande dessinée?). Parce que vous faites confiance aux packages et que cela ne vous dérange pas de vérifier manuellement le contenu des packages et leurs dépendances, ces attaques sont extraordinairement efficaces. Et l’asymétrie vient du fait qu’ils peuvent être largement automatisés et que les méchants n’ont pas besoin d’interagir directement avec la victime. Il leur suffit de télécharger le package dans le registre public et de le laisser partir.
Colis malveillants a augmenté d'un facteur 6x en 2022, et a continué de croître d'un facteur 2.5 en 2023. L'année dernière, pas moins de 245,000 2021 packages malveillants ont été détectés, un chiffre qui fait plus que doubler le nombre total des années précédentes combinées. C'est une croissance exponentielle ! Des suppressions de packages en tant que logiciels malveillants confirmés par centaines en 2022 et par milliers en 2023, nous avons constaté beaucoup plus de « bruit » de fond en XNUMX, avec un rythme similaire pour cette année. Et cachées dans ce contexte provoqué par des cybercriminels peu avertis suivant la « voie de la moindre résistance », une minorité d’attaques très médiatisées ont fait la une des journaux, même dans les médias grand public.
Pourquoi est-ce un problème d’une telle ampleur ? Il y a un excès de confiance partout dans la chaîne. Les logiciels open source sont distribués avec leur code source et publiés sous une licence donnée. Oui, n’importe qui peut inspecter le code source ; mais qui le fait en général ? Qui, après avoir vérifié que le logiciel ne contient aucun logiciel malveillant, construit le logiciel à partir des sources ? Qui, avant de transmettre le composant packagé (également appelé paquet) en aval du gestionnaire de packages ou de l'outil de build, s'assure que le package n'est pas criblé de malware et correspond au code source supposé dont il devrait provenir ?
Pourquoi l’infrastructure permet-elle des attaques aussi faciles ?
Registres de paquets sont ouverts, nécessitant souvent une vérification minimale de l’identité de l’éditeur. « Tout le monde est invité à publier son logiciel ici ! » La barre pour les attaquants est placée bas : ils utilisent des adresses e-mail jetables et des comptes GitHubgithub jetables pour créer des centaines de packages malveillants dans le cadre de courtes campagnes de type phishing. Seules les applications ciblées nécessitent une sophistication plus élevée : nous avons même vu créer un référentiel de sources GitHub crédible avec de nombreuses étoiles et commits de plusieurs faux contributeurs et d’autres mesures de popularité et de maintenance. Obtenir les observateurs d'étoiles et la réputation des fausses contributions n'est pas difficile à automatiser. Nous avons constaté des abus sur les infrastructures logicielles ouvertes de toutes sortes, et pas seulement sur les logiciels malveillants, comme le incident du protocole du thé.
Les gestionnaires de packages ont été conçus pour la facilité d'utilisation et non pour la sécurité. Ils peuvent exécuter des scripts de pré-installation et de post-installation (il est parfois nécessaire de compiler du code natif pour une bibliothèque). Aussi, Gestionnaires de paquets installez des packages à partir de plusieurs sources, et parfois la valeur par défaut consiste à utiliser des registres publics. Ils n'ont pas vérifié l'incompatibilité entre les métadonnées de la demande de publication et les métadonnées du package lui-même.
Les dépendances sont imbriquées et forment un graphique. Dans certains écosystèmes comme Node (JavaScript), les dépendances à petite granularité s'accumulent par centaines ou par milliers. Une chose est d'avoir un contrôle strict sur les dépendances directes déclarées par mes projets logiciels, mais dépendances transitives sont plus difficiles à contrôler. L'open source a suivi « les amis de mes amis sont mes amis ». La fraternité est la norme dans l’Extrême-Orient sauvage ! Les acteurs de la menace le savent et cachent profondément leurs comportements malveillants dans des dépendances obscures et souvent inconnues. Ce fut le cas du flux d'événements incident visant le Portefeuille Copay.
C’est ainsi que fonctionnaient les logiciels open source depuis leur création. Cela ne changera pas grand-chose. Certains registres de packages exigent au mieux une authentification à deux facteurs, et souvent uniquement pour les packages les plus populaires. Certains registres fournissent des étendues, un espace de noms appartenant à une organisation approuvée, mais tragiquement d'autres ne le prennent pas en charge (PyPI) ou le rendent facultatif (NPM). Il est intéressant de noter que même un schéma de dépistage simple (basé sur le contrôle du référentiel/organisation DNS ou GitHub correspondant à l'ID de groupe) et en faisant Signatures PGP obligatoires pour tous les artefacts, à l'exception des sommes de contrôle, supprime la plupart du « bruit », des packages malveillants de type typosquatting, et limite une grande partie des dépendance confusion. Des attaques sophistiquées sont possibles mais beaucoup plus difficiles, avec seulement quelques-unes comme la com.github.codingandcoding:maven-compiler-plugin connu pour Maven Central. Et tous les registres maven ne suivent pas les mêmes pratiques !
Les contrôles de sécurité sur les gestionnaires de packages peuvent alourdir mais n'empêchent pas les attaques de dépendances. Le problème avec l'authentification multifacteur est que pour l'automatisation, des informations d'identification dérivées telles que des jetons d'accès ou des clés APIapi sont générées pour les comptes à utiliser dans les appels APIapi effectués à partir de scripts d'automatisation, sans qu'aucun utilisateur interactif de soutien ne fournisse un deuxième facteur. MFA est efficace pour protéger les comptes d'utilisateurs contre les fuites de mots de passe, mais les jetons d'accès ou les clés APIapi générés doivent être protégés lorsqu'ils sont actifs, sinon leur propriétaire sera usurpé par les adversaires. Une grande partie des campagnes de chaîne d'approvisionnement basées sur des packages commencent par une clé/un jeton divulgué. Rappelez-vous simplement des incidents comme Ledger, 3CX, et bien d’autres encore, où des informations d’identification non interactives ont été exfiltrées pour la première fois lors d’une intrusion préliminaire au lancement de l’attaque de la chaîne d’approvisionnement.
La réponse apportée à cette menace n'a pas été suffisamment vigoureuse. Dans le troisième épisode, nous nous concentrerons sur ce qui a fonctionné et ce qui a échoué lamentablement. L'industrie doit travailler collectivement sur la question. standards, processus, formation et outils pour atténuer les risques pour les chaînes d'approvisionnement mondiales. Ce problème ne peut être résolu par une seule organisation.
Pour terminer cette section, le malentendu crucial : nous parlons de malveillant des paquets, pas vulnérable ceux. Les vulnérabilités proviennent d’erreurs de conception ou de codage, introduites accidentellement, sans mauvaise intention. Les vulnérabilités peuvent être exploitées, mais beaucoup ne le sont pas. Les packages malveillants sont toujours intentionnels et leur exploitabilité est de 100 % s'ils sont exécutés. Aucun risque comparable ! Ainsi il est paradoxal de voir combien d'efforts sont déployés pour détecter et atténuer les vulnérabilités, et l'absence de mesures équivalentes pour les composants malveillants.
« Nous prenons la sécurité au sérieux »
Imaginons l'habitude Société Acmé. Acme, l'un des principaux fournisseurs de WileCoyote.com, fait appel à la plupart de ses logiciels provenant de tiers, avec plus de 80 % de projets open source. Ils produisent des logiciels à usage interne, mais ils fournissent également des logiciels à leurs partenaires, fournisseurs et clients/utilisateurs finaux. Acme dispose de logiciels écrits en Go, JavaScript, Java, C# et Python, et exécute la plupart de ses logiciels sur le cloud, sous des clusters Kuberneteskubernetes. Acme crée ses images personnalisées à partir d'images de base extraites de Docker Hub et d'autres registres. Et ils partagent également quelques bibliothèques, packages et images de conteneurs dans des registres publics.
Acme prend la sécurité au sérieux. Ils sont assez conscients du problème de open source security, et le risque qu’il comporte. Tous les développeurs, gestionnaires système et ingénieurs DevOpsdevops utilisent ces jolies petites clés cryptographiques comme authentification à deuxième facteur. Tous commitles dépôts de code sont signés, la protection des branches est activée avec des revues de code obligatoires, CI/CD Verrouillé, les secrets sont stockés dans un coffre secret et doté d'un registre interne reflétant partiellement les registres externes où seuls les composants autorisés et autorisés sont stockés. Les logiciels développés par Acme doivent impérativement utiliser les dépendances tierces de ce registre.
La plupart des organisations correspondent probablement à ce profil. Cher lecteur, le vôtre vous convient certainement si vous êtes déjà là, n'est-ce pas ?
Puis un jour malheureux, un important développeur frontend à Acme a couru npm installer acme-cute-lib, en oubliant que @acme/cute-lib était la bonne dépendance. L’erreur exacte n’a pas d’importance, beaucoup de choses peuvent mal tourner même si l’on assume un contrôle parfait du cycle de vie du logiciel. Notre développeur ne savait pas qu'un groupe APT ciblait Acme et a publié un composant malveillant sous ce nom, de manière astucieuse afin que le comportement malveillant ne s'active que lorsque le logiciel est installé sur les ordinateurs Acme. Le colis n'a pas été détecté pendant des semaines après sa publication.
Un script d'installation est exécuté pour rechercher les informations d'identification (il y avait de nombreux jetons d'accès juteux dans l'ordinateur portable de notre développeur), permettant l'accès aux référentiels de logiciels internes et au référentiel interne susmentionné, qui bien sûr n'est accessible que via VPN. Le code malveillant a réussi à utiliser la connexion VPN existante et à publier un composant malveillant de deuxième étape dans le registre interne, affectant une bibliothèque d'utilitaires commune partagée par la plupart des logiciels fournis par Acme.
Quelques semaines plus tard, d'autres organisations utilisant les outils publiés par Acme ont commencé à constater un trafic étrange sur leurs réseaux, avec un trafic utilisant le protocole Acme mais dirigé vers des hôtes ressemblant au domaine Acme. Le trafic était crypté, mais les outils de surveillance du système ont trouvé l'accès à des fichiers inattendus et l'exécution de processus qui ressemblent à des commandes système mais qui finissent par exécuter des exécutables téléchargés.
Le reste appartient à l’histoire : Acme a d’abord nié qu’un tel comportement leur était imputable et que toutes les mesures de sécurité étaient en place. Ce n'est qu'après que les médias de cybersécurité ont commencé à se demander pourquoi la source du comportement détecté provenait des composants d'Acme et que l'analyse de sécurité a révélé à quel point ces composants étaient criblés de logiciels malveillants furtifs, Acme a dû reconnaître l'incident et a fait appel à une société de réponse aux incidents. Une campagne marketing négative qui a miné en un instant une confiance durement gagnée. "Acme était à une installation npm de disaster» était un titre courant. S’en sont ensuite suivis des procès et des contrats annulés.
Voyez-vous des ressemblances avec des incidents passés connus ? Acme est tombé à la suite d'un incident de chaîne d'approvisionnement en deux phases, en utilisant un mélange de confusion de dépendance/typosquatting attaques qui utilisaient un poste de travail de développeur comme tête de pont pour infecter des composants qui se retrouvaient dans des logiciels utilisés par des tiers. Comment cela pourrait-il être évité ou atténué ?
Pourquoi les colis empoisonnés sont si populaires
Cet incident hypothétique montre que même avec une approche raisonnable de la sécurité open source, les organisations ont besoin de mesures spécifiques pour éviter de devenir la proie de logiciels malveillants dans les composants open source. Schématiquement, l’acteur menaçant peut :
- Créer un nouveau package (en suivant les voies bien connues du typosquatting ou de la confusion des dépendances, c'est le chemin le plus emprunté par les méchants en volume) ;
- Essayez d'infecter un existant, soit en l'injectant dans le code source, soit en essayant de le déguiser en contributeur via pull request, ou en utilisant l'ingénierie sociale pour devenir un mainteneur (comme « Jao Tan » l'a fait dans le XZ Backdoor ou droite9ctrl L'utilisateur de GitHub l'a fait dans le flux d'événements incident survenu à l'automne 2018), ou en obtenant des informations d'identification pour un référentiel open source et en se faisant passer pour le responsable ;
- Injecter un malware lors de la construction du package, soit en exécutant un script de construction malveillant, ou interférer avec les téléchargements de packages avec des interceptions man-in-the-middle (heureusement, TLS est désormais toujours requis dans la plupart des registres).
- Injectez le composant directement dans le registre, généralement en capturant les informations d'identification du registre (l'alternative préférée pour de nombreuses attaques sophistiquées comme celle d'Acme, où le poste de travail compromis dans la première étape avait le jeton d'accès au registre interne, par exemple dans le cas habituel). .env or ~/.m2/settings.xml: les mauvais acteurs savent où chercher les secrets). Des vulnérabilités dans les registres ont également été exploitées.
L’empoisonnement des registres par des logiciels malveillants constitue la base des attaques de dépendance. Rien de nouveau sous le soleil : sa prévalence a explosé, mais les mêmes techniques fonctionnent aujourd'hui qu'il y a cinq ans.
Source: Collection de couteaux de traître.
Le package malveillant peut fonctionner lors de l’installation, pendant la création du logiciel ou lors de l’exécution. Et le comportement va de l'exfiltration d'informations, par exemple l'extraction de secrets pour une tentative de deuxième phase, à l'extraction de code source, en supprimant des logiciels malveillants supplémentaires. Dans le prochain épisode, nous décortiquerons les packages malveillants et la manière dont ils sont publiés.
Lectures complémentaires
Le prochain épisode Anatomie des packages malveillants : quelles sont les tendances ? se concentrera sur des cas réels que nous surveillons avec notre système Malware Early Warning, jour après jour. Nous examinerons quels types de logiciels malveillants ont été détectés et quelles tactiques, techniques et procédures sont préférées. Nous examinerons l'obscurcissement et la manière dont ils tentent de se cacher des évaluateurs potentiels, les techniques d'évasion pour éviter la détection et comment ils évoluent avec la télémétrie et les mouvements latéraux. S'il vous plaît restez à l'écoute!
Références
- Backstabber's Knife Collection : un examen des attaques de la chaîne d'approvisionnement de logiciels open source. M. Ohm et al., mai 2020.
- Protection contre les logiciels malveillants open source. Livre blanc de Xygeni.
- Software Supply Chain Security Rétrospective : façonner une 2024 plus sûre. Rapport de Xygeni.
