Sichere Geheimdaten: DevOps und die Cloud

Originalbeitrag von David Fiser, Threat Researcher, Alfredo Oliveira, Sr. Security Researcher

Die geeignete Verwaltung von geheim zu haltenden Daten spielt eine wichtige Rolle, um sie für Bedrohungsakteure unerreichbar zu machen. Ein solch sicheres Management gewinnt weiter an Bedeutung, je mehr Workloads in die Cloud geschoben werden. Ein erster Beitrag zum Thema beschäftigte sich mit der Definition von „Geheimnissen“ und den Möglichkeiten diese zu speichern und zur Verfügung zu stellen. Gerade wenn es um Workloads in der Cloud geht, zeigt sich auch die Relevanz des Modells der gemeinsamen Verantwortung (Shared Responsibility Model). Welche Auswirkungen hat eine unsichere Speicherung von Credentials auch vor dem Hintergrund heutiger Entwicklungstechnologien?

Heute betrachten die meisten Menschen Entwicklungs- und „lokale“ Umgebungen als inhärent sicher. Dies spiegelt sich in Praktiken wider, wie etwa das Speichern von Geheimnissen in unverschlüsselter Form, das Entwerfen von Software, die nur in sicheren Umgebungen ausgeführt werden soll, und der Verzicht auf die standardmäßige Härtung von Sicherheitsfunktionen. Das bringt zwar zusätzlichen Komfort für die Benutzer, da keine komplexe Sicherheitskonfiguration erforderlich ist, der Nachteil dabei ist jedoch, dass diese Praktiken das Risiko eines Sicherheitsvorfalls erhöhen. Wir haben bereits die Auswirkungen von Angriffen auf die Lieferkette, schwacher VPN-Sicherheit, VPN-Schwachstellen usw. gesehen.

Auch sollte in Betracht gezogen werden, dass „lokale“ Umgebungen nicht mehr ganz so lokal sind, denn immer mehr Unternehmen wechseln in die Cloud. Geheimdaten in Klartext, die auf einem Gerät mit hardwarebasierter Verschlüsselung abgelegt sind, werden gleichzeitig auf einem Gerät vorgehalten, das mit der Cloud verbunden ist. Kurz gesagt: Es ist nicht sicher, geheime Informationen in Klartext zu speichern, egal ob in der Cloud oder nicht. Ein echtes Beispiel dafür aus der DevOps-Welt ist Visual Studio Code, das erst seit der Version 1.5353, aus dem Januar 2021 Unterstützung für die Speicherung von Geheimdaten bietet. Bislang gab es kein offizielles API für das sichere Speichern von Geheimdaten, und es oblag den Entwicklern, dies sicher zu realisieren.

Bedrohungen

Erschwerend kommt hinzu, dass sich Bedrohungsakteure auf das Abgreifen von Anmeldeinformationen fokussieren, was Visual Studio Code-Benutzer und auch Anwender in der Cloud zu leichten Zielen für solche Angriffe macht. Wenn Geheimdaten in Klartext vorliegen, ist es für Cyberkriminelle viel einfacher sie zu stehlen. Beim Betrieb in der Cloud müssen Unternehmen das Modell der geteilten Verantwortung beachten. Die Sicherheit ihrer verwendeten Anmeldedaten bleibt auch in der Cloud in ihrer Verantwortung.

Unerlässlich ist es auch, ein hohes Maß an Vertrauen zwischen allen an der Geheimhaltung der Daten Beteiligten zu erreichen. Cloud-Anbieter berufen sich stets auf das Modell der geteilten Verantwortung, das insbesondere bei Fehlkonfigurationen durch den Anwender zum Tragen kommt. So gab es beispielsweise einen Angriff, bei dem nach der Kompromittierung einer Instanz die Kriminellen den AWS-Metadaten-Service anforderten, um Anmeldeinformationen oder geheime Daten zu erhalten. Dies verdeutlicht, wie Angreifer auf Anmeldeinformationen einer Cloud-Instanz zugreifen können, nachdem sie diese kompromittiert haben, um ihren Angriff fortzusetzen.

Im Allgemeinen generieren Befehlszeilen-Tools der Cloud Service Provider (CSP) bei der ersten Konfiguration Autorisierungs-Token und speichern diese Token in Klartext entweder in Dateien oder als Systemvariablen. Wenn Bedrohungsakteure diese Funktionalität kennen, können sie Malware entwickeln, die nach diesen Berechtigungs-Token sucht, sobald sie in eine Instanz eindringen. Abhängig von der Berechtigungsstufe der gestohlenen Token können sie als Folge den Angriff fortsetzen und weitere Nutzdaten intern verbreiten.

Native CSP-Tools

Bei einer unserer Untersuchungen fiel auf, dass Angreifer an verschiedenen Punkten ihrer Angriffe native CSP-Tools verwendeten, anstatt eigene zu entwickeln oder Exploits zu nutzen. In solchen Fällen hätte der Angreifer die gleichen Berechtigungen wie der vom Anwender konfigurierte Dienst. Dieses Verhalten bedeutet, dass die Cyberkriminellen sich über alle möglichen Optionen und Parameter der nativen Tools informieren und sie missbrauchen. In internen Umgebungen wie etwa Lambda ist die Verwendung nativer Tools vorautorisiert. Wenn es dem Angreifer also gelingt, das Tool dorthin hochzuladen, hätte er die gleichen Berechtigungen wie der Dienst.

Interessierte finden im Originalbeitrag ein reales Szenario, das die Bedeutung geeigneter Speicherung von Geheimdaten aufzeigt. Eine neuere Recherche zeigt auch, dass Bedrohungsakteure sich an die aktuellste Technologie anpassen und aktiv versuchen, Infrastructure as Code (IaC) Software auszunutzen, so etwa Ansible, Chef und SaltStack, um ihre Payload an möglichst viele Geräte zu verteilen.

Container

Ein typischer Container ist nichts anderes als ein weiterer Prozess mit eingeschränkten Berechtigungen und Fähigkeiten; dies gilt jedoch nicht für privilegierte Container. Seit kurzem haben Angreifer Funktionen zum Ausnutzen von Containern in ihr Arsenal aufgenommen. Das Ausführen eines Dienstes innerhalb eines Containers benötigt oft eine vertrauliche Information, um Zugriff auf einen anderen Dienst zu erhalten, sodass das gleiche Prinzip für deren Speicherung gilt.

Das folgende Video zeigt, wie ein potenzieller Angreifer mithilfe von Tools aus dem TeamTNT-Toolset aus einem Docker-Container ausbrechen kann.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.