Plusieurs projets open source de haut niveau, y compris ceux de Google, Microsoft, AWS et Red Hat, ont révélé des fuites de jetons d’authentification GitHub via des artefacts d’actions GitHub dans les flux de travail CI/CD.
Les attaquants volant ces jetons pourraient obtenir un accès non autorisé à des référentiels privés, voler du code source ou injecter du code malveillant dans des projets.
La découverte par l’unité 42 de Palo Alto Networks a incité les propriétaires de référentiels populaires à agir, où des secrets ont été divulgués via des artefacts d’actions GitHub. Cependant, les problèmes sous-jacents restent non résolus car GitHub a décidé de ne pas aborder le risque, plaçant la responsabilité sur les utilisateurs de sécuriser leurs artefacts.
Compte tenu de la situation, les utilisateurs de GitHub doivent comprendre les risques, évaluer leur exposition et prendre des mesures pour éviter les fuites à l’avenir.
Jetons GitHub qui fuient
Le rapport de l’Unité 42 met en évidence une combinaison de facteurs, notamment des paramètres par défaut non sécurisés, une mauvaise configuration de l’utilisateur et des contrôles de sécurité insuffisants, qui peuvent entraîner la fuite de jetons GitHub dans ce qu’ils appellent une attaque « ArtiPACKÉE ».
Le premier point de risque est l’action « actions / extraction », couramment utilisée dans les flux de travail GitHub pour cloner le code du référentiel afin qu’il soit disponible pendant l’exécution du flux de travail.
Par défaut, cette action persiste le jeton GitHub vers le local .répertoire git (masqué) requis pour les opérations authentifiées dans le workflow.
Si un utilisateur télécharge par erreur l’intégralité du répertoire de paiement dans le cadre d’un artefact, le jeton GitHub à l’intérieur du dossier git sera désormais exposé.
D’autres informations sensibles pouvant être contenues dans ce dossier incluent des clés d’API, des jetons d’accès au service cloud et diverses informations d’identification de compte.
Une exposition similaire par des téléchargements d’artefacts erronés peut se produire par des artefacts générés pendant le processus CI / CD, tels que les sorties de construction et les résultats des tests, qui sont stockés et accessibles jusqu’à trois mois.
Un autre point d’échec concerne les pipelines CI/CD qui utilisent des variables d’environnement pour stocker les jetons GitHub. Si des actions ou des scripts dans le flux de travail enregistrent ces variables, délibérément ou par erreur, les journaux sont téléchargés en tant qu’artefacts.
L’unité 42 note que l’action ‘super-linter’ peut créer des journaux détaillés qui incluent des variantes d’environnement lorsque la propriété ‘CREATE_LOG_FILE’ est définie sur ‘ True.’
Exploiter les fuites
En fin de compte, les attaquants chercheraient à exploiter des scénarios de conditions de concurrence spécifiques dans lesquels les jetons GitHub éphémères doivent être extraits des journaux et utilisés avant leur expiration.
Les jetons GitHub restent valides pendant toute la durée du travail de workflow, leur potentiel d’exploitation varie donc selon les cas.
Le « Actions_Runtime_Token », utilisé en interne par GitHub pour la mise en cache et la gestion des artefacts, est généralement valide pendant six heures, de sorte que la fenêtre d’exploitation est petite.
Les secrets et jetons personnalisés, tels que les clés API ou les jetons d’accès pour les services cloud, ont des durées de vie variables, de quelques minutes à n’expirer jamais.
L’unité 42 présente un scénario d’attaque qui identifie les projets ou les référentiels publics qui utilisent des actions GitHub et utilise des scripts automatisés pour les analyser à la recherche de critères qui augmentent la probabilité de génération d’artefacts.
Un ensemble différent de scripts pourrait télécharger automatiquement des artefacts à partir des pipelines CI/CD des référentiels cibles, ce qui est un processus simple dans le cas des référentiels publics. Ensuite, il les examinerait pour trouver des secrets.
Atténuation
L’unité 42 a identifié les 14 cas suivants de grands projets open source exposant des artefacts avec des jetons GitHub et les a signalés aux parties concernées pour correction:
- Firebase (Google)
- Sécurité OpenSearch (AWS)
- Clair (Chapeau rouge)
- Système d’annuaire actif (Adsys) (Canonique)
- Schémas JSON (Microsoft)
- Automatisation des Rapports TypeScript, TypeScript À La Fois Déclenché Par les Tests, Azure Draft (Microsoft)
- SBOM cyclonique (OWASP)
- Stockfish
- Libévénement
- Gardien pour Apache Kafka (Aiven-Ouvert)
- Annexe Git (Base de données)
- Pénrose
- Rouf
- Béton-ML (Zama AI)
En général, il est recommandé aux utilisateurs de GitHub d’éviter d’inclure des répertoires entiers dans les artefacts téléchargés, de nettoyer les journaux et de revoir régulièrement les configurations de pipeline CI/CD.
Les paramètres par défaut pour les actions dangereuses telles que « actions/checkout » doivent être ajustés afin que les informations d’identification ne persistent pas. De plus, les autorisations de jeton utilisées dans les flux de travail doivent être définies sur le moindre privilège nécessaire pour limiter les dommages au cas où elles seraient exposées.