Cet article a été coécrit par Zach Rice et Joe Leon, tous deux chez Aikido .
En bref : certaines informations d'identification sont censées être publiques, mais les scanners de secrets les signalent tout de même comme des secrets génériques. Nous avons défini des règles de suppression pour les plus courantes et réduit les faux positifs d'environ 2 %. Ces règles sont désormais intégrées par défaut dans Betterleaks.
Les scanners de secrets s'appuient sur des expressions régulières. Chaque modèle cible un type d'identifiant spécifique, comme une clé d'accès secrète AWS, un PAT GitHub ou un jeton Stripe. Une fois qu'un scanner identifie un secret potentiel, il effectue un contrôle de validité, par exemple en envoyant une requête HTTP afin de vérifier si l'identifiant est valide.
Ce workflow échoue lorsque les scanners de secrets tentent d'identifier des secrets génériques. Les secrets génériques sont les clés API et les identifiants qui ne possèdent pas de signature unique ou connue. Les scanners peuvent tout de même utiliser une expression régulière pour les détecter, mais au lieu de rechercher une correspondance avec un format d'identifiant connu, ils utilisent un modèle générique pour repérer tout élément susceptible d'être un secret.
Réduire le bruit dans analyse des secrets le problème des expressions régulières
Il est assez facile d'écrire une expression régulière sophistiquée pour repérer dans le code (et ailleurs) les chaînes de caractères qui ressemblent à des secrets. Mais sans vérification prédéfinie de l'actualité, le scanner ne peut pas affirmer avec certitude qu'un secret générique est effectivement un secret actif.
Cette approche oblige les utilisateurs à trier manuellement les faux positifs. Mais ce n'est pas très amusant. C'est pourquoi, au cours des prochains mois, nous allons déployer une série de couches de réduction du bruit :
- Filtrage basé sur l'efficacité des jetons (dernier message)
- Liste noire des identifiants pouvant être publiés (cet article)
- Liste noire des secrets d'État
- Répartition des règles génériques en deux catégories : les jetons et les identifiants/mots de passe
- Triage assisté par l'apprentissage automatique
Nous souhaitons suivre cet ordre précis, car notre objectif est d’éliminer le plus grand nombre possible de faux positifs à moindre coût, puis de recourir à des opérations d’apprentissage automatique plus coûteuses pour traiter les ambiguïtés restantes. Le résultat ne sera jamais parfait, mais nous pensons que les secrets génériques constituent la plus grande opportunité dans le domaine de analyse des secrets. C’est le domaine idéal pour que les chercheurs fassent de nouvelles découvertes et que les défenseurs prennent une longueur d’avance sur les acteurs malveillants. L’objectif de cette série est d’améliorer suffisamment les règles par défaut de Betterleaks pour permettre aux chercheurs et aux analystes de trier à grande échelle les résultats relatifs aux secrets génériques.
Pourquoi certaines clés sont considérées comme des clés pouvant être rendues publiques (pas vraiment secrètes)
De nombreux cloud SaaS et cloud génèrent pour leurs utilisateurs des identifiants destinés à être rendus publics. Stripe, le prestataire de services de paiement, met à la disposition de ses utilisateurs plusieurs types de clés, dont une « clé API publiable ». Ces clés sont conçues pour être « intégrées dans le code front-end ».
Une règle générique de détection des secrets identifierait probablement cet élément comme un secret potentiel. Il présente une entropie élevée, se trouve à proximité de mots-clés tels que « api_key » et ressemble globalement à un identifiant. Mais il ne s'agit pas d'un véritable secret. Il est destiné à être public, et un chercheur ou un analyste ne devrait pas perdre son temps à l'examiner manuellement.
Nous avons donc créé une expression régulière pour supprimer ce type de clé des résultats génériques de Betterleak concernant les secrets.
Mais Stripe n'est qu'un type d'identifiant parmi d'autres. Nous devions étendre ce processus à plus grande échelle. Nous avons étudié les types d'identifiants « publics par conception » les plus courants et avons créé manuellement des signatures de détection pour chacun d'entre eux. Oui, manuellement. L'IA s'est révélée étonnamment inefficace pour cette tâche.
Réduire les taux de faux positifs parmi les secrets génériques
Après avoir passé des heures à ajouter manuellement ces expressions, nous avons voulu vérifier si cela en valait la peine. Pour mesurer l'impact de ce changement, nous avons téléchargé 100 Go de données depuis Common Crawl et les avons analysées deux fois avec Betterleaks : une fois avec les nouvelles signatures, et une fois sans.
Les nouvelles signatures de certificats publiables ont permis de réduire les faux positifs de 2,37 %. Dans notre ensemble de données, cela a représenté 27 886 secrets en moins à examiner manuellement.
Cela représente environ 5 % de temps d'analyse en plus, mais éviter autant de faux positifs en vaut largement la peine.
Votre taux de réduction variera en fonction des données que vous analysez. Common Crawl se concentre principalement sur le code HTML et JavaScript du front-end, là où se trouvent précisément les identifiants publiables, ce qui a probablement pour effet de gonfler nos résultats. Quoi qu’il en soit, chaque identifiant publiable supprimé par le filtre est un identifiant qu’un chercheur ou un analyste n’aura pas à trier.
« Public » ne rime pas toujours avec « sûr »
Le problème avec cette approche est que le fait que des identifiants puissent être publiés ne signifie pas nécessairement qu’il n’y a aucun risque. Chaque type de clé nécessite un examen manuel de sa structure et des droits d’accès qui lui sont accordés dans le contexte de la plateforme SaaS. Lors de l’élaboration de cette liste, nous avons rencontré cinq cas qui méritent d’être examinés, en particulier pour toute personne envisageant de soumettre une PR en ajouter d’autres (n’hésitez pas à le faire !).
Forme originale : facile
C'est très simple. Les identifiants publiables ont une forme unique et caractéristique. Nous rédigeons une expression régulière unique et sommes certains que celle-ci n'exclura aucun secret générique potentiellement valide.
Pas de forme distinctive : il faut le contexte
Il s'agit de chaînes de caractères qui peuvent littéralement apparaître n'importe où. Il peut s'agir d'un UUID, ou simplement de 32 caractères hexadécimaux quelconques. Le format à lui seul ne permet pas d'identifier cette chaîne comme un type d'identifiant pouvant être publié. Dans ces cas-là, nous nous appuyons sur un mot-clé adjacent pour confirmer qu'elle appartient à une plateforme SaaS ou à cloud particulier.
Cette approche n'est pas nouvelle. Nous procédons ainsi tout le temps pour les identifiants confidentiels.
C'est comme un secret : il faut vérifier qu'il est bien valide
Ce n'est pas facile. Certains fournisseurs de SaaS choisissent de créer des identifiants secrets et des identifiants pouvant être publiés en utilisant exactement le même format. Honnêtement, nous préférerions qu'ils ne le fassent pas. Cela complique la détection des identifiants secrets et sème la confusion chez les utilisateurs. Mais nous en avons rencontré beaucoup de ce type.
Dans ces cas-là, la seule façon de supprimer en toute sécurité le type de clé passible de sanctions consiste à ajouter une signature de détection (à l'aide d'une requête HTTP de vérification d'activité) pour l'identifiant secret.
Étant donné que les clés publiques et secrètes ont la même structure, la signature de détection du type de clé secrète les identifie toutes les deux ; après un contrôle de validité, elle détermine que la clé publique n'est pas une clé secrète et la rejette.
Vulnérable uniquement en cas de mauvaise configuration : nécessite un contrôle de disponibilité
Il existe certains types de clés générées par cloud de SaaS et cloud pour lesquelles, selon qu’un utilisateur a ou non ajouté une autorisation spécifique, la clé peut être considérée comme sensible ou sans risque. J’ai déjà beaucoup écrit sur les clés API de Google et leur capacité à accéder à Gemini. C’est un exemple parmi d’autres. Mais j’ai observé ce même schéma avec les clés Algolia et d’autres encore.
Dans ces situations, la meilleure approche à adopter est similaire à celle que nous suivons lorsque nous constatons des conflits de format entre les clés publiques et les clés secrètes : nous envoyons un test de validité pour déterminer si le système peut accéder à des données sensibles.
Identifiants de test : nécessitent un triage manuel
Certaines plateformes SaaS, comme Stripe, mettent à la disposition des utilisateurs un environnement de test ou un « sandbox ». Au départ, nous avions envisagé d'exclure systématiquement ces résultats des résultats génériques de détection des secrets.
Cependant, en y regardant de plus près, il est apparu clairement que certaines organisations intégraient des données de production dans leurs environnements de test. Et même si une clé Stripe divulguée dans un environnement de test ne permettrait peut-être pas d’envoyer des milliers de dollars sur le compte d’un acteur malveillant, elle pourrait lui donner accès aux informations personnelles identifiables (PII) des clients ou à d’autres données internes importantes. Comme nous ne pouvons pas savoir si un identifiant de test donne accès à des données internes sensibles, nous conservons ces résultats dans nos conclusions et nous nous appuyons sur un triage manuel.
Résoudre le problème de détection de secrets générique détection de secrets par étape
La détection générique des secrets est un problème de filtrage, et le filtrage repose sur une succession de petits progrès qui s’accumulent les uns après les autres. Nous commençons par éliminer ce dont nous sommes certains. Nous espérons que quelques-uns de ces petits changements permettront une détection générique efficace des secrets à grande échelle.
La version actuelle de Betterleaks filtre par défaut les clés publiables parmi les résultats génériques. Essayez-la !
