Dieser Artikel wurde gemeinsam verfasst von Zach Rice und Joe Leon, beide bei Aikido .
tl;dr: Manche Anmeldedaten sind eigentlich öffentlich, werden von Secret-Scannern jedoch weiterhin als generische secrets markiert. Wir haben für die häufigsten Fälle Ausblendungsregeln erstellt und die Anzahl der Fehlalarme um ca. 2 % reduziert. Diese Regeln sind nun standardmäßig in Betterleaks enthalten.
Secrets basieren auf regulären Ausdrücken. Jedes Muster zielt auf einen bestimmten Typ von Anmeldedaten ab, wie beispielsweise einen AWS-Geheimzugriffsschlüssel, einen GitHub-PAT oder ein Stripe-Token. Sobald der Scanner ein potenzielles Geheimnis identifiziert hat, führt er eine Echtheitsprüfung durch, indem er beispielsweise eine HTTP-Anfrage sendet, um zu überprüfen, ob die Anmeldedaten noch gültig sind.
Dieser Workflow bricht ab, wenn Secret-Scanner versuchen, generische secrets zu identifizieren. Generische secrets API-Schlüssel und Anmeldedaten, die keine eindeutige oder bekannte Signatur aufweisen. Die Scanner können zwar weiterhin reguläre Ausdrücke verwenden, um sie zu finden, doch anstatt nach einer Übereinstimmung mit einem bekannten Format für Anmeldedaten zu suchen, verwenden sie ein generisches Muster, um alles zu erfassen, was so aussieht, als könnte es ein Geheimnis sein.
Reduzierung von „Noise“ secrets und das Problem mit regulären Ausdrücken
Es ist relativ einfach, einen ausgeklügelten regulären Ausdruck zu schreiben, um Zeichenfolgen im Code (und an anderen Stellen) aufzuspüren, die wie secrets aussehen. Ohne eine vordefinierte Überprüfung der Aktualität kann der Scanner jedoch nicht eindeutig feststellen, ob es sich bei einem generischen Geheimnis tatsächlich um ein aktuelles Geheimnis handelt.
Bei diesem Ansatz müssen die Nutzer die Fehlalarme manuell aussortieren. Das macht aber keinen Spaß. Deshalb werden wir in den nächsten Monaten eine Reihe von Funktionen zur Rauschunterdrückung einführen:
- Filterung nach Token-Effizienz (letzter Beitrag)
- Sperrliste für veröffentlichbare Anmeldedaten (dieser Beitrag)
- secrets für öffentliche secrets
- Aufteilung der allgemeinen Regeln in zwei Typen: Tokens und Benutzernamen/Passwörter
- ML-gestützte triage
Wir möchten die Schritte in genau dieser Reihenfolge durchführen, da wir so viele Fehlalarme wie möglich auf kostengünstige Weise beseitigen und anschließend aufwendige ML-Vorgänge für die verbleibenden Unklarheiten einsetzen wollen. Das Ergebnis wird zwar nie perfekt sein, aber wir sind secrets überzeugt, secrets generische secrets das größte Potenzial beim secrets secrets . Hier haben Forscher die besten Chancen, neue Erkenntnisse zu gewinnen, und Sicherheitsverantwortliche können Bedrohungsakteure einen Schritt voraus sein. Das Ziel dieser Serie ist es, die Standardregeln von Betterleaks so zu optimieren, dass Forscher und Analysten die Ergebnisse triage Geheimnissen in großem Maßstab triage können.
Warum manche Schlüssel als veröffentlichbar (nicht ganz so geheim) gelten
Viele SaaS- und Cloud-Anbieter generieren für ihre Nutzer Zugangsdaten, die für die öffentliche Nutzung vorgesehen sind. Der Zahlungsdienstleister Stripe stellt seinen Nutzern verschiedene Schlüsseltypen zur Verfügung, darunter einen „veröffentlichbaren API-Schlüssel“. Diese Schlüssel sind dafür gedacht, „in den Frontend-Code eingefügt zu werden“.
Eine allgemeine Regel zur Erkennung von Geheimnissen würde dies wahrscheinlich als potenzielles Geheimnis identifizieren. Es weist eine hohe Entropie auf, befindet sich in der Nähe von Schlüsselwörtern wie „api_key“ und sieht ganz allgemein wie eine Anmeldeinformation aus. Aber es handelt sich nicht um ein tatsächliches Geheimnis. Es ist für die Öffentlichkeit bestimmt, und Forscher oder Analysten sollten ihre Zeit nicht damit verschwenden, es manuell zu überprüfen.
Also haben wir einen regulären Ausdruck geschrieben, um diesen Schlüsseltyp aus den generischen Geheimnisergebnissen von Betterleak zu entfernen.
Aber Stripe ist nur eine Art von Schlüssel. Wir mussten diesen Prozess ausweiten. Wir haben die gängigsten, von vornherein öffentlich konzipierten Arten von Zugangsdaten untersucht und für jede davon manuell Erkennungssignaturen erstellt. Ja, manuell. KI war bei dieser Aufgabe überraschenderweise nutzlos.
Senkung der Falsch-Positiv-Rate bei generischen secrets
Nachdem wir diese Ausdrücke stundenlang manuell hinzugefügt hatten, wollten wir herausfinden, ob sich der Aufwand gelohnt hatte. Um die Veränderung zu messen, haben wir 100 GB Daten von Common Crawl heruntergeladen und diese zweimal mit Betterleaks gescannt – einmal mit den neuen Signaturen, einmal ohne.
Die neuen Signaturen für veröffentlichbare Anmeldedaten reduzierten die Anzahl der Fehlalarme um 2,37 %. In unserem Datensatz bedeutete dies, dass 27.886 secrets weniger manuell überprüft secrets .
Das kostet zwar etwa 5 % mehr Scanzeit, aber die Vermeidung dieser vielen Fehlalarme lohnt sich auf jeden Fall.
Ihre Reduktionsrate hängt von den von Ihnen gescannten Daten ab. Common Crawl konzentriert sich vor allem auf Frontend-HTML und JavaScript – also genau dort, wo veröffentlichbare Anmeldedaten zu finden sind –, was unsere Ergebnisse wahrscheinlich verzerrt. So oder so: Jeder veröffentlichbare Schlüssel, den der Filter entfernt, ist einer, den ein Forscher oder Analyst nicht mehr triage muss.
Öffentlich heißt nicht immer sicher
Die Herausforderung bei diesem Ansatz besteht darin, dass veröffentlichbare Anmeldedaten nicht zwangsläufig bedeuten, dass kein Risiko besteht. Bei jedem Schlüsseltyp müssen die Struktur des Schlüssels und die damit verbundenen Zugriffsrechte im Kontext der SaaS-Plattform manuell überprüft werden. Beim Erstellen dieser Liste sind wir auf fünf Fälle gestoßen, die eine genauere Betrachtung verdienen – insbesondere für alle, die erwägen, einen PR einzureichen, um weitere Einträge hinzuzufügen (bitte tut das!).
Einzigartige Form: einfach
Das ist ganz einfach. Die veröffentlichbaren Anmeldedaten weisen eine eindeutige, unverwechselbare Struktur auf. Wir erstellen einen eindeutigen regulären Ausdruck und sind sicher, dass dadurch keine potenziell gültigen generischen secrets ausgeschlossen werden.
Keine eindeutige Form: erfordert Kontext
Das sind Zeichenfolgen, die buchstäblich überall auftauchen können. Vielleicht handelt es sich um eine UUID oder einfach nur um beliebige 32 Hexadezimalzeichen. Das Format allein reicht nicht aus, um diese Zeichenfolge als veröffentlichbaren Anmeldedaten-Typ zu identifizieren. In solchen Fällen stützen wir uns auf ein in der Nähe stehendes Schlüsselwort, das bestätigt, dass sie zu einer bestimmten SaaS-Plattform oder einem bestimmten Cloud-Anbieter gehört.
Dieser Ansatz ist nicht neu. Bei geheimen Zugangsdaten gehen wir immer so vor.
Hat dieselbe Form wie ein Geheimnis: erfordert eine Lebendigkeitsprüfung
Das ist eine knifflige Angelegenheit. Manche SaaS-Anbieter entscheiden sich dafür, geheime und öffentlich zugängliche Anmeldedaten im exakt gleichen Format zu erstellen. Ehrlich gesagt würden wir uns wünschen, dass sie das nicht tun würden. Das erschwert die Erkennung geheimer Daten und verwirrt die Nutzer. Aber wir sind auf viele solcher Fälle gestoßen.
In diesen Fällen besteht die einzige Möglichkeit, den strafbaren Schlüsseltyp sicher zu entfernen, darin, eine Erkennungssignatur (mit einer HTTP-Liveness-Check-Anfrage) für die geheime Anmeldeinformation hinzuzufügen.
Da der veröffentlichte und der geheime Schlüssel die gleiche Form haben, würde die Signatur zur Erkennung des geheimen Schlüssels beide erkennen und nach einer Lebendigkeitsprüfung feststellen, dass der veröffentlichte Schlüssel kein geheimer Schlüssel ist, und ihn verwerfen.
Nur bei falscher Konfiguration anfällig: Es ist eine Funktionsprüfung erforderlich.
Es gibt bestimmte Schlüsseltypen, die von SaaS- und Cloud-Anbietern generiert werden, bei denen der Schlüssel – je nachdem, ob ein Nutzer eine bestimmte Berechtigung hinzugefügt hat – entweder sensibel oder risikolos sein kann. Ich habe bereits ausführlich über Google-API-Schlüssel und deren Zugriffsmöglichkeiten auf Gemini geschrieben. Das ist ein Beispiel dafür. Aber ich habe dieses Muster auch bei Algolia-Schlüsseln und anderen beobachtet.
In solchen Situationen ist die beste Vorgehensweise ähnlich wie bei Formatkonflikten zwischen veröffentlichbaren und geheimen Schlüsseln: Wir senden eine Lebendigkeitsprüfung, um festzustellen, ob dadurch Zugriff auf sensible Daten möglich ist.
Testzugangsdaten: Erfordert manuelle triage
Einige SaaS-Plattformen, wie beispielsweise Stripe, stellen den Nutzern eine Test- oder Sandbox-Umgebung zur Verfügung. Zunächst hatten wir erwogen, diese Ergebnisse grundsätzlich aus den allgemeinen Ergebnissen der Geheimniserkennung herauszunehmen.
Bei genauerer Betrachtung stellte sich jedoch heraus, dass einige Organisationen Produktionsdaten in ihre Testumgebungen übertragen. Und auch wenn ein durchgesickerter Stripe-Schlüssel aus der Sandbox möglicherweise nicht ausreicht, um Tausende von Dollar auf das Konto eines Angreifers zu überweisen, könnte er einem Angreifer dennoch Zugriff auf personenbezogene Kundendaten oder andere wichtige interne Daten verschaffen. Da wir nicht wissen können, ob Testzugangsdaten Zugriff auf sensible interne Daten gewähren, behalten wir diese Ergebnisse in den Befunden bei und verlassen uns auf triage manuelle triage.
secrets generischer secrets Schritt für Schritt beheben
Die generische Erkennung geheimer Informationen ist ein Filterproblem, und beim Filtern kommt es auf eine Reihe kleiner, aufeinander aufbauender Erfolge an. Wir beginnen damit, das zu entfernen, worüber wir uns sicher sind. Wir hoffen, dass einige dieser kleinen Änderungen eine effektive generische Erkennung geheimer Informationen in großem Maßstab ermöglichen werden.
In der aktuellen Version von Betterleaks werden veröffentlichbare Schlüssel standardmäßig aus den allgemeinen Ergebnissen herausgefiltert. Probieren Sie es doch einmal aus!
