Cet article a été co-écrit par Zach Rice et Joe Leon, tous deux chez Aikido Security.
En bref : Certains identifiants sont destinés à être publics, mais les scanners de secrets les signalent toujours comme des secrets génériques. Nous avons écrit des règles de suppression pour les plus courants et avons 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 sont basés 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 que le scanner identifie un secret potentiel, il effectue une vérification de validité en envoyant, par exemple, une requête HTTP pour vérifier si l'identifiant est actif.
Ce flux de travail se dégrade 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 n'ont pas de signature unique ou connue. Les scanners peuvent toujours utiliser une expression régulière pour les trouver, mais au lieu de chercher à correspondre à un format d'identifiant connu, ils utilisent un modèle générique pour détecter tout ce qui pourrait ressembler à un secret.
Réduire le bruit dans l'analyse des secrets et le problème des expressions régulières
Il est plutôt facile d'écrire une expression régulière sophistiquée pour faire apparaître des chaînes dans le code (et ailleurs) qui ressemblent à des secrets. Mais sans une vérification de vivacité prédéfinie, le scanner ne peut pas dire avec certitude si un secret générique est réellement un secret actif.
Cette approche oblige les utilisateurs à trier manuellement les faux positifs. Mais ce n'est pas amusant. C'est pourquoi, au cours des prochains mois, nous déploierons une série de couches de réduction du bruit :
- Filtrage de l'efficacité des jetons (dernier article)
- Liste de refus des identifiants publiables (cet article)
- Liste de refus des secrets publics
- Séparation des règles génériques en deux types : jetons et noms d'utilisateur/mots de passe
- Triage assisté par ML
Nous souhaitons procéder dans cette séquence particulière car nous cherchons à éliminer autant de faux positifs que possible à moindre coût, puis à utiliser des opérations de ML coûteuses pour l'ambiguïté restante. Ce ne sera jamais parfait, mais nous pensons que les secrets génériques représentent la plus grande opportunité dans l'analyse des secrets. C'est le meilleur endroit pour les chercheurs afin de découvrir de nouvelles vulnérabilités et pour les défenseurs de devancer les acteurs de la menace. L'objectif de cette série est de rendre les règles par défaut de Betterleaks suffisamment efficaces pour permettre aux chercheurs et aux analystes de trier les résultats de secrets génériques à grande échelle.
Pourquoi certaines clés sont considérées comme publiables (pas si secrètes)
De nombreux fournisseurs SaaS et cloud créent des identifiants pour les utilisateurs qui sont conçus pour être publics. Stripe, le processeur de paiement, fournit aux utilisateurs plusieurs types de clés, y compris une "clé API publiable". Ces clés sont conçues pour être "placées dans le code front-end".
Une règle de détection de secret générique le ferait probablement apparaître comme un secret candidat. Il a une entropie élevée, est situé près de mots-clés comme "api_key", et ressemble généralement à un identifiant. Mais ce n'est pas un vrai secret. Il est destiné à être public, et ce n'est pas quelque chose qu'un chercheur ou un analyste devrait perdre son temps à examiner manuellement.
Nous avons donc écrit une expression régulière pour supprimer ce type de clé des résultats de secrets génériques de Betterleaks.
Mais Stripe n'est qu'un type de clé parmi d'autres. Nous devions faire évoluer ce processus. Nous avons recherché les types de credentials les plus courants conçus pour la publication et créé manuellement des signatures de détection pour chacun. Oui, manuellement. L'IA s'est avérée étonnamment inutile pour cette tâche.
Réduire les taux de faux positifs parmi les secrets génériques
Après des heures à ajouter manuellement ces expressions, nous voulions voir si cela en valait la peine. Pour mesurer le changement, nous avons téléchargé 100 Go depuis Common Crawl et l'avons scanné deux fois avec Betterleaks. Une fois avec les nouvelles signatures, une fois sans.
Les nouvelles signatures de credentials publiables ont réduit les faux positifs de 2,37 %. Dans notre jeu de données, cela représentait 27 886 secrets de moins à examiner manuellement.
Cela coûte environ 5 % de temps de scan supplémentaire, mais éviter autant de faux positifs en vaut largement la peine.
Votre taux de réduction variera en fonction des données que vous scannez. Common Crawl est orienté vers le HTML et le JavaScript front-end, exactement là où résident les credentials publiables, il est donc probable que cela gonfle nos résultats. Quoi qu'il en soit, chaque clé publiable que le filtre supprime est une clé qu'un chercheur ou un analyste n'aura jamais à trier.
Public ne signifie pas toujours sûr
Le défi avec cette approche est que les identifiants publiables ne signifient pas nécessairement qu'il n'y a aucun risque. Chaque type de clé nécessite un examen manuel de sa forme et des 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 quiconque envisage de soumettre une PR pour en ajouter d'autres (n'hésitez pas !).
Forme unique : facile
Ceux-ci sont faciles. Le credential publiable a une forme unique et reconnaissable. Nous écrivons une expression régulière unique et sommes convaincus que cela n'exclura aucun secret générique potentiellement valide.
Pas de forme unique : nécessite un contexte
Ce sont des chaînes de caractères qui pourraient littéralement apparaître n'importe où. Il peut s'agir d'un UUID, ou simplement de 32 caractères hexadécimaux. Le format seul n'identifie pas cette chaîne comme un type de credential publiable. Dans ces cas, nous nous appuyons sur un mot-clé proche confirmant qu'il appartient à une plateforme SaaS ou un fournisseur cloud spécifique.
Cette approche n'est pas nouvelle. Nous le faisons tout le temps pour les credentials secrets.
Même forme qu'un secret : nécessite un liveness check
C'est un défi. Certains fournisseurs SaaS décident de créer des identifiants secrets et publiables avec exactement le même format. Honnêtement, nous aimerions qu'ils ne fassent pas cela. Cela rend la détection de secrets plus difficile et perturbe les utilisateurs. Mais nous en avons rencontré beaucoup.
Dans ces cas, la seule façon de supprimer en toute sécurité le type de clé publiable est d'ajouter une signature de détection (avec une requête de vérification de vitalité HTTP) pour le credential secret.
Étant donné que les clés publiables et secrètes ont la même forme, la signature de détection du type de clé secrète détecterait les deux, et après une vérification de vitalité, déterminerait que la clé publiable n'est pas un secret, et la rejetterait.
Sensible uniquement si mal configuré : nécessite un liveness check
Il existe certains types de clés que les fournisseurs SaaS et cloud émettent où, selon qu'un utilisateur a ajouté une permission particulière, la clé peut être soit sensible, soit sans risque. J'ai beaucoup écrit sur les clés API Google et leur capacité à accéder à Gemini. C'est un cas. Mais j'ai observé ce schéma avec les clés Algolia et d'autres.
Dans ces situations, la meilleure approche est similaire à celle que nous adoptons lorsque nous constatons des collisions de format entre les clés publiables et secrètes : nous envoyons un liveness check pour déterminer si elle peut accéder à des informations sensibles.
Identifiants de test : nécessite un triage manuel
Certaines plateformes SaaS, comme Stripe, fournissent aux utilisateurs un environnement de test ou de sandbox. Au début, nous avons envisagé de supprimer catégoriquement ces résultats des résultats génériques de détection de secrets.
Cependant, en y regardant de plus près, il est devenu évident que certaines organisations placent des données de production dans leurs environnements de test. Et bien qu'une clé Stripe de sandbox divulguée ne puisse pas envoyer des milliers de dollars au compte d'un acteur malveillant, elle pourrait donner à un acteur malveillant accès aux PII des clients ou à d'autres données internes importantes. Étant donné que nous ne pouvons pas savoir si un credential de test donne accès à des données internes sensibles, nous laissons ces résultats dans les découvertes et nous nous appuyons sur un triage manuel.
Corriger la détection de secrets génériques étape par étape
La détection générique de secrets est un problème de filtrage, et le filtrage est remporté par une série de petites victoires cumulées. Nous commençons par supprimer ce dont nous sommes certains. Notre espoir est 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 des résultats génériques. Essayez-le !
