Attaque sur la console de build AWS : Quand la chaîne de montage devient un maillon faible

Un article paru le 16 Janvier 2026 sur CyberPress.org détaille une attaque sophistiquée visant les consoles de build AWS via des comptes GitHub compromis. Pour les non-initiés, ce type d’attaque par la chaîne d’approvisionnement peut sembler complexe, mais il est crucial de comprendre ses mécanismes pour mieux s’en protéger.

---

Comment les hackers ont -ils exfiltré les identifiants AWS ?

Voici le déroulement, étape par étape :

Phase 0 : La vulnérabilité technique — Le regex mal ancré 🔍

Le problème central résidait dans une mauvaise configuration subtile des pipelines AWS CodeBuild. Ces pipelines utilisent des filtres webhook pour empêcher les pull requests (PR) non fiables de déclencher des builds. Ces filtres s’appuient sur le paramètre ACTOR_ID pour autoriser uniquement une liste d’identifiants GitHub approuvés.

Le bug ? Les expressions régulières (regex) utilisées n’avaient pas d’ancres de début et de fin (^ et $). Cela signifie qu’un ID GitHub contenant l’ID d’un mainteneur approuvé en tant que sous-chaîne pouvait contourner le filtre.

Exemple concret :

• ID mainteneur approuvé : 12345
• ID attaquant créé : 123456789 (contient 12345)
• Le filtre regex valide 123456789 car il trouve 12345 dedans ! ✅❌

Phase 1 : L’exploitation du système d’ID séquentiels de GitHub 🎯

Les chercheurs ont exploité le fait que GitHub attribue des identifiants utilisateur de manière séquentielle. En automatisant la création de comptes bot via le flux manifeste de GitHub Apps, ils ont pu “réserver” un ID cible contenant l’ID d’un mainteneur de confiance.

Concrètement :

1. Création automatisée de multiples GitHub Apps
2. Récupération d’IDs séquentiels jusqu’à obtenir un ID contenant celui d’un mainteneur AWS
3. Résultat : un compte attaquant qui “passe” les filtres de sécurité

Phase 2 : La pull request malveillante 💣

Une fois l’ID cible obtenu, les chercheurs ont soumis une pull request malveillante au dépôt aws-sdk-js-v3. Cette PR contenait du code conçu pour s’exécuter pendant la phase de build.

Phase 3 : Le déclenchement du build et l’exfiltration 🔑

Le système CodeBuild, trompé par le filtre regex défaillant, a automatiquement déclenché un build à partir de la PR malveillante. Le code injecté a alors :

1. Dumpé la mémoire du processus de build
2. Volé les identifiants GitHub du compte aws-sdk-js-automation
3. Exfiltré ces informations vers un serveur contrôlé par les chercheurs

Ces identifiants offraient :

• ✅ Droits d’administration complets sur le dépôt du SDK JavaScript
• ✅ Accès à plusieurs dépôts privés associés
• ✅ Capacité de pousser du code directement sur la branche principale
• ✅ Pouvoir d’approuver des PR compromises
• ✅ Possibilité d’injecter des backdoors dans les releases hebdomadaires distribuées à des millions d’applications

Phase 4 : L’ampleur de la compromission 🌐

La vulnérabilité affectait au moins trois autres dépôts AWS, exposant potentiellement :

• D’autres comptes d’automatisation
• Des identifiants GitHub personnels d’employés AWS

Impact potentiel :

• Millions d’applications utilisant le SDK JS AWS compromises
• Console AWS elle-même vulnérable
• Chaîne d’approvisionnement globale en danger

Note importante : Cette attaque fait écho à un incident similaire survenu en juillet 2025 avec l’extension Amazon Q pour VS Code, où une misconfiguration CodeBuild similaire avait permis l’injection de code malveillant dans des releases de production.

Phase 5 : La remédiation par AWS 🛡️

Suite à la divulgation responsable par Wiz Research, AWS a :

1. ✅ Remédié immédiatement à toutes les vulnérabilités identifiées
2. ✅ Implémenté des mesures de durcissement à l’échelle de la plateforme CodeBuild
3. ✅ Introduit une nouvelle porte d’approbation : “Pull Request Comment Approval”
   • Requiert une approbation manuelle avant l’exécution de builds de PR non fiables
4. ✅ Confirmé aucun impact sur la confidentialité ou l’intégrité des environnements clients

---

🛡️ Best Practices : Fortifier vos défenses

Face à un tel scénario, il ne faut pas paniquer, mais agir ! Voici une liste de meilleures pratiques pour transformer votre chaîne d’approvisionnement en forteresse, inspirées par les recommandations de l’OWASP et l’expérience du terrain :

Principe du Moindre Privilège (IAM)!

C’est la règle d’or ! Chaque utilisateur, chaque rôle, chaque service (y compris votre système de build CI/CD) ne devrait avoir que les permissions strictement nécessaires pour accomplir sa tâche, et rien de plus.

• Pourquoi ça aide : Si votre système de build n’a besoin que d’écrire sur un bucket S3 spécifique, ne lui donnez pas les droits d’administrateur ! Si un attaquant vole ces identifiants, son champ d’action sera très limité.

Authentification Multi-Facteurs (MFA)!

Activez le MFA partout où c’est possible : pour vos comptes GitHub, vos comptes AWS root, vos utilisateurs IAM, et tout autre service critique. Un simple mot de passe ne suffit plus.

• Pourquoi ça aide : Même si un attaquant réussit à voler votre mot de passe GitHub, il ne pourra pas se connecter sans le second facteur (code sur votre téléphone, clé U2F, etc.).

