Un attaquant isolé a publié 14 packages NPM malveillants imitant les bibliothèques populaires OpenSearch et Elasticsearch

Un seul utilisateur de npm a publié jeudi 14 packages malveillants dans une fenêtre de quatre heures, tous imitant les bibliothèques populaires OpenSearch, Elasticsearch, DevOps et de configuration d’environnement, selon Microsoft.

Il s’agit de la dernière d’une série apparemment sans fin d’attaques sur la chaîne d’approvisionnement ciblant les outils de développement et volant dans son sillage les informations d’identification du cloud et les secrets du pipeline CI/CD.

À l’aide d’un alias de responsable nouvellement créé, vpmdhaj (a39155771@gmail(.)com), l’acteur malveillant a publié 14 packages usurpant l’identité de bibliothèques légitimes des écosystèmes @opensearch et @elastic et ciblant Amazon Web Services, HashiCorp Vault, GitHub Actions et le registre npm lui-même. Cela suggère que l’attaquant « a probablement choisi un public de développeurs pour disposer des informations d’identification AWS et Elastic cloud dans leurs environnements », a averti Microsoft dans un blog publié jeudi.

Tous les packages malveillants incluent le même intermédiaire au moment de l’installation et la même charge utile de deuxième étape compilée par Bun : un récupérateur d’informations d’identification de 195 Ko spécialement conçu pour les environnements cloud et CI/CD.

De plus, comme nous l’avons vu récemment avec toutes les autres attaques de la chaîne d’approvisionnement open source, après avoir volé des jetons et d’autres secrets, l’attaquant peut se déplacer latéralement à travers les environnements cloud, voler des données sensibles supplémentaires et envoyer des mises à jour encore plus empoisonnées aux packages appartenant à des identités de responsable piratées, étendant ainsi l’attaque au-delà des 14 initiales.

Toutes les bibliothèques malveillantes ont depuis été supprimées et Microsoft a publié une liste des 14 sur son blog. Lisez-le pour vous aider à identifier les systèmes qui ont installé ou créé des versions de package concernées à compter du 28 mai. Assurez-vous également de faire pivoter les jetons AWS IAM/STS, HashiCorp Vault, npm submit et GitHub Actions qui peuvent avoir été exposés.

Pour inciter les utilisateurs à installer ces outils de développement et ces moteurs de recherche, l’attaquant a utilisé le typosquatting – en nommant un package à une ou deux lettres du paquet légitime – ou un nom similaire (tel que opensearch-setup-tool, opensearch-config-utility et elastic-opensearch-helper) pour usurper l’identité de bibliothèques bien connues.

En plus de cette technique d’ingénierie sociale, utilisée pour piloter les installations grâce aux erreurs de frappe ou à la confiance des utilisateurs, l’attaquant a également utilisé deux autres techniques pour rendre l’attaque de la chaîne d’approvisionnement plus crédible.

Cela inclut l’usurpation des métadonnées en amont. « Chaque package non défini définit sa page d’accueil package.json, son référentiel et ses champs de bogues sur le projet légitime github.com/opensearch-project/opensearch-js », ont expliqué les chasseurs de menaces de Microsoft.

Et finalement, ils ont gonflé les numéros de version, de sorte que les fausses « versions » passent directement à 1.0.7265, 1.0.9108 ou 2.1.9201 pour indiquer un historique de versions mature.

Après avoir incité les utilisateurs à installer les packages npm – tous les 14 sont répertoriés dans le blog, alors lisez-le – les charges utiles de vol d’informations d’identification s’exécutent automatiquement via des hooks de préinstallation dès que la victime exécute l’installation de npm.

Pour cela, l’attaquant a utilisé l’un des deux stagers. Le stager Gen-1 utilise des hooks d’installation, de préinstallation et de post-installation qui appellent tous preinstall.js, puis collecte une tonne d’informations sur l’hôte, notamment le nom d’hôte, la plate-forme, l’arch, la version du nœud, USER/USERNAME, cwd, INIT_CWD, npm_package_name, npm_package_version. Il encode ensuite le JSON en base64 et le POST sur le serveur de commande et de contrôle de l’acteur, qui sert ensuite une charge utile de deuxième étape, écrite dans payload.bin dans le répertoire d’installation du package.

« Le fichier index.js du package relance le même payload.bin à chaque require() ultérieur du module – un mécanisme de persistance silencieux qui survit à travers les étapes de construction de CI et les boucles de reconstruction des développeurs », selon Microsoft.

Le dernier stager Gen-2 remplace l’aller-retour C2 au moment de l’installation par un chargeur plus furtif qui vérifie si bun est déjà présent sur l’hôte. Dans le cas contraire, il télécharge le runtime Bun légitime v1.3.13, puis exécute la charge utile de deuxième étape, qui se met à voler les informations d’identification sur AWS, HashiCorp Vault, npm, GitHub Actions et d’autres environnements CI/CD.®