Coder a confirmé qu’un attaquant non identifié avait compromis l’infrastructure prenant en charge son registre de modules et distribué des modules Terraform modifiés conçus pour dérober des identifiants cloud, des clés SSH, des secrets CI/CD et d’autres données sensibles.
Les modules malveillants ont été distribués pendant environ 14 heures le 31 août, de 07:35 à 21:45 UTC. Coder indique n’avoir trouvé aucune preuve que les données clients qu’elle conserve aient été affectées, mais ne peut pas identifier avec certitude chaque déploiement compromis.
Les attaquants ont détourné le chemin de confiance du registre Coder
Selon Coder, un attaquant non identifié a accédé à son infrastructure Cloudflare et ajouté des adresses IP non autorisées au pool qui assurait la distribution de registry.coder.com.
Cloudflare a ensuite acheminé certaines requêtes légitimes vers le registre vers des serveurs contrôlés par les attaquants. Ces serveurs hébergeaient des versions modifiées des modules Terraform de Coder contenant du code destiné à dérober des identifiants.
L’attaque n’a pas exploité de vulnérabilité dans Terraform lui-même. Elle a plutôt compromis un canal de distribution logicielle de confiance, permettant à des artefacts malveillants d’arriver via le nom d’hôte légitime du registre de Coder.
La méthode initiale utilisée pour accéder à l’environnement Cloudflare de Coder n’a pas été divulguée.
Une fois distribués, les modules malveillants recherchaient dans les environnements des provisionneurs des clés API cloud et d’outils d’IA, des identifiants CI/CD, des secrets présents dans les fichiers de configuration, l’historique du terminal, des jetons OIDC, des clés SSH, des jetons d’authentification à usage unique et d’autres données sensibles.
Si un provisionneur s’exécutait dans coderd, le logiciel malveillant pouvait également accéder aux mots de passe de la base de données de Coder et à d’autres secrets de configuration.
Les informations dérobées ont été exfiltrées vers le domaine ressemblant à coder-infra[.]com.
Les modules Terraform pouvaient exécuter du code destiné à dérober des identifiants
Coder demande à ses clients de rechercher dans les journaux des provisionneurs la chaîne data.external.telemetry, qui identifie une source de données externe Terraform utilisée par les modules malveillants.
La source de données externe de Terraform peut exécuter un programme externe et transmettre à ce processus enfant les variables d’environnement visibles par Terraform. La documentation de HashiCorp décrit cette fonctionnalité comme une « soupape de secours » pour les cas où un fournisseur normal ne convient pas.
Cela conférait au module malveillant une position stratégique : le code exécuté pendant le provisionnement de l’infrastructure pouvait accéder aux mêmes identifiants cloud, jetons et données de configuration que ceux disponibles pour le processus de provisionnement.
L’incident met également en évidence un écart entre les protections de Terraform pour les fournisseurs et celles applicables aux modules.
Le fichier .terraform.lock.hcl de verrouillage de Terraform consigne les sélections de fournisseurs et les hachages cryptographiques, mais HashiCorp indique que le fichier de verrouillage ne suit actuellement pas les modules distants.
Une contrainte portant sur une version exacte du module peut garantir que Terraform sélectionne le même numéro de version, mais elle ne vérifie pas de manière indépendante qu’un registre compromis distribue bien le contenu original associé à cette version.
Cette distinction est particulièrement pertinente ici, car le canal de distribution du registre lui-même a été compromis.
L’incident fait suite à d’autres attaques récentes contre la chaîne d’approvisionnement logicielle visant les infrastructures des développeurs, au cours desquelles des paquets ou outils de développement de confiance sont devenus des vecteurs d’accès aux identifiants et aux environnements cloud.
Coder recommande de rechercher les compromissions et de renouveler les identifiants
Coder recommande de vérifier les journaux de pare-feu, de proxy, DNS et de flux VPC afin d’y rechercher des connexions vers coder-infra[.]com avant d’effacer des éléments potentiellement utiles.
Les organisations doivent également rechercher dans les journaux des provisionneurs la chaîne data.external.telemetry, identifier les modules téléchargés pendant la fenêtre d’exposition du 31 août et utiliser la requête SQL publiée par Coder pour identifier les modules mis en cache et les versions de modèles potentiellement affectés.
Les organisations potentiellement affectées doivent renouveler tous les identifiants auxquels les provisionneurs pouvaient accéder pendant l’incident, notamment :
- Clés API cloud et d’outils d’IA
- Identifiants CI/CD
- Jetons OIDC et jetons d’authentification à usage unique
- Clés SSH
- Mots de passe de bases de données, le cas échéant
Le renouvellement des identifiants est particulièrement important, car les clés d’accès cloud peuvent rester utilisables même après le confinement de la compromission initiale.
Coder recommande également de supprimer les paquets mis en cache affectés et de mettre à niveau l’installation vers l’une des versions corrigées :
- 2.37.0
- 2.36.4
- 2.35.7
- 2.34.9
Selon Coder, les jetons d’actualisation n’ont pas été transmis aux provisionneurs.
L’étendue de la compromission reste incertaine
Coder indique ne pas pouvoir déterminer avec certitude chaque déploiement affecté, car les journaux clés sont conservés sur une infrastructure contrôlée par les attaquants.
L’entreprise n’a pas révélé comment l’attaquant avait initialement accédé à son environnement Cloudflare ni attribué cette activité à un acteur connu de la menace.
L’incident alimente les inquiétudes croissantes concernant les outils de développement en tant que composante de la surface d’attaque de la chaîne d’approvisionnement logicielle. Les registres, les systèmes CI/CD, les outils de programmation et l’automatisation des infrastructures peuvent tous contenir des identifiants donnant accès à des ressources bien plus vastes que le simple poste de travail du développeur.
Les organisations qui ont utilisé Coder pendant la fenêtre d’exposition du 31 août doivent donc considérer la mise à jour, l’investigation et le renouvellement des identifiants comme des étapes distinctes de la remédiation. La mise à jour de Coder supprime le canal de distribution compromis, mais elle ne peut pas invalider les secrets qui ont peut-être déjà été dérobés.
À lire aussi : un compte GitHub compromis a contribué à propager l’attaque de la chaîne d’approvisionnement npm Shai-Hulud, distribuant des logiciels malveillants destinés à dérober des identifiants