Cloud
Zertifikate und Schlüssel in den Händen Krimineller
Das Beispiel eines Angriffsszenarios, bei dem Akteure sowohl OpenVPN- und auch SSH-Schlüssel in einem Image ausnutzen konnten, zeigt eindrucksvoll den Ernst der Gefahr. Welche Best Practices sollten Unternehmen beachten, um sich zu schützen?
Save to Folio
Gestohlene Zertifikate und private Schlüssel könnten von Cyberkriminellen als Waffe eingesetzt werden, um in das System eines Unternehmens einzudringen. Wir haben bereits aufgezeigt, welche Herausforderungen Zertifikate und private Schlüssel und deren Diebstahl mit sich bringen. Um die Gefahren besser zu veranschaulichen, haben wir ein Szenario ausgewählt, dass auch einem realen Fall beruht. Wir fanden ein Image, das sowohl OpenVPN-Zertifikate (und private Schlüssel) als auch private SSH-Schlüssel enthielt, beides wesentliche Elemente der Kommunikation.
OpenVPN baut auf Zertifikate und private Schlüssel, um sichere, verschlüsselte Verbindungen aufzubauen. Wenn Angreifer in den Besitz dieser Zertifikate gelangen, können sie einen gefälschten VPN-Server einrichten, der authentisch erscheint, oder sie können sich als autorisierter Benutzer mit dem legitimen VPN eines Unternehmens verbinden. Auf diese Weise könnten sie Datenverkehr ausspähen, in andere Unternehmensnetzwerke eindringen, vertrauliche Informationen ausspähen oder einen Angriff auf die Lieferkette starten.
SSH wiederum ist der Grundstein für die sichere Fernverwaltung von Servern. Sobald ein privater SSH-Schlüssel kompromittiert ist, kann sich ein Angreifer bei den Servern oder Systemen, die dem entsprechenden öffentlichen Schlüssel vertrauen, anmelden und so die kennwortbasierte Authentifizierung vollständig umgehen. Noch schlimmer ist, dass viele Administratoren SSH-Schlüssel in mehreren Umgebungen wiederverwenden oder replizieren, so dass die Kompromittierung eines Schlüssels zur Kompromittierung zahlreicher Server und Dienste führt.
Gibt es beides in einem Image, bietet sich für Bedrohungsakteure die Gelegenheit, einen perfekten Sturm von Sicherheitsvorfällen auszulösen. Der Start wäre, sich unbefugten VPN-Zugang zu verschaffen, dann die SSH-Anmeldedaten auszuspähen und die internen Server oder gar das gesamte Netzwerk zu übernehmen. Die Folgen werden im Detail im Originalbeitrag beschrieben.
Zertifikate und private Schlüssel in erstellten Images
Wie kann es passieren, dass ein Image mit solch sensiblen Dateien darin landet? Hier sind einige häufige Szenarien.
- Fehlende Trennung zwischen der Build- und der Produktionsumgebung. Entwickler erstellen Container-Images manchmal in einer Umgebung, in der das Hostsystem Umgebungsvariablen speichert oder Datenträger mit sensiblen Schlüsseln freigibt. Durch ein Versehen in der Docker-Datei kann es passieren, dass alles aus einem Verzeichnis (einschließlich der privaten Schlüssel) in das Image kopiert wird. Wir fanden 1.653 eindeutige Docker-Dateien und 918 eindeutige Docker Compose-Dateien. Diese Dateien wurden während des Erstellungsprozesses in das
- Bequemlichkeit hat Vorrang. Die Aufnahme von SSH-Schlüsseln ins Image ermöglicht manchmal eine schnellere Fehlersuche oder Replikation der Produktionsumgebung. Dies wird oft gemacht, wenn nicht genügend Zeit da ist und die Einrichtung der Umgebung kompliziert ist.
- Konfiguration durch Kopieren und Einfügen. Bei Technologien wie VPN gibt es Docker-Dateien mit Anweisungen wie „Legen Sie Ihre Konfigurationsdateien hier ab“. Durch die einfache Wiederverwendung des Snippets kopiert die Docker-Engine beim Erstellen das gesamte Konfigurationsverzeichnis. Das Verzeichnis kann alles enthalten, vom Zertifikat über den privaten Schlüssel bis hin zur CA-Kette.
- Aufräumen übersehen. Selbst wenn jemand kurzzeitig Schlüssel zum Debuggen in den Container gelegt hat, könnte er vergessen, sie später zu entfernen. Oder man entfernt die Verweise auf sie in der Docker-Datei, vergisst aber, dass die dazwischen liegenden Build-Schichten immer noch Teil der Image-Historie sind. Wenn die Registry nicht nur das endgültige Image, sondern auch ältere Schichten speichert, sind die Schlüssel weiterhin auffindbar.
Auswirkungen
Die Auswirkungen exponierter Zertifikate und Schlüssel können schlimm sein. Nach einem Leakage können Bedrohungsakteure Folgendes tun:
- Kompromittierung von VPNs - ein falsches VPN einrichten oder einem bestehenden beitreten. Dadurch wird das interne Netzwerk des Unternehmens für bösartigen Datenverkehr und Datenexfiltration geöffnet.
- Uneingeschränkter Serverzugriff - Gehört der private SSH-Schlüssel einem privilegierten Benutzer, erhält der Angreifer volle Verwaltungsrechte für das System. Sobald er im System ist, kann er sich seitlich bewegen, Hintertüren installieren und dauerhaften Schaden anrichten.
- Man-in-the-Middle-Angriffe - insbesondere wenn der Angreifer den Datenverkehr abfängt oder Benutzer dazu bringt, eine Verbindung über einen bösartigen Proxy herzustellen.
- Benutzer-Identität - Wenn die MitM-Angriffe erfolgreich sind, können die Angreifer die Benutzeranmeldeinformationen der Kunden des Unternehmens, die mit dem System interagieren, sammeln.
- Datendiebstahl - Der erlangte Zugang ermöglicht es, weitere sensible Kunden- und/oder Unternehmensdaten zu stehlen.
- Infektion der Lieferkette - Digitale Zertifikate werden zum Signieren von ausführbaren Dateien verwendet. Wenn ein Build-Container öffentlich wird, können Bedrohungsakteure die Lieferkette infizieren, indem sie der ausführbaren Binärdatei bösartiges Verhalten hinzufügen. Die Binärdatei wird dann mit dem durchgesickerten Zertifikat signiert. Für den Kunden gibt es keine sichtbare Veränderung, bis das durchgesickerte Zertifikat abläuft oder widerrufen wird. Die allgemeine Faustregel lautet: Je mehr Geheimnisse im Container vorhanden sind, desto erfolgreicher wird der Angriff sein.
- Kunden und Partner verlieren das Vertrauen in die Sicherheitspraktiken des Unternehmens. Selbst wenn das Problem schnell behoben wird, könnte der Schaden für den Ruf des Unternehmens andauern.
Missverständnisse, auf die man achten sollte
Unabhängig von den Abhilfemaßnahmen und Sicherheitslösungen, die Unternehmen einsetzen, ist es wichtig, sich nicht von einem der folgenden Irrtümer täuschen zu lassen:
- „Mein Container ist privat. Ich bin sicher!" Registries können in Sekundenschnelle falsch konfiguriert werden. Benutzer sollten bei selbst gehosteten Container-Registries besonders vorsichtig sein, da deren Standardeinstellungen keine Authentifizierung erfordern. In dem Moment, in dem sie versehentlich für jedermann zugänglich gemacht werden, könnten Bedrohungsakteure alle Anmeldeinformationen erhalten. Das Konzept des Datenschutzes ist damit hinfällig.
- „Ich verwende Docker Ignore-Dateien. Mir geht es gut!" Die Verwendung von .dockerignore hilft dabei, das versehentliche Kopieren von Dateien zu reduzieren, aber sie ist nicht kugelsicher. Ein einziger Fehler in Ihrer Dockerdatei oder .dockerignore kann den Zweck der beabsichtigten Trennung zunichtemachen.
- „Es ist nur ein Dev/Test-Image“. Selbst wenn die Umgebung als Entwicklungs- oder Testumgebung gekennzeichnet ist, können die SSH-Schlüssel oder Zertifikate immer noch an ein Produktionssystem gebunden sein oder andere Netzwerkressourcen freischalten. Angreifer können aus Entwicklungs-Images wertvolle Erkenntnisse gewinnen, die ihnen helfen, in die Produktionsumgebung einzudringen.
- „Ich werde die Datei später entfernen“. Später heißt nie. Intermediäre Image-Schichten können den Dateiverlauf enthalten. Wenn Sie also nicht ordnungsgemäß mit mehrstufigen Builds umgehen oder Schichten entfernen, sind die Daten möglicherweise immer noch in der Abbildschichtstruktur zu finden.
Risikominderung und Best Practices
Eine Kombination aus strengen Prozessen, Codeüberprüfungen, Scan-Lösungen und achtsamen Entwicklungspraktiken führt zu einem geringeren Risiko. Einige Empfehlungen:
Geheimnisse vollständig aus Images raushalten
Geheimnisse oder Anmeldeinformationen, einschließlich Zertifikate und private Schlüsseln, sollten niemals in ein Container-Image integriert werden. Stattdessen empfiehlt sich die Verwendung von Umgebungsvariablen oder von Lösungen zur Verwaltung von Geheimnissen (wie HashiCorp Vault, AWS Secrets Manager oder Docker/Kubernetes Secrets), die Credentials zur Laufzeit einfügen.
Image-Scanning implementieren
Es gibt Tools, die Container-Images nach Geheimnissen, kryptografischen Schlüsseln oder sogar verdächtigen Dateinamen durchsuchen können. Integrieren Sie diese Scanning-Schritte in die CI/CD-Pipeline, um ungeschützte Dateien abzufangen, bevor sie in einer Registry landen.
Mehrstufige Builds verwenden
Die mehrstufigen Builds von Docker ermöglichen es, das endgültige Image sauber zu halten. Die Entscheidung, nur notwendige Artefakte in die Produktionsphase zu kopieren, garantiert, dass Entwicklungs- oder Debugging-Schlüssel niemals in das endgültige Image gelangen.
Stellen Sie sicher, dass Registries standardmäßig privat sind und erzwingen Sie eine strenge Zugriffskontrolle. Verwenden Sie eine starke Authentifizierung und rollenbasierte Berechtigungen, um sicherzustellen, dass nur vertrauenswürdige Mitarbeiter und Systeme Images abrufen oder übertragen können.
Verschlüsseln von Geheimnissen
Gehen Sie davon aus, dass das Geheimnis einen Weg zum Image, zur Codebasis usw. findet. Ein gewisses Maß an Vertrauen muss jedoch da sein. Dazu sollte sichergestellt sein, dass die Geheimnisse verschlüsselt gespeichert werden. Die Entschlüsselung erfolgt zur Laufzeit, d. h. der Entschlüsselungsschlüssel ist nicht im Image vorhanden. Infolgedessen ist das geleakte Geheimnis für den Bedrohungsakteur nur ein wertloser binärer Blob.
Proaktive Sicherheitslösung
Der Trend Micro Artifact Scanner (TMAS) führt vor der Laufzeit Image-, Schwachstellen-, Malware- und Secret-Scans für bestimmte Artefakte durch. So können Sie Probleme erkennen und beheben, bevor sie eine Produktionsumgebung erreichen. TMAS ist Teil von Trend Vision One™, eine KI-gestützten Cybersicherheitsplattform für Unternehmen, die das Management von Cyberrisiken, den Sicherheitsbetrieb und einen robusten mehrschichtigen Schutz zentralisiert.