Gestion des Secrets Sécurisée!

Ne jamais, au grand jamais, stocker des identifiants (clés API, mots de passe de base de données, clés AWS) en clair dans votre code ou vos dépôts GitHub. Utilisez des gestionnaires de secrets dédiés (AWS Secrets Manager, HashiCorp Vault, Azure Key Vault, ou des secrets d’environnement sécurisés par votre CI/CD).

• Pourquoi ça aide : Si votre dépôt GitHub est compromis, il ne contiendra pas les secrets, limitant ainsi les dégâts.
• OWASP Cheat Sheet : La section Secrets Management Cheat Sheet est une mine d’informations !

Analyse de Code Statique (SAST) et de Dépendances

Intégrez des outils d’analyse statique du code (SAST) et de scan de dépendances (SCA) dans votre pipeline CI/CD. Ces outils peuvent détecter des vulnérabilités connues dans votre code, des secrets exposés, ou des dépendances tierces contenant des failles de sécurité.

• Pourquoi ça aide : Ils peuvent potentiellement détecter le code malveillant injecté avant qu’il ne fasse des ravages, ou au moins alerter sur des anomalies.

  Et en analysant votre code de WebHook et ou de build, ils peuvent repérer les ‘ancres’ regex manquantes comme dans cette attaque. Bien souvent, on sous-estime/oublie le fait d’analyser ce type de code…

Durcissement de l’environnement CI/CD!

• “Runners” éphémères : Utilisez des machines de build (runners) qui sont créées à la demande pour chaque build et détruites ensuite.

• Isolation réseau : Isolez vos environnements de build dans des réseaux restreints (VPC, Security Groups) pour qu’ils ne puissent communiquer qu’avec les services AWS nécessaires et rien d’autre.

• Image de build : Utilisez des images de conteneurs de build minimalistes et mises à jour régulièrement.

• Validation des webhooks avec paramètres: Suite a ce que nous avons vu, il est critique de s’assurer que vos webhooks avec paramètres soient correctement écrits. Par exemple, assurer vous que vos expressions régulières dans les filtres webhook aient ^ (début) et $ (fin). Exemple :
  • ❌ Mauvais : 12345 (accepte 123456789, 9912345, etc.)
  • ✅ Bon : ^12345$ (accepte uniquement 12345)
• Approbation des PR critiques :
  • Activez la nouvelle fonctionnalité “Pull Request Comment Approval” introduite par AWS si vous Utilisez CodeBuild. Cette porte de sécurité exige une approbation manuelle explicite (commentaire sur la PR) avant que le build d’une PR non fiable ne s’exécute. Cela empêche les attaques automatisées via des PR malveillantes.
  • Si vous utilisez Github, implémentez les Required reviews (https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/approving-a-pull-request-with-required-reviews) .
  • Si vous utilisez gitlab.com, implémentez les Merge Request Approvals (https://docs.gitlab.com/ee/user/project/merge_requests/approvals/).
  • Si vous avez d’autres systèmes CI/CD, cherchez des fonctionnalités similaires d’approbation manuelle avant l’exécution de builds de PR non fiables.

• 🔑 Personal Access Tokens (PAT) à privilèges minimaux : Utilisez des Fine-Grained Personal Access Tokens avec le minimum de permissions nécessaires plutôt que des tokens classiques avec accès complet. Limitez la portée aux seuls dépôts et actions strictement requis.

• Pourquoi ça aide :
  • Un runner éphémère ne peut pas être infecté de manière persistante.
  • Une isolation réseau stricte empêche le code malveillant de communiquer avec des serveurs externes.
  • L’analyse regulière SAST des codes de build et webhook permet de détecter les vulnérabilités ‘cachées’.
  • La porte d’approbation PR introduit un contrôle humain critique avant l’exécution de code potentiellement malveillant.
  • Les PAT à privilèges minimaux limitent l’impact d’une compromission.

Monitoring et Alerting : Avoir des yeux partout et un bon système d’alarme.

Mettez en place une surveillance rigoureuse de vos logs Clouds, GitHub (audit logs) et de votre système CI/CD. Configurez des alertes pour les activités suspectes : tentatives de connexion échouées multiples, changements de rôle IAM inattendus, accès à des ressources inhabituelles, exfiltration de données.

• Pourquoi ça aide : Détecter rapidement une activité anormale est crucial pour minimiser les dommages.

Audits et Revues de Code Réguliers : L’œil humain reste irremplaçable.

Faites relire votre code, vos configurations CI/CD et vos politiques IAM par un tiers. Des revues de sécurité régulières peuvent dénicher des failles que les outils automatisés pourraient manquer.

• Pourquoi ça aide : Deux paires d’yeux valent mieux qu’une, surtout en sécurité.

Formation et Sensibilisation : Le facteur humain, votre première ligne de défense.

Formez régulièrement vos développeurs et équipes CI/CD/ops aux meilleures pratiques de sécurité, aux risques de phishing, à l’importance de mots de passe robustes et de la MFA.

• Pourquoi ça aide : La plupart des attaques commencent par l’exploitation d’une erreur humaine. Une équipe bien formée est une équipe résiliente.

---

Conclusion :

L’attaque sur les consoles de build AWS via GitHub nous rappelle cruellement que la sécurité n’est pas une option, mais une nécessité absolue.

Elle rappelle aussi que la chaîne d’approvisionnement logicielle est aussi forte que son maillon le plus faible, et que les attaquants sont toujours à l’affût de la moindre faille.

Elle rappelle aussi l’importance d’analyser et de durcir le code de vos pipelines CI/CD, y compris les webhooks et scripts de build.

---