Dieser Artikel wurde gemeinsam von Zach Rice und Joe Leon, beide bei Aikido Security, verfasst.
tl;dr Einige Zugangsdaten sind öffentlich gedacht, werden aber von Secret-Scannern trotzdem als generische Secrets gekennzeichnet. Wir haben Unterdrückungsregeln für die häufigsten Fälle erstellt und die Fehlalarme um ca. 2 % reduziert. Diese Regeln sind jetzt standardmäßig in Betterleaks enthalten.
Secret-Scanner basieren auf regulären Ausdrücken. Jedes Muster zielt auf einen bestimmten Typ von Zugangsdaten ab, wie einen AWS Secret Access Key, einen GitHub PAT oder ein Stripe Token. Sobald der Scanner ein potenzielles Secret identifiziert, führt er einen Liveness-Check durch, indem er beispielsweise eine HTTP-Anfrage sendet, um zu überprüfen, ob die Zugangsdaten aktiv sind.
Dieser Workflow bricht zusammen, wenn Secret-Scanner versuchen, generische Secrets zu identifizieren. Generische Secrets sind API-Schlüssel und Zugangsdaten, die keine eindeutige oder bekannte Signatur aufweisen. Die Scanner können weiterhin einen regulären Ausdruck verwenden, um sie zu finden, aber anstatt ein bekanntes Zugangsdatenformat abzugleichen, verwenden sie ein generisches Muster, um alles zu erfassen, was wie ein Secret aussehen könnte.
Rauschunterdrückung beim Secrets-Scan und das Problem mit regulären Ausdrücken
Es ist relativ einfach, einen ausgeklügelten regulären Ausdruck zu schreiben, um Strings in Code (und an anderen Stellen) zu finden, die wie Secrets aussehen. Aber ohne einen vordefinierten Liveness-Check kann der Scanner nicht eindeutig feststellen, ob ein generisches Secret tatsächlich ein Live-Secret ist.
Dieser Ansatz zwingt Benutzer dazu, False Positives manuell zu durchsuchen. Aber das macht keinen Spaß. Daher werden wir in den nächsten Monaten eine Reihe von Rauschunterdrückungsschichten veröffentlichen:
- Token-Effizienzfilterung (letzter Beitrag)
- Denylist für veröffentlichbare Credentials (dieser Beitrag)
- Denylist für öffentliche Secrets
- Aufteilung generischer Regeln in zwei Typen: Tokens und Benutzernamen/Passwörter
- ML-gestützte Triage
Wir möchten die Dinge in dieser bestimmten Reihenfolge tun, da wir so viele False Positives wie möglich kostengünstig eliminieren und dann teure ML-Operationen für die verbleibende Ambiguität nutzen wollen. Es wird niemals perfekt sein, aber wir glauben, dass generische Secrets die größte Chance beim Secrets-Scan bieten. Es ist der beste Ort für Forschende, um neuartige Erkenntnisse aufzudecken, und für Verteidiger, um Bedrohungsakteuren einen Schritt voraus zu sein. Das Ziel dieser Reihe ist es, die Standardregeln von Betterleaks so gut zu machen, dass Forschende und Analysten generische Secret-Ergebnisse im großen Maßstab triagieren können.
Warum einige Schlüssel als veröffentlichbare (nicht ganz so geheime) Schlüssel gelten
Viele SaaS- und Cloud-Anbieter erstellen Credentials für Benutzer, die öffentlich sein sollen. Stripe, der Zahlungsdienstleister, stellt Benutzern verschiedene Schlüsseltypen zur Verfügung, darunter einen „Publishable API Key“. Diese Schlüssel sind dafür konzipiert, „in Frontend-Code platziert zu werden“.
Eine generische Secret-Erkennungsregel würde dies wahrscheinlich als Kandidaten-Secret identifizieren. Es hat eine hohe Entropie, befindet sich in der Nähe von Keywords wie „api_key“ und sieht generell wie ein Credential aus. Aber es ist kein echtes Secret. Es ist dazu bestimmt, öffentlich zu sein, und es ist nichts, womit ein Forscher oder Analyst seine Zeit mit manueller Überprüfung verschwenden sollte.
Daher haben wir einen regulären Ausdruck geschrieben, um diesen Schlüsseltyp aus den generischen Secret-Ergebnissen von Betterleaks zu entfernen.
Stripe ist jedoch nur ein Schlüsseltyp. Wir mussten diesen Prozess skalieren. Wir haben die gängigsten „public-by-design“-Credential-Typen recherchiert und manuell Erkennungssignaturen für jeden erstellt. Ja, manuell. KI war für diese Aufgabe überraschend nutzlos.
Reduzierung der False-Positive-Raten bei generischen Secrets
Nach stundenlangem manuellem Hinzufügen dieser Ausdrücke wollten wir sehen, ob es sich lohnte. Um die Änderung zu messen, luden wir 100 GB von Common Crawl herunter und scannten sie zweimal mit Betterleaks. Einmal mit den neuen Signaturen, einmal ohne.
Die neuen „publishable-credential“-Signaturen reduzierten False Positives um 2,37 %. In unserem Datensatz waren das 27.886 weniger Secrets, die manuell überprüft werden mussten.
Es kostet etwa 5 % mehr Scanzeit, aber die Vermeidung so vieler False Positives ist es absolut wert.
Ihre Reduktionsrate variiert je nach den gescannten Daten. Common Crawl tendiert zu Front-End-HTML und JavaScript, genau dort, wo veröffentlichbare Anmeldeinformationen zu finden sind, was unsere Ergebnisse wahrscheinlich aufbläht. So oder so ist jeder veröffentlichbare Schlüssel, den der Filter entfernt, einer, den ein Researcher oder Analyst niemals manuell überprüfen muss.
Öffentlich bedeutet nicht immer sicher
Die Herausforderung bei diesem Ansatz besteht darin, dass veröffentlichbare Zugangsdaten nicht unbedingt bedeuten, dass kein Risiko besteht. Jeder Schlüsseltyp erfordert eine manuelle Überprüfung der Schlüsselform und der ihm gewährten Zugriffsrechte im Kontext der SaaS-Plattform. Beim Erstellen dieser Liste sind wir auf fünf Fälle gestoßen, die einer Überprüfung wert sind, insbesondere für alle, die in Erwägung ziehen, einen PR einzureichen, um weitere hinzuzufügen (bitte tun Sie das!).
Einzigartige Form: einfach
Diese sind einfach. Die veröffentlichbare Anmeldeinformation hat eine einzigartige, unverkennbare Form. Wir schreiben einen einzigartigen regulären Ausdruck und sind zuversichtlich, dass dies keine potenziell gültigen generischen Secrets ausschließt.
Keine einzigartige Form: benötigt Kontext
Dies sind Zeichenketten, die buchstäblich überall auftauchen könnten. Vielleicht ist es eine UUID oder einfach 32 Hexadezimalzeichen. Das Format allein identifiziert diese Zeichenkette nicht als veröffentlichbaren Anmeldeinformationstyp. In diesen Fällen verlassen wir uns auf ein nahegelegenes Schlüsselwort, das bestätigt, dass es zu einer bestimmten SaaS-Plattform oder einem Cloud-Anbieter gehört.
Dieser Ansatz ist nicht neu. Wir tun dies ständig für geheime Anmeldeinformationen.
Gleiche Form wie ein Secret: benötigt einen Liveness-Check
Das ist schwierig. Einige SaaS-Anbieter prägen Secrets und öffentlich zugängliche Zugangsdaten im exakt gleichen Format. Ehrlich gesagt, wünschen wir uns, dass sie das nicht tun würden. Es erschwert die Secret-Erkennung und verwirrt die Benutzer. Aber wir sind auf viele solcher Fälle gestoßen.
In diesen Fällen ist der einzige Weg, den veröffentlichbaren Schlüsseltyp sicher zu entfernen, eine Erkennungssignatur (mit einer HTTP-Liveness-Check-Anfrage) für die geheime Anmeldeinformation hinzuzufügen.
Da die veröffentlichbaren und geheimen Schlüssel die gleiche Form haben, würde die Erkennungssignatur für den geheimen Schlüsseltyp beide erfassen und nach einem Liveness-Check feststellen, dass der veröffentlichbare Schlüssel kein Secret ist, und ihn verwerfen.
Nur sensibel bei Fehlkonfiguration: benötigt einen Liveness-Check
Es gibt Schlüsseltypen, die von SaaS- und Cloud-Anbietern geprägt werden, bei denen der Schlüssel, je nachdem, ob ein Benutzer eine bestimmte Berechtigung hinzugefügt hat, entweder sensibel oder risikofrei sein kann. Ich habe ausführlich über Google API-Schlüssel und deren Fähigkeit, auf Gemini zuzugreifen, geschrieben. Das ist ein solcher Fall. Aber ich habe dieses Muster auch bei Algolia-Schlüsseln und anderen gesehen.
In diesen Situationen ist die beste Vorgehensweise ähnlich wie bei Formatkollisionen zwischen öffentlich zugänglichen und geheimen Schlüsseln: Wir senden einen Liveness-Check, um festzustellen, ob er auf sensible Daten zugreifen kann.
Test-Zugangsdaten: benötigt manuelle Triage
Einige SaaS-Plattformen, wie Stripe, stellen Benutzern eine Test- oder Sandbox-Umgebung zur Verfügung. Zuerst zogen wir in Betracht, diese Ergebnisse kategorisch aus den generischen Secret-Erkennungsergebnissen zu entfernen.
Bei genauerer Betrachtung wurde jedoch klar, dass einige Organisationen Produktionsdaten in ihre Testumgebungen legen. Und während ein geleakter Sandbox-Stripe-Schlüssel möglicherweise keine Tausende von Dollar an das Konto eines Bedrohungsakteurs senden kann, könnte er einem Bedrohungsakteur Zugang zu Kunden-PII oder anderen wichtigen internen Daten verschaffen. Da wir nicht wissen können, ob eine Test-Anmeldeinformation Zugang zu sensiblen internen Daten bietet, belassen wir diese Ergebnisse in den Befunden und verlassen uns auf die manuelle Triage.
Behebung der Erkennung generischer Secrets Schritt für Schritt
Generische Secret-Erkennung ist ein Filterproblem, und Filterung wird durch eine Reihe kleiner, aufeinander aufbauender Erfolge gewonnen. Wir beginnen damit, das zu entfernen, worüber wir uns sicher sind. Unsere Hoffnung ist, dass einige dieser kleinen Änderungen eine effektive generische Secret-Erkennung im großen Maßstab ermöglichen werden.
Die aktuelle Version von Betterleaks filtert veröffentlichbare Schlüssel standardmäßig aus generischen Ergebnissen heraus. Probieren Sie es aus!
