L’équipe de recherche de Wiz a récemment découvert une vulnérabilité de la chaîne d’approvisionnement dans IBM Cloud, qui serait selon elle la première à toucher l’infrastructure d’un fournisseur cloud.
Dans un élan théâtral, elle a baptisé la faille Hell’s Keychain.
Les problèmes de sécurité ont été signalés à IBM Cloud fin août et corrigés début septembre. Avant la correction, un attaquant connaissant la vulnérabilité aurait pu exécuter du code malveillant et modifier les données stockées par tout client d’IBM Cloud utilisant PostgreSQL.
Une recette pour l’accès : lien interdit et secrets du trousseau
Les chercheurs de Wiz – Ronen Shustin, Shir Tamari, Nir Ohfeld et Sagi Tzadik – ont écrit dans un billet de blog : « D’après notre expérience, la recette d’une attaque de la chaîne d’approvisionnement visant un fournisseur de services cloud (CSP) comporte deux ingrédients : le lien interdit et le trousseau. Le lien interdit représente l’accès au réseau – plus précisément, il s’agit du lien entre un environnement de production et son environnement de compilation. »
Le trousseau, ont-ils expliqué, « symbolise l’ensemble d’un ou plusieurs secrets disséminés que l’attaquant découvre dans l’environnement ciblé. Bien que les deux composants soient individuellement peu hygiéniques, ils forment un composé fatal lorsqu’ils sont combinés. »
Dans le cas de Hell’s Keychain, les trois secrets du trousseau étaient un jeton de compte de service Kubernetes, un mot de passe de registre privé de conteneurs et des identifiants de serveur CI/CD. Le lien interdit reliait une instance PostgreSQL personnelle à l’environnement de compilation d’IBM Cloud Databases.
À lire aussi:
- Conseils de sécurité de la chaîne d’approvisionnement logicielle pour les développeurs
- Comment les pirates compromettent la chaîne d’approvisionnement logicielle
Injection SQL et extraction de données des registres de conteneurs
Les chercheurs ont d’abord découvert une vulnérabilité d’injection SQL qui leur a permis d’exécuter des commandes arbitraires sur la machine virtuelle sous-jacente hébergeant leur instance de base de données. Ils s’en sont servis pour cartographier l’environnement interne et rechercher de nouvelles surfaces d’attaque.
Leurs actions ont déclenché une alerte de l’équipe de sécurité d’IBM Cloud, qui leur a finalement donné l’autorisation de poursuivre leurs recherches.
En explorant l’environnement, ils ont trouvé un jeton d’API Kubernetes, qu’ils ont utilisé pour accéder à l’API Kubernetes et afficher la liste des autres pods exécutant des instances PostgreSQL. Ils ont ensuite utilisé l’extraction de données des registres de conteneurs pour trouver quatre identifiants permettant d’accéder à plusieurs registres de conteneurs.
« Notre requête adressée à l’API IAM d’IBM Cloud a révélé qu’il s’agissait d’une clé d’API capable d’accéder aux images du registre de conteneurs d’IBM Cloud, qui semblait disposer d’une autorisation de lecture-écriture ! Nous avons ensuite utilisé ibmcloud-cli pour nous connecter au registre de conteneurs concerné avec cette clé », ont-ils écrit.
Bien qu’il se soit avéré que la description de la clé était inexacte – ils ne pouvaient pas écrire dans le registre de conteneurs –, ils considéraient tout de même leurs découvertes comme graves. « Si un acteur malveillant avait obtenu ces identifiants, il aurait pu extraire et examiner des centaines d’images appartenant aux services de bases de données gérées d’IBM Cloud », ont-ils écrit.
À lire aussi : Comment empêcher les attaques par injection SQL
Accès réseau aux serveurs de compilation d’IBM Cloud
Les chercheurs ont analysé les images de conteneurs auxquelles ils avaient accès et trouvé plusieurs secrets sensibles dans des fichiers négligés, notamment des identifiants FTP et des identifiants de référentiel d’artefacts internes pour les services internes d’IBM Cloud.
Ils ont ensuite examiné les commandes historiques utilisées pour créer l’image du conteneur afin de déterminer quels artefacts étaient concernés. « Lorsque nous avons tenté d’accéder à ces serveurs depuis la machine hébergeant l’instance PostgreSQL, nous avons été stupéfaits de découvrir que nous disposions d’un accès réseau aux serveurs de compilation internes d’IBM Cloud ! Nous avons alors entrepris de nous y authentifier à l’aide des identifiants du référentiel d’artefacts et avons ainsi découvert le lien interdit », ont-ils écrit.
Enfin, ils ont testé leurs autorisations en créant des fichiers dans les référentiels utilisés lors du processus de compilation de l’image PostgreSQL. « Cela a prouvé que nous pouvions écraser des fichiers arbitraires dans les paquets qui auraient été installés sur chaque instance PostgreSQL, établissant ainsi le vecteur de l’attaque de la chaîne d’approvisionnement », ont-ils écrit.
Les enseignements à retenir
Les chercheurs de Wiz ont déclaré que Hell’s Keychain « montre comment des identifiants en clair disséminés dans votre environnement peuvent faire peser un risque considérable sur votre organisation en compromettant son intégrité et l’isolation entre les locataires. En outre, la vulnérabilité souligne la nécessité de contrôles réseau stricts et montre que l’accès des pods à l’API Kubernetes est une mauvaise configuration courante pouvant entraîner une exposition et une extraction sans restriction des registres de conteneurs. »
Selon les chercheurs, trois enseignements clés peuvent être tirés de leurs découvertes :
- Surveillez en permanence votre environnement à la recherche de secrets disséminés
- Assurez-vous que votre environnement de production dispose de contrôles réseau stricts
- Configurez votre registre de conteneurs pour empêcher les acteurs malveillants d’en extraire les données
« IBM Cloud a rapidement enquêté sur les vulnérabilités et les problèmes de sécurité que nous avions découverts, puis les a corrigés », ont-ils écrit. « Nous avons apprécié de travailler avec l’équipe de sécurité d’IBM Cloud, qui a pris ces problèmes très au sérieux en les traitant rapidement et avec professionnalisme. »
Pour aller plus loin: