Geheimnisse durchsickern lassen: Ein Schritt zum Todsaster

Die Schlüssel Ihres Hauses Kriminellen zu überlassen, ist definitiv keine gute Idee. Aber genau das passiert häufig in den meisten Organisationen, die moderne Software entwickeln.

In diesem ersten Beitrag zum Thema Geheimnislecks analysieren wir, warum dies so häufig vorkommt, welche Folgen dies hat und welche Maßnahmen zur Vorbeugung oder Eindämmung des Problems sowie zum Umgang mit Geheimnislecks zu ergreifen sind.

OMG! Ich habe meine Cloud-Zugriffsschlüssel in ein öffentliches Repository übertragen

Fest codierte Geheimnisse in Quellcode oder Konfigurationsdateien in DevOps-Tools können in die falschen Hände geraten. Wenn das Geheimnis commitWenn Sie in einem öffentlichen Quellcode-Repository gespeichert sind, sind Sie auf jeden Fall verloren. Aber auch private Repositorien sind nicht sicher, da Geheimnisse auch durch Anwendungsbinärdateien, Protokolle oder gestohlenen Quellcode verloren gehen.

Im Nachhinein ist es beunruhigend wie oft ein einfaches Versehen zu einer schwerwiegenden Sicherheitsverletzung geführt hat. Googlen Sie einfach „AWS-Schlüssellecks–GitHub-Zugriffstoken-Lecks“, und so weiter. Betrachten Sie diese Beispiele nicht als versteckte Empfehlungen für diesen oder jenen Anbieter. Nutzen Sie Ihre eigenen!

Zum Beispiel der (berüchtigte) Codecov-Angriff vom April 2021 war möglich, weil das Codecov-Docker-Image Git-Anmeldeinformationen enthielt, die es einem Angreifer ermöglichten, auf die privaten Git-Repositorys von Codecov zuzugreifen und dem Bash-Uploader-Skript von Codecov eine einzelne Zeile zum Sammeln von Umgebungsvariablen und Git-Repository-URLs hinzuzufügen.

Denken Sie daran, dass ein Teil der Beute bei Angriffen aus den Geheimnissen besteht, die den Zugriff auf zusätzliche Systeme ermöglichen, und dass bei vielen Angriffen viel Wert auf die Exfiltration von Anmeldeinformationen, kryptografischen Schlüsseln und Token gelegt wird. 

Das Problem ist, dass hartcodierte Geheimnisse sind an der Tagesordnung. Im März 2022 der Lapsus$ APT 189 GB durchgesickert des Quellcodes von Samsung und anderer sensibler Dateien. Die Analyse ergab, dass es einige 6,600 fest codierte Geheimnisse: 90 % für interne Systeme, aber 10 % für externe Dienste und Tools wie GitHub, AWS oder Google. Zu diesen Geheimnissen gehörten AWS-/Twilio-/Google-API-Schlüssel, Datenbankverbindungszeichenfolgen und andere vertrauliche Informationen. Dies ist in den meisten Codebasen der Stand der Technik.

Lecks von Geheimnissen sind der einfachste Weg für Angriffe auf die Lieferkette

Paketabhängigkeiten sind derzeit das häufigste, wenn auch nicht das einzige Ziel von Supply-Chain-Angriffen. Die Bösewichte könnten ein neues Paket erstellen, das in der Software der Opfer installiert wird (mit Typosquatting und andere Techniken), aber typischerweise versuchen sie, ein bestehendes Paket zu infizieren, indem sie entweder Änderungen am Quellcode in Software-Repositories vornehmen (SCM) wie GitHub, GitLab oder BitBucket oder durch Hinzufügen bösartiger Versionen zu öffentlichen Registern wie NPM, PyPI, RubyGems, Maven Central.

Aber das Einfügen von bösartigem Code oder einer bösartigen Abhängigkeit, die in einem komplizierten Abhängigkeitsdiagramm versteckt ist, erfordert login Anmeldeinformationen wie Benutzername/Passwort, Token oder Zugriffsschlüssel (nennen wir sie „Tasten” kurz) für das Zielquell-Repository bzw. das öffentliche Register. 

Manchmal gelangen die Bösewichte an die Schlüssel über Social Engineering. Der Angriff auf die event-stream Ein beliebtes NPM-Paket ist ein schönes Beispiel. Aber die Suche nach durchgesickerten login Anmeldeinformationen oder Zugriffsschlüssel sind die am häufigsten vorkommende Angriffstechnik bei Angriffen auf die Software-Lieferkette.

