Gefahren durch gestohlene Zertifikate und private Schlüssel
Gestohlene Zertifikate und private Schlüssel könnten von Cyberkriminellen als Waffe eingesetzt werden, um in das System eines Unternehmens einzudringen. Wir haben untersucht, welche besonderen Herausforderungen ein solcher Diebstahl mit sich bringt.
Save to Folio
Im Labor wird der Alarm ausgelöst. Die XDR-Lösung des Unternehmens meldet, dass ein unbekanntes Gerät einem Netzwerk beigetreten ist. Der Administrator druckt das aktuellste Zugriffsprotokoll aus und stellt fest, dass ein VPN verwendet wurde, um mit dem privaten Schlüssel und Zertifikat eines Mitarbeiters auf das private Netzwerk des Unternehmens zuzugreifen. Er ruft den Mitarbeiter an und fragt ihn nach der angeblichen Verwendung eines nicht zertifizierten Geräts für den Zugriff auf das Netzwerk. Dieser hat jedoch kein unbekanntes Gerät verwendet sondern lediglich ein Container-Image in seine private Container-Registry gestellt.
Auf den ersten Blick mag dies unwahrscheinlich klingen. Unsere Erkenntnisse über 32 OpenVPN-Client-Konfigurationsdateien innerhalb von Container-Images belegen die Plausibilität des Szenarios, unterstützt durch unsere Langzeituntersuchung von exponierten privaten Container-Registries. Die Folgen könnten uneingeschränkten Zugang zu Servern oder privaten Netzwerken sein und Identitätsdiebstahl, Infektionen in der Lieferkette und Verstöße gegen Kundendaten.
Wir haben 2 278 eindeutige private Schlüssel extrahiert, davon 169 private SSH-Schlüssel. Bei 88 der anfälligsten privaten Schlüssel fehlt jeglicher Passwortschutz und sind damit potenziellen Sicherheitsbedrohungen ausgesetzt.
Der Angriff kann starten, wenn sich die Bedrohungsakteure Zugriff auf die private Container-Registry des Unternehmens verschaffen. Sie laden alle Images herunter und finden eine VPN-Konfiguration mit Serveradressen, Verbindungsschlüsseln und Zertifikaten ohne Passwortschutz. Diese Daten nutzen sie, um sich mit dem internen Netzwerk des Unternehmens zu verbinden.
Schlimmer noch: Ein Image enthält ein Skript, das passwortlose SSH-Schlüssel mit ihren IP-Adressen verwendet, so dass der Angreifer die interne Infrastruktur weiter infiltrieren kann.
Bild 1. Wie Bedrohungsakteure Zugriff auf die Registry erhalten könnten
Zertifikate und private Schlüssel fallen technisch gesehen unter die Kategorie „Geheimnisse“. Sie bergen eine Reihe von Risiken. Ein privater SSH-Schlüssel oder eine OpenVPN-Schlüsseldatei in einem öffentlich zugänglichen Container-Image könnte es einem Angreifer erlauben, auf andere Systeme zuzugreifen, sich als Server oder Benutzer auszugeben, verschlüsselte Kommunikation abzufangen oder gar seine Rechte in einer breiteren Umgebung zu erweitern.
Im Gegensatz zu allgemeinen Zugriffs-Token können sich kompromittierte Zertifikate und private Schlüssel als besonders schädlich erweisen, da sie es Angreifern ermöglichen, sich als vertrauenswürdige Entitäten auszugeben. Dabei geht es nicht nur um den Verlust von Anmeldedaten, sondern um den Verlust einer Identität, der das System oder die Benutzer implizit vertrauen.
Exponierte Container-Registries
Eine Container-Registry ist im Grunde ein Lager für die Speicherung von Container-Images - jedes mit seinem eigenen Code, Abhängigkeiten und Konfigurationsdetails. Wenn dieses Lager unbeabsichtigt offen gelassen wird, können böswillige Akteure eindringen und Images untersuchen.
Problem 1: Exponierte Registries oder geleakte Registry Credentials
Bei exponierten Registries sind alle Images (einschließlich solcher in der Entwicklung, Testversionen oder ältere Backups) für Bedrohungsakteure zugänglich. Sie enthalten häufig vertrauliche Informationen, wie z. B. in der Konfiguration oder in erstellten Skripts gespeicherte Credentials. Diese ermöglichen den Zugang zu internen Systemen.
Da eine Registry als Wissensbasis des Unternehmens dienen kann, könnte ihre Zugänglichkeit zu einer Lawine von Sicherheitsproblemen führen.
Problem 2: Geheimnisspeicherung
Unternehmen dürfen keine Geheimnisse in Images speichern, sondern müssen sie zur Laufzeit referenzieren. Die Implementierung von Mechanismen zum Scannen und Schützen von Geheimnissen verhindert zudem, dass Angriffe erfolgreich sein können.
Es sollte zudem automatisch davon ausgegangen werden, dass das Geheimnis auf jeden Fall einen Weg ins Image, die Codebasis usw. finden wird. Ein gewisses Maß an Vertrauen ist ebenfalls unumgänglich. Deshalb müssen die Geheimnisse verschlüsselt gespeichert werden. Die Entschlüsselung erfolgt zur Laufzeit, d. h. der Entschlüsselungsschlüssel ist nicht im Image vorhanden. Wenn also das Geheimnis nach außen dringt, wird es für die Bedrohungsakteure zu einem wertlosen Binärblob.
In unserer früheren Studie über die im DevOps-Minenfeld versteckten Bedrohungen haben wir die Wurzeln dieses Themas näher beleuchtet.
Zertifikate und private Schlüssel, eine besondere Herausforderung
Die Zertifikate und privaten Schlüssel verdienen aufgrund ihrer Eigenschaften besondere Aufmerksamkeit:
- Identität und Vertrauen - Ein SSL/TLS-Zertifikat oder ein SSH-Schlüssel ist ein Identifikator dafür, dass ein System oder ein Benutzer derjenige ist, der er vorgibt zu sein. Wenn ein Angreifer in den Besitz dieser Zertifikate gelangt, kann er sich als Server oder Benutzer ausgeben. Dies führt zu Szenarien, in denen Unternehmen eine Verbindung zu einer von einem Angreifer kontrollierten Ressource herstellen, diese aber dennoch als vertrauenswürdig ansehen, weil sie ein legitimes Zertifikat oder einen legitimen Schlüssel vorweisen.
- Langlebig und schwieriger zu erneuern - Zertifikate und private Schlüssel sind Teil einer formalen Ausstellungs- und Vertrauenskette. Ihr Widerruf und ihre Neuausstellung ist ein komplizierterer Prozess, der die Angreifbarkeitsdauer verlängert.
- Potenzial sich zu verbergen - Die Verwendung kompromittierter Zertifikate oder Schlüssel kann Angriffe ermöglichen, die viel länger verborgen bleiben, da es nicht immer einen unmittelbaren Hinweis darauf gibt, dass jemand Unbefugtes sie verwendet. Ein geschickter Angreifer kann den böswilligen Datenverkehr als legitim tarnen oder scheinbar reguläre Sitzungen einrichten.
- Regulatorische und Compliance-Risiken - In einigen Branchen, die strengen Datenschutzbestimmungen unterliegen, kann die Exponierung bestimmter Zertifikate und Schlüssel auch zu Verstößen gegen Regularien führen.
Leider können diese Dateien während der Entwicklung vergessen werden, insbesondere bei der Paketierung eines Dienstes, der lokal funktionieren muss. Eine ähnliche Situation könnte für schnelle VPN- oder SSH-Tests gelten.
Im nächsten Beitrag zum Thema geht es um die möglichen Angriffsszenarien, Auswirkungen und Best Practices für den besseren Schutz der Zertifikate und Schlüssel.