Un zombie est créé lorsqu’un secret est exposé mais non révoqué, restant ainsi un vecteur d’attaque potentiel. Le seul moyen de supprimer le risque inhérent à la fuite d’un secret est de supprimer toutes les autorisations qui y sont associées.
De nombreux secrets sont régulièrement publiés accidentellement dans des dépôts publics.
Au cours de l’année écoulée, le nombre de secrets découverts sur GitHub est certes très important, mais ce qui attire vraiment l’attention cette année, c’est ce qui s’est passé après l’identification des secrets exposés.
Qu’est-ce qu’un secret zombie ?
Ce terme a été inventé suite à une observation : les propriétaires de dépôts de code réagissent souvent à une fuite sensible en supprimant le dépôt ou en le rendant privé, dans l’idée de couper l’accès public à l’information problématique.
Le problème est que, ce faisant, ils peuvent créer une faille de sécurité majeure pour eux-mêmes ou pour l’organisation pour laquelle ils travaillent : ils peuvent créer un « secret zombie ».
Un zombie est créé lorsqu’un secret est exposé mais non révoqué, restant ainsi un vecteur d’attaque potentiel. L’auteur du commit peut penser qu’il suffit de supprimer le commit ou le dépôt, négligeant ainsi l’étape cruciale de la révocation.
Mais soyons clairs: le seul moyen de supprimer le risque inhérent à la fuite d’un secret est de supprimer toutes les autorisations qui y sont associées. C’est exactement ce que signifie la révocation dans ce contexte. Ce faisant, le secret devient aussi inoffensif que n’importe quelle chaîne de caractères.
Éliminer le secret du code, en revanche, n’a absolument aucun impact sur la posture de sécurité de l’entreprise, puisqu’elle n’a aucun contrôle sur la « propagation » de ce secret (oui, même si le secret a été divulgué à l’intérieur d’un périmètre « privé »). Pire encore, cela peut rendre plus difficile, voire impossible, le travail des spécialistes de la sécurité qui cherchent à corriger ce type de vulnérabilité, car la fuite est désormais invisible.
Imaginons le scénario suivant : un développeur commit accidentellement le fichier .env contenant les secrets de production de son entreprise sur son dépôt GitHub personnel. Se rendant rapidement compte de son erreur, il rendit le dépôt privé.
Se sentant coupable et honteux de cette erreur, il hésite à divulguer l’incident à son équipe de sécurité et estime que sa réaction a été suffisamment rapide pour atténuer tout risque de compromission. De toute façon, qui pourrait trouver cette aiguille dans la botte de foin qu’est GitHub ?
Des mois plus tard, l’équipe de sécurité de l’entreprise effectue un audit pour évaluer son exposition sur GitHub. À cette fin, elle envoie un questionnaire de sécurité à tous les ingénieurs logiciels, leur demandant de déclarer s’ils possèdent un compte GitHub.
Sur cette base, l’équipe de sécurité procède ensuite à l’analyse de tous les dépôts publics à la recherche d’informations d’identification ayant fait l’objet d’une fuite. Le problème, c’est qu’ils ne verront pas la fuite du fichier .env, puisque celui-ci a disparu de la partie publique de la plateforme. Cette vulnérabilité leur échappe désormais, à moins qu’ils n’utilisent un outil capable d’interroger l’historique complet de GitHub.
D’un autre côté, un acteur malveillant aurait pu détecter le fichier .env et les informations d’identification codées en dur (il y a plus de 50 % de chances que cette extension de fichier contienne des secrets valides). Il dispose alors de nombreuses options pour les exploiter afin d’atteindre ses objectifs.
C’est l’exemple type d’une fuite de secret zombie : le secret existe, mais personne (vous souhaitant du bien) ne le surveille activement ou ne prend de mesures pour le révoquer.
Les secrets zombies sont très nombreux
Des services existent pour alerter les propriétaires de dépôts de code lorsqu’ils découvrent une fuite de secret dans leurs commits Git publics. Au cours des cinq jours suivant la détection, des vérifications sont effectuées et répétées pour déterminer si ces secrets restent valides.
Plus de 91 % des fuites restent valides après cinq jours1 et ce chiffre est inquiétant. De nombreux propriétaires de dépôts ont supprimé ou rendu privé leurs dépôts après la notification, mais n’ont pas révoqué le secret ayant fait l’objet de la fuite.
Une sélection aléatoire de 5 000 dépôts dont le secret avait disparu dans les cinq jours a montré que 28,2 % des dépôts étaient toujours publics, tandis que 71,8 % avaient été supprimés ou rendus privés.
Bien qu’il soit difficile de spéculer sur la prévalence des secrets zombies, ces indices suggèrent qu’ils sont assez répandus.
Les fuites de secrets sont des vulnérabilités à haut risque
Lorsqu’on parle de secrets, il est essentiel de se rappeler que tout secret actif codé en dur représente une vulnérabilité à très fort impact jusqu’à ce qu’il soit révoqué.
Bien que cela semble évident, il est important de donner la priorité à ce type de vulnérabilité par rapport à d’autres risques liés aux applications, tels que le célèbre OWASP Top10 ou le plus récent OWASP Top 10 Risks for Open Source Software.
Les fuites de secrets sont un type de vulnérabilité unique car la menace potentielle qu’elles représentent à son propre cycle de vie, complètement indépendant de la source qui les héberge. Cela signifie qu’un secret ayant fuité ne cesse pas d’être une menace lorsque :
● l’application dans laquelle il est intégré cesse de fonctionner,
● le code où il est codé en dur est écrasé ou rendu privé,
● le message où il a été partagé est supprimé,
● le disque où il est stocké est finalement crypté.
Pourquoi une vulnérabilité à haut risque ? Examinons le système de classement de la gravité des vulnérabilités logicielles, le système CVSS (Common Vulnerability Scoring System).
Le niveau de risque le plus élevé est défini comme suit :
Critique (9.0 à 10.0) : Ces vulnérabilités sont généralement faciles à exploiter par un attaquant et peuvent entraîner des accès non autorisés, des violations de données et la compromission ou l’interruption du système. Comme pour les vulnérabilités à haut risque, il est conseillé de porter une attention immédiate à ces vulnérabilités et de les atténuer.
La principale différence entre les vulnérabilités critiques et les vulnérabilités à haut risque est que l’exploitation d’une vulnérabilité à haut risque entraîne généralement une compromission au niveau de la racine des serveurs ou des dispositifs d’infrastructure.
Les informations d’identification divulguées qui restent actives correspondent précisément à cette définition et sont, au mieux, des vulnérabilités critiques.
Comment empêcher les secrets de devenir des zombies ?
Il faut les révoquer. C’est facile à dire, mais pas si facile à faire. Mais pourtant, c’est essentiel.
Voici une vue d’ensemble du processus en quatre étapes pour les organisations :
1. Mettre de l’ordre dans la gestion de leurs secrets. Il peut s’agir d’utiliser un fichier .env, de le retirer du contrôle de version ou de faire appel à un gestionnaire de secrets externe tel que CyberArk, AWS Secrets Manager ou HashiCorp Vault.
2. Générer un nouveau secret pour remplacer ceux qui ont été divulgués. Tester minutieusement son nouveau code pour s’assurer que tout fonctionne correctement avec les nouveaux secrets et les outils de gestion des secrets.
3. Mettre le nouveau code en production, en supprimant le(s) ancien(s) secret(s).
4. Révoquer le secret qui a fait l’objet d’une fuite et supprimer toutes les autorisations qui y sont associées.
Il y a une chose sur laquelle nous n’insistons jamais assez, c’est sur la nécessité de mettre en œuvre des pratiques et des procédures pour découvrir et remédier aux fuites de secrets avant qu’elles ne deviennent un danger pour l’entreprise et ses clients.