Quellrepositorys und Paketregister sind zwei wesentliche Systeme beim Software-Build pipeline. Aber es gibt viele Tools in DevOps: CI/CD Systeme, Tools für Testdurchführung, Konfigurations- und Bereitstellungsautomatisierung sowie Bereitstellung und Release. All diese Tools können missbraucht werden, um Schadcode in Software einzuschleusen. Das Leaken gültiger Schlüssel für diese Tools führt direkt zu Leid und Qual. Stellen Sie sich vor, Root-Zugriffsschlüssel mit voller Kontrolle über Ihre öffentlichen Cloud-Ressourcen würden verloren gehen …

Die üblichen Empfehlungen

Wir sagen hier nichts Neues, das wissen Sie alle. Aber handeln Sie! Denken Sie daran, dass Bots regelmäßig alle öffentlichen SCM Repositorien. Einige Empfehlungen, in keiner bestimmten Reihenfolge.

• Wenn Sie für das IT-Sicherheitsmanagement verantwortlich sind, Definieren Sie, wie mit Geheimnissen umgegangen werden soll in der Sicherheitsrichtlinie. Richtlinien sind jedoch nur so gut wie ihre Durchsetzung: Stellen Sie sicher, dass in Ihrem Unternehmen eine Richtlinie zum Umgang mit Geheimnissen durchgesetzt wird – und zwar nicht nur bei Ihren DevOps-Teams, sondern auch bei Ihren Softwarelieferanten – und dass der Vorfallreaktionsplan Ihres Unternehmens Bestimmungen für Vorfälle mit Geheimnislecks enthält.
• Implementieren und Durchsetzen Multi-Faktor-Authentifizierung (MFA, 2FA oder welches Akronym auch immer). Und keine Abstriche bei der Sicherheit: Ein USB-Sicherheitsschlüssel ist die paar Dollar wert, die er kostet. Sie müssen Ihre Tausenden von Anmeldeinformationen per Git-Push übertragen (einfach) und sich dann betrinken und Ihre Schlüssel in einer Bar mit etwas hinterlassen, das auf Sie verweist (die Wahrscheinlichkeit ist nur etwas geringer, insbesondere wenn Sie Abstinenzler sind).
• Verwenden Sie einen Passwort-Manager mit einem starken, nicht gespeicherten Passwort. Für den Umgang mit Geheimnissen in Systemen verwenden Sie Geheime Tresore. CI/CD Systeme, Cloud-Anbieter, SCMs und andere DevOps-Tools bieten diesen Dienst, Sie können sich jedoch für eine generische Secret Vault-Lösung entscheiden.
• Bevorzugen kurzlebig Tokens zu langlebigen Zugangsschlüsseln. Sie sind leichter zu widerrufen und bieten dem Bösen weniger Angriffsfläche.
• Beschränken Sie die Wiederverwendung von Anmeldeinformationen: Angreifer verwenden die gesammelten Anmeldeinformationen für ein Ziel in anderen Systemen wieder, ein weiterer Grund für die Verwendung eines Passwort-Managers. Passwort-Manager und geheime Tresore sollten die Wiederverwendung von Anmeldeinformationen der Vergangenheit angehören lassen.
• Begrenzen und überwachen Sie die Nutzung von Admin Passwörter. Sie sind so mächtig, dass sie eine besondere Überwachung verdienen.
• Implementierung starkes Hashing und Verschlüsselung. Zurück zu USB-Schlüsseln (kryptografischen Schlüsseln), strengen Verfahren zur Übermittlung von Anmeldeinformationen an Partner und Mitarbeiter usw.
• Verwenden Geheimnisse Scanner, beispielsweise in einem pre-commit Haken um Lecks in Versionskontrollsystemen zu vermeiden, als Sicherheitstor. Vor der Sache ist hier wichtig. Alternativ können Sie Post-hoc-Scans verwenden, um geleakte Geheimnisse zu erkennen, beispielsweise als Kontrolle vor pull request Zusammenführungen. Hinweis: Unsere Xygeni-Plattform umfasst einen Geheimnisscanner, der beide Betriebsarten ermöglicht. 
• Die manuelle Alternative zur Verwendung Code-Bewertungen Die Suche nach hartcodierten Geheimnissen ist mit höheren Kosten verbunden und funktioniert nachträglich.commit (aber hoffentlich zumindest bevor das Geheimnis für Außenstehende zugänglich ist). Durch Überprüfungen können jedoch auch unkonventionelle Geheimnisse aufgedeckt werden, die den Geheimnisscannern entgehen könnten.       
• Vermeiden Sie versehentlich commitgemeinsame Dateien mit Geheimnissen zur Versionskontrolle mit entsprechenden Muster ausschließen (wie `gitignore`-Vorlage), unter Berücksichtigung von Dateien wie .env, .npmrc, .pypirc, temporäre Dateien … Tatsächlich eine zusätzliche Schicht in der Sicherheitszwiebel.
• Und das letzte in dieser langen Liste: Lassen Sie die Cloud-Anbieter Scans durchführen, um ihre Schlüssel zu finden, sofern diese verfügbar sind. Zumindest ist dies Mai Sie werden über das Leck informiert, wenn es passiert ist, aber Sicherheit ist ein Muss für Cloud-Anbieter. Dies Post-hoc- Beim geheimen Scannen ist nicht sehr transparent, wo und wie oft der Scan ausgeführt wird, und es ist oft eine explizite Einrichtung erforderlich, aber es ist sicherlich die letzte Möglichkeit, wenn alles andere fehlschlägt.

