Menace d’attaque de la chaîne d’approvisionnement sur CodeQL – incident de sécurité déclenché par une clé secrète GitHub exposée

 (praetorian.com)
1 points par GN⁺ 2025-04-01 | 1 commentaires | Partager sur WhatsApp
  • En raison d’une clé secrète GitHub (Secret) exposée publiquement, CodeQL, l’outil d’analyse statique de GitHub, a été exposé à une attaque de la chaîne d’approvisionnement
  • La clé concernée est restée valide pendant 1,022 seconde et, durant ce laps de temps, un attaquant pouvait exécuter du code arbitraire dans un workflow GitHub Actions
  • Cette vulnérabilité a été enregistrée comme CVE publique : CVE-2025-24362

Principaux scénarios d’impact

Grâce à cette vulnérabilité, un attaquant aurait pu mener les attaques suivantes :

  • Exfiltration du code source des dépôts utilisant CodeQL (atteinte à la propriété intellectuelle)
  • Vol des clés secrètes de GitHub Actions et possibilité d’attaques secondaires
  • Exécution de code via les workflows CodeQL dans l’infrastructure interne
  • Vol possible même des clés secrètes des workflows utilisant GitHub Actions Cache

Détection de l’attaque et déroulement de l’expérimentation

  • L’équipe de recherche de Praetorian a développé un outil qui scanne les clés secrètes incluses dans les artefacts de workflow générés par GitHub Actions
  • Découverte d’un artefact de debug contenant une clé secrète dans un dépôt lié à CodeQL
  • Conception et exécution d’un outil de PoC artifact_racer.py démontrant qu’un attaquant pouvait créer une branche ou un tag et pousser des fichiers tant que la clé restait valide

Résultats clés de l’expérimentation

  • Avec ce token, l’attaquant pouvait :
    • créer une nouvelle branche
    • pousser des fichiers
    • ajouter des tags
  • CodeQL référence par défaut le tag v3, et un attaquant pouvait écraser ce tag → distribution possible de code malveillant à tous les utilisateurs de CodeQL

Potentiel de propagation : pourquoi est-ce dangereux ?

  • La plupart des utilisateurs ne configurent pas CodeQL manuellement et se contentent de cliquer sur le bouton "Enable CodeQL" dans les paramètres du dépôt GitHub
  • Le workflow configuré automatiquement référence alors le dépôt github/codeql-action, sur la base du tag v3
  • Si un attaquant écrase le tag v3 avec un commit malveillant, du code malveillant peut être exécuté automatiquement dans un très grand nombre de projets

Vecteur d’attaque supplémentaire : empoisonnement du cache (Cache Poisoning)

  • Le workflow CodeQL par défaut utilise GitHub Actions Cache
  • Cela permet à un attaquant d’injecter un cache malveillant dans le pipeline de build, puis de voler des clés secrètes et d’obtenir un accès interne lors des workflows suivants
  • Principales cibles potentielles :

Réponse et correctif de GitHub

  • Après le signalement de la vulnérabilité le 22 janvier 2025, GitHub a, en moins de 3 heures :
    • interrompu le workflow vulnérable
    • soumis une PR empêchant l’upload de clés secrètes
    • déployé une version corrigée : CodeQL Action v3.28.3
  • Avis de sécurité officiel : GHSA-vqf5-2xx6-9wfm

Mesures de réponse

  • Lors de l’upload d’artefacts dans un workflow, limiter les fichiers envoyés
  • Faire attention à l’inclusion de variables d’environnement, de .git/config et des fichiers du répertoire _temp/
  • Accorder au GITHUB_TOKEN des permissions en lecture seule uniquement
  • Il est recommandé d’effectuer un scan de clés secrètes avant l’upload (avec des outils comme Nosey Parker)

Conclusion

  • Même avec la configuration par défaut de CodeQL, un très grand nombre de projets peuvent être exposés à une attaque de la chaîne d’approvisionnement
  • Les failles de sécurité de GitHub Actions restent une menace sérieuse, et exigent une vigilance continue de la communauté ainsi que des stratégies de défense adaptées

Informations associées

À lire aussi

1 commentaires

 
GN⁺ 2025-04-01
Avis Hacker News
  • Certains estiment que les actions GitHub immuables pourraient résoudre plus de 70 % des attaques une fois lancées
    • Ils pensent que les problèmes rencontrés chaque semaine par GitHub finiront par les pousser à les lancer
  • Il n’est pas expliqué pourquoi le jeton temporaire avait l’autorisation de créer un nouveau déploiement et de générer des attestations d’artefacts
    • Les logs de débogage ont été désactivés pour corriger le problème, mais il n’y a pas de réponse indiquant si les autorisations du jeton temporaire ont été modifiées pour mieux convenir au moteur d’analyse de code
  • Cela renforce de plus en plus l’idée que le CI et le CD devraient être des environnements totalement séparés
    • Une compromission du CI ne devrait pas entraîner une fuite des jetons liés au CD
  • Le temps de réponse de GitHub est très impressionnant
  • Quelqu’un dont le nom de famille est Prater dit qu’il aimerait posséder praetorian.com
  • Utiliser des actions GitHub publiques peut poser problème, et les utiliser sans analyser la procédure du workflow est encore plus risqué
    • Il est recommandé d’auto-héberger à la place avec woodpecker ou un autre excellent outil de CI (circle, travis, gitlab, etc.)
  • Il est mentionné qu’OpenZFS utilise CodeQL pour ses PR et qu’OpenZFS n’a pas de problème
    • Le code d’OpenZFS n’est pas secret
  • Certains se demandent si le problème a été résolu
  • Quelqu’un se plaint que les performances du site sont si mauvaises qu’il est presque impossible de faire défiler la page