Cloud
Analyzing the Hidden Danger of Environment Variables for Keeping Secrets
While DevOps practitioners use environment variables to regularly keep secrets in applications, these could be conveniently abused by cybercriminals for their malicious activities, as our analysis shows.
Save to Folio
Die Verwendung von Umgebungsvariablen ist in der DevOps-Community eine gängige Praxis, da sie einen einfachen Zugriff auf Konfigurationseigenschaften ermöglicht. Dies ist vor allem in containerisierten Umgebungen nützlich, denn es ist bequemer, die Konfiguration als Umgebungsvariable zu übergeben. Aus Sicht der Cloud-Sicherheit jedoch sollte die Übergabe eines Geheimnisses innerhalb einer Umgebungsvariablen vermieden werden. Diese Vorgehensweise ist nämlich einfach zu implementieren, und es könnte gefährlich sein, wenn vertrauliche Informationen darin gespeichert, geleakt und/oder für Kompromittierung missbraucht werden.
Umgebungsvariablen bestehen aus einer Reihe von Schlüsselpaaren, die für eine Umgebung - in der Regel eine Shell oder eine Subshell - gelten. Diese Schlüsselpaare können auf verschiedene Weise definiert werden, wobei eine der globalen Definitionen der Befehl export ist. Umgebungsvariablen werden nicht verschlüsselt und sind innerhalb des Bereichs der Umgebung im Klartext verfügbar.
Was bedeuten diese Definitionen aus technischer Sicht? Es geht unter anderem um den Geltungsbereich, der in einigen Situationen durch das Shell-Skript oder die ausführende Umgebung und ihre Kindprozesse begrenzt wird. Bei der Verwendung von Containern wird die Grenze durch den Containerprozess und seine Kindprozesse festgelegt. Diese Eigenschaften implizieren, dass die Variablen in jeden Kindprozess kopiert werden.
Bei der Betrachtung der technischen Details fällt auf, dass die Variablen in einen Stack von laufenden Prozessen kopiert werden, die anschließend kopiert werden, um Kindprozesse zu erzeugen. Dieses Detail bedeutet, dass die Variablen auch in diesen neuen Prozess kopiert werden, wenn ein Entwickler
- eine Wrapper-Anwendung ausführt; oder
- ein Skript startet, das Umgebungsvariablen zur Konfiguration verwendet und andere Anwendungen startet, die diese Konfigurationsfelder nicht unbedingt benötigen.
Weitere technische Details umfasst der Originalbeitrag.
Verwendung von Umgebungsvariablen gefährlich für Geheimnisse?
Wir sind in einem früheren Beitrag bereits auf die Bedeutung einer ordnungsgemäßen Verwaltung von Geheimnissen eingegangen und haben dargelegt, wie unsachgemäße Praktiken den Zugang zu wichtigen Systemen ermöglichen und wie das Leaken von Geheimnissen schließlich zu einer Gefährdung der Lieferkette führen kann. Doch wie sieht die ideale Praxis der Geheimhaltung aus? Wir haben die folgenden Empfehlungen aufgestellt:
- Verschlüsselte Speicherung: Speichern Sie Anmeldedaten und Geheimnisse mit einem weiteren Passwort.
- Transport über sichere Kanäle: Konfigurieren Sie die Kanäle, über die Geheimnisse übertragen werden, so, dass sie nicht abgefangen werden können und nicht nach außen dringen.
- Regelmäßige Rotation der Geheimnisse: Legen Sie einen regelmäßigen Zeitraum für die Aktualisierung der Zugangsdaten in der Datenbank oder im Dienst fest.
- Kurze Verfügbarkeit: Im Prinzip sollte ein Geheimnis nur für eine begrenzte Zeit im Speicher vorhanden sein. Sobald es verbraucht ist, ist der Speicherbereich zu löschen.
Kurze Verfügbarkeit bedeutet an sich, dass ein Geheimnis vorübergehend im Speicher vorhanden ist und nach seiner Verwendung entfernt wird. Wir können diesen Ansatz mit den Implementierungen von Betriebssystemen verbinden, die effektiv verhindern, dass die Geheimnisse in einem anderen Prozess als Teil des nicht initialisierten Speichers gefunden werden.
Wir haben beispielsweise die Umgebung analysiert, in der eine MySQL-Datenbank in einem Container ausgeführt wird, und festgestellt, dass das Abfließen einer Umgebungsvariablen, in der ein Root-Passwort gespeichert ist, ein schwerwiegenderes Problem darstellen kann als der Zugriff auf das Geheimnis selbst (d. h. das Root-Passwort).
Wenn jedoch serverlose Funktionen (über ein Ereignis oder einen Trigger wie z. B. den Zugriff auf den Endpunkt, die Datenbank oder die Message Queue) innerhalb des Standarddienstes eines Cloud-Dienstanbieters (CSP) ausgeführt werden und sensible Umgebungsvariablen enthalten, könnte die Ausführung selbst zu einer Kompromittierung des gesamten Dienstes oder zu einer Remote-Code-Ausführung (RCE) aufgrund einer Memory-Read-Schwachstelle führen.
Die versteckte Gefahr bei der Verwendung von Umgebungsvariablen für die Verwaltung von Geheimnissen besteht darin, dass die architektonische Lösung es Benutzern ermöglichen könnte, ungewollt Sicherheitsgrenzen zu überschreiten, selbst wenn nur eine einzige Information geleakt ist. Die Wahrscheinlichkeit der Leakage erhöht sich mit der Copy-and-Paste-Funktion in jedem Kindprozess, wodurch jede Anwendung, die ein anderes Programm als Kindprozess erzeugt, mit größerer Wahrscheinlichkeit angreifbar ist.
Die Eigenschaften von Umgebungsvariablen können DevOps-Teams noch unbekannt sein, wenn sie ihre Anwendungen entwerfen und im Fall wenn eine gängige Praktik wiederverwendet wird (d. h. die gewohnheitsmäßige Verwendung von Umgebungsvariablen zur Speicherung von Geheimnissen durch App-Entwickler). Aus diesem Grund sollten sich die Entwickler bei der Entwicklung ihrer Produkte dieser Eigenschaften und der Auswirkungen ihrer Programmierung bewusst sein. Der beste Fall ist die Vermeidung der Verwendung von Umgebungsvariablen für die Speicherung von Geheimnissen.
Cloud-Geheimnisse in Umgebungsvariablen
Wenn ein Entwickler seine Tools für die Befehlszeilenschnittstelle oder sogar Erweiterungen für die Entwicklung auf Plattformen wie Visual Studio Code ausführen muss, vollzieht er einen ersten Konfigurationsprozess. Ein Kennwort oder Schlüssel wird angefordert, um den Zugriff auf CSP-Dienste zu gewähren, und die Autorisierungs-Tokens können auf zwei Arten für die Validierung gespeichert werden: über eine lokale Datei, die die Tokens enthält, meist im Klartext, oder über Umgebungsvariablen.
Bei der Untersuchung von serverlosen Diensten stellten wir fest, dass dieselben Umgebungsvariablen auf dem Rechner eines Entwicklers und auch in der Serverless-Laufzeitumgebung zu finden sind. Die in der Umgebung vorhandenen Geheimnisse könnten in verschiedenen Kontexten missbraucht werden. Wenn es einem Angreifer gelingt, das offizielle CLI-Tool des CSP innerhalb der serverlosen Umgebung herunterzuladen, erbt es die Berechtigung und die Privilegien, die dem Dienst über die Geheimnisse gegeben wurden.
In Anbetracht der Tatsache, wie einfach es war, an sensible Daten heranzukommen, gehen wir davon aus, dass die Cloud, die Pipeline und die Tools ein Ziel für Cyberkriminelle werden. Wir haben in mindestens zwei Fällen Ereignisse mit dieser Art von Kompromittierung gesehen. Beim ersten Vorfall hatte es die Hackergruppe TeamTNT auf kompromittierte Cloud-Umgebungen abgesehen und suchte speziell nach sensiblen Umgebungsvariablen. Kürzlich gab es Berichte über einen Supply-Chain-Angriff, bei dem der Code einer Python-Bibliothek so verändert wurde, dass derselbe Inhalt sensibler Variablen abgegriffen werden konnte.
Verbreitung der Verwendung von Umgebungsvariablen für Geheimnisse
Es gibt nur Schätzungen über die Verbreitung dieser Praxis. Viele Entwickler gehen jedoch davon aus, dass die Aufbewahrung von Geheimnissen in Umgebungsvariablen „der sicherste Weg ist, mit geheimen Schlüsseln/Passwörtern umzugehen“.
Wir halten die Verwendung von Vaults für eine bessere Option zur Speicherung von Geheimnissen als Umgebungsvariablen. Zudem sollten Geheimnisse nur bei Bedarf und nur über einen sicheren und verschlüsselten Kanal abgerufen und der Speicher sicher gelöscht werden, sobald das Schlüsselpaar verwendet wurde. Mit diesem Ansatz wird ein Geheimnis in einem einzigen Prozess innerhalb der bereitgestellten Anwendung gespeichert und die unerwünschte Weitergabe an seine untergeordneten Prozesse, die den Angriffsvektor im Zusammenhang mit dem Risiko des Leakens von Geheimnissen erhöht, wird vermieden.
Fazit
Die Verwendung von Umgebungsvariablen für anwendungsbezogene Funktionen und Daten ist von Natur aus sicher, schnell und effizient für Entwicklung und Einsatz. Die gespeicherten Daten sollten jedoch keine sensiblen Informationen oder Geheimnisse enthalten, die für Angriffe verwendet werden könnten, wie z. B. Anmeldedaten, Zugriffs-Token, Anmelde-URLs und Connection Strings.
Im besten Fall sollte die Speicherung von Geheimnissen in Umgebungsvariablen vollständig vermieden werden. Es gibt sicherere Möglichkeiten, Geheimnisse zu verwalten, unabhängig davon, wie groß das Projekt oder das Team ist, das das Projekt bearbeitet. DevOps-Praktiker und -Entwickler sollten auch in Betracht ziehen, dass es Tools gibt, mit denen sich die Risiken auf ein Minimum reduzieren lassen und die Cyberkriminellen keine zusätzlichen Angriffsvektoren in Anwendungen bieten. Best Practices wie die folgenden können dazu beitragen, die Auswirkungen dieser Risiken zu mindern:
- Befolgen Sie die Empfehlungen der CSPs (die Sie in der Regel in ihren jeweiligen Dokumentationen finden) zur Sicherung von Umgebungen und Projekten.
- Verwenden Sie Tresore/Vaults zur Speicherung von Schlüsseln und Passwörtern. Dies kann zusätzliche Kosten für das Team oder die Organisation verursachen, bietet aber Benutzern und Sicherheitsteams eine zusätzliche Schutzschicht für die Speicherung ihrer Anmeldeinformationen.
- Verwenden Sie benutzerdefinierte Images. Während Standarddienste eine schnelle und effiziente Bereitstellung und Entwicklung ermöglichen, bieten benutzerdefinierte Container-Images und -Implementierungen den Entwicklern mehr Spielraum für sofort einsatzbereite Lösungen und zusätzliche Sicherheit.
- Verwenden Sie verschlüsselte Kanäle und Pipelines. Durch das Sperren der Variablenwerte wird sichergestellt, dass sensible Informationen wie Kennwörter und IDs im Falle eines unbefugten Zugriffs geheim bleiben.