OMG! Ich habe meine Cloud-Zugriffsschlüssel in ein öffentliches Repository übertragen, Versuch Nr. 2

Das könnte auch den Besten von uns passieren. Krempeln Sie die Ärmel hoch!

Erneuern / widerrufen / deaktivieren Sie das durchgesickerte Geheimnis sofort! Wenn das Konto über eine anständige MFA verfügt, ist das Risiko viel geringer. Das könnte beispielsweise bei privaten Schlüsseln auf Websites schwieriger sein (Sie müssen ein neues Zertifikat für einen neuen privaten Schlüssel ausstellen und das vorhandene widerrufen), aber moderne Tools bieten eine schnelle Möglichkeit, Anmeldeinformationen zu erneuern oder Token zu widerrufen. 

Befolgen Sie die vom Anbieter empfohlenen Schritte, sofern verfügbar, wie AWS in diesem Beispiel.

Identifizieren Sie die Ursache des Lecks. Zu wissen, wie es passiert ist, ist für die Offenlegung, Analyse, Eindämmung und die Nutzung von Lehren aus der Leckage von entscheidender Bedeutung.

Melden Sie das Leck dann den betroffenen Parteien und erläutern Sie die Maßnahmen, die Sie ergreifen, um das Leck zu schließen und den Schaden zu begrenzen. Der entstandene Schaden lässt sich nicht mehr rückgängig machen. Was durchgesickert ist, ist durchgesickert. Seien Sie transparent und informieren Sie andere, damit diese Maßnahmen ergreifen können. 

Dann beginnen Sie mit dem Forensik. Der Belichtungsfenster ist die Zeit zwischen dem Leck und dem Zeitpunkt, als das Geheimnis nicht mehr gültig war. Seien Sie bereit, während dieses Zeitraums Protokolle zu lesen und ungewöhnliche Aktivitäten mit dem betroffenen Konto zu verfolgen. Entfernen Sie Konten und Schlüssel, die mit dem betroffenen Konto generiert wurden. Denken Sie daran, dass die Behebung viel komplexer ist, wenn das betroffene Konto über Administratorrechte verfügt. 

Umschreiben des Verlaufs (Versionskontrolle) ist komplex. Sogar totalitäre Staaten versuchen dies vergeblich (Wortspiel beabsichtigt). Und wahrscheinlich irrelevant: Die Hacker oder Bots auf öffentlichen Repos könnten das Repo geklont haben oder das Gold bereits extrahiert haben, insbesondere wenn das Offenlegungsfenster groß genug ist. 

Wenn Sie abenteuerlustig sind und selbst testen möchten, wie lange es dauert, bis Bots ein durchgesickertes Geheimnis entdecken, können Sie Stolperdrähte wie Kanarische Token lassen Sie experimentieren. Denken Sie daran, Bots blacklisten die Standard canarytokens.org Domain…

Um mehr zu lesenKovacs, E. “Tausende geheime Schlüssel im durchgesickerten Samsung-Quellcode gefunden„. Security Week, März 2022. Dyjak, A. „Vor ein paar Tagen habe ich ein kleines Experiment durchgeführt WRT Geheimnisse commited zu öffentlichen Git-Repositories …„. Tweet-Thread, November 2020. Rzepa, P. „AWS-Zugriffsschlüsselleck im GitHub-Repository und einige Verbesserungen bei der Reaktion von Amazon„. Medium, November 2020.