Ausnutzung von Terraform, Kubernetes und AWS für Datendiebstahl

Das Sysdig Threat Research Team hat eine raffinierte Cloud-Operation namens SCARLETEEL entdeckt, die sich auf den Diebstahl von geschützten Daten in einer Kundenumgebung spezialisiert hat. Die Angreifer nutzten eine containerisierte Arbeitslast, um Zugang zu einem AWS-Konto zu erhalten und schützenswerte Software und Anmeldeinformationen zu stehlen. Um ihre Reichweite zu erhöhen, versuchten sie auch, über eine Terraform Status Datei auf andere AWS-Konten zuzugreifen. Dieser Angriff war anspruchsvoller als herkömmliche Kryptojacking-Angriffe , da er von einem kompromittierten Kubernetes-Container ausging und Kenntnisse über AWS-Cloud-Mechanismen wie EC2-Rollen, serverlose Lambda-Funktionen und Terraform erforderte. Das Hauptziel der Angreifer war der Diebstahl von proprietärer Software, was den Angriff besonders heimtückisch macht.

Cyberangriffe in der Cloud haben im letzten Jahr um 56 Prozent zugenommen . Die häufigsten Motive sind das Erreichen von Persistenz in der Cloud, das Exfiltrieren sensibler Daten und die Erstellung neuer Ressourcen wie EC2-Instanzen zur Verwendung für Kryptomining. Solche Ressourcen können erhebliche Auswirkungen auf die Cloud-Kosten eines Unternehmens haben. Die Realität ist, dass Angreifer gehackte Cloud-Ressourcen für mehr als nur Kryptomining nutzen können.

Der jüngste Angriff hat viele Facetten, die die Komplexität der Sicherung einer Cloud-basierten Infrastruktur verdeutlichen. Schwachstellenmanagement allein kann nicht alles abdecken. Stattdessen gibt es eine Reihe von Tools, die Ihr Risiko durch moderne Bedrohungen verringern können, darunter virtuelle Maschinen, Cloud Security Posture Management (CSPM), Cloud Infrastructure Entitlement Management (CIEM), Runtime-Bedrohungs Erkennung und Secrets Management.

Diese Infografik zeigt die wichtigsten Schritte in der Kill Chain. Zunächst wird der Angriff auf einer hohen Ebene dargestellt, dann werden die einzelnen Schritte detaillierter erläutert.

Schritt 1: Der Angreifer verschaffte sich zunächst Zugang, indem er einen öffentlich zugänglichen Service in einem selbst verwalteten Kubernetes-Cluster ausnutzte, der in einem AWS-Cloud-Konto gehostet wird.

Schritt 2: Sobald der Angreifer Zugriff auf den Pod hatte, konnte die Malware während der Ausführung zwei erste Aktionen durchführen:

• Einen Cryptominer starten, um Geld zu verdienen oder eine Ablenkung zu bieten.
• Zugriff auf Anmeldeinformationen über die temporären Anmeldeinformationen eines Mitarbeiters im Instance Metadata Service (IMDS) v1, um mithilfe der Cluster-Rollenberechtigungen Informationen in seinem Namen aufzuzählen und zu sammeln. Aufgrund der übermäßig gewährten Berechtigungen war der Angreifer in der Lage:
  • AWS-Ressourcen zu enumerieren.
  • Anmeldeinformationen anderer IAM-Benutzer (Identity and Access Management) zu finden, die als Lambda-Umgebungsvariablen festgelegt und im Klartext in Amazon Simple Storage Service (S3)-Buckets übertragen wurden.

Schritt 3: Der Angreifer nutzte die im vorherigen Schritt gefundenen Anmeldeinformationen, um sich lateral zu bewegen. Er wandte sich direkt an die AWS-API, enumerierte das Konto weiter und fuhr mit dem Sammeln von Informationen und der Datenexfiltration fort. Während dieses Schritts waren sie in der Lage:

• CloudTrail-Protokolle zu deaktivieren, um Erkennung zu entgehen.
• Proprietäre Software zu stehlen.
• die Anmeldeinformationen eines IAM-Benutzers zu finden, der zu einem anderen AWS-Konto gehört, indem er Terraform-Statusdateien in S3-Buckets entdeckte.

Schritt 4: Der Angreifer nutzte die neuen Anmeldeinformationen, um sich erneut lateral zu bewegen und den Angriff und seine Kill Chain von dem anderen AWS-Konto, das er gefunden hatte, zu wiederholen. Glücklicherweise waren sie in diesem Fall nicht in der Lage, Ressourcen zu enumerieren, da alle AWS-API-Anfragen, die sie versuchten, aufgrund fehlender Berechtigungen fehlschlugen.

Empfehlungen

Der hier beschriebene Angriff ist ein deutlicher Hinweis darauf, wie Bedrohungsakteure versuchen, die Cloud als Hauptziel zu erreichen. Es begann mit einem kompromittierten Service, jedoch versuchte der Angreifer sofort sich lateral in der Cloud zu bewegen, sobald er gültige Anmeldeinformationen erhalten hatte, um an wertvolle Informationen wie proprietären Code zu gelangen. Sie versuchten auch, auf andere Cloud-Konten auszuweichen, um an noch mehr Daten zu gelangen.

Hier sind einige der wichtigsten Erkenntnisse, die helfen können, besser vorbereitet zu sein:

• Nutzung von aktuellen Patches und einem Vulnerability Management Cycle für Anwendungen und öffentlich zugänglichen Container an. So kann erkannt werden welche Schwachstellen bestehen, und können Prioritäten für die Patching-Aktivitäten setzen.
• Verwendung von IMDS v2 anstelle von IMDS v1. Die Verbesserungsversion erfordert sitzungsorientierte Anfragen, um den Schutz vor unbefugtem Zugriff auf Metadaten zu erhöhen. Um sicherzustellen, dass nur autorisierte Pods bestimmte IAM-Rollen in Clustern übernehmen können, sollte das Prinzip von Least Privilege angewendet und wann immer möglich IAM Rollen für Service Accounts (IRSA) verwendet werden. IRSA schränkt den Zugriff auf Ressourcen ein und verringert das Risiko eines unbefugten Zugriffs. Pods, die nicht autorisiert sind, bleiben bei den IMDS-Einstellungen.
• Die Bedeutung von schreibgeschütztem Zugriff. Selbst der schreibgeschützte Zugriff auf bestimmte AWS-Ressourcen wie Lambda-Funktionen bedeutet, dass Datenexfiltration oder das Abgreifen von Anmeldeinformationen möglich sind. Die Beschränkung des Nur-Lese-Zugriffs nur auf die benötigten Ressourcen ist von grundlegender Bedeutung, um Konten sicher zu halten.
• Überwachung von veralteten Objekten in Cloud-Konten. Ungenutzte Berechtigungen, selbst wenn sie alt sind und nie genutzt wurden, können gefährlich sein und im Falle einer Kompromittierung viel kosten. Das Bewusstsein für veraltete Objekte und die regelmäßige Bewertung der Cloud-Objekte sollte obligatorisch sein.
• Terraform ist ein großartiges Werkzeug, aber es muss mit Sorgfalt behandelt werden. Man sollte sich an Best Practices halten und Statusdateien an einem sicheren Ort speichern. Mithilfe von Schlüsselverwaltungsdiensten (KMS) wie AWS KMS, GCP KMS oder Azure Key Vault ist es möglich, Geheimnisse sicher aufzubewahren und sie bei Bedarf zu ver- oder entschlüsseln.

Fazit

Es wurden einige Maßnahmen nach der Entdeckung des Angriffs zur Sicherung der Umgebung ergriffen. Dazu gehörten die Deaktivierung und Entfernung der Zugangsschlüssel und geheimen Zugangsschlüssel von Benutzern sowie die Sicherung anfälliger Anwendungen nach der Durchführung einiger Audits und Penetrationstests. Im nächsten Schritt wurde die Beschränkung des Zugangs zu sensiblen S3-Buckets durch die Verwendung restriktiver Richtlinien enger eingestellt. Zudem wurden zusätzliche Maßnahmen zur Minimierung der Privilegien eingeführt, um die potenzielle Angriffsfläche zu verringern und Querbewegungen in der Cloud zu verhindern.

Bei diesem komplexen Angriff konnte man sehen, wie weit ein Angreifer gehen kann, wenn er eine anfällige Anwendung mit unzureichenden Sicherheitsmaßnahmen kompromittiert. Dieses Ereignis bestätigte, zwei bestehenden Einschätzungen. Erstens: Zero Trust und das Prinzip von Least Privilege sind wichtig, und verringern die Wahrscheinlichkeit einer Kompromittierung. Zweitens: Strenge Erkennungsmechanismen und Warnmeldungen sollten in der Lage sein, diese Aktivitäten zu erkennen, bevor ein Angreifer zu tief eindringt.

Über Alberto Pellitteri

Alberto Pellitteri ist Sicherheitsforscher mit Spezialisierung auf Kubernetes- und Docker-Technologien.

Als Sicherheitsforscher bei Sysdig erforscht Alberto Pellitteri Malware und Angriffe, die auf Cloud-Infrastrukturen und anfällige Umgebungen abzielen. Als Mitwirkender an Open-Source-Projekten hat Alberto auch zu Falco beigetragen, einem Open-Source-Laufzeit-Sicherheitstool der CNCF auf Inkubationsniveau. Alberto studierte Cybersicherheit, während er seinen Bachelor- und Master-Abschluss in Computertechnik in Italien machte.