März 22, 2022
Von Thyaga Vasudevan - Vizepräsident für Produktmanagement, Skyhigh Security
Die Umstellung auf eine Cloud-native Architektur für Ihre Unternehmensanwendungen kann einen enormen geschäftlichen Nutzen bringen, da sie Skalierbarkeit und Agilität bietet und gleichzeitig lästige Aufgaben wie Patches und Upgrades der Serverinfrastruktur auslagert.
In jeder Cloud-Umgebung, ob Amazon Web Services (AWS), Azure oder Google Cloud, gibt es jedoch eine neue Kategorie von Risiken. Cloud-native Bedrohungen ergeben sich aus den neuen Kontext- und Konfigurationsanforderungen, die Sie in einer Cloud-Umgebung haben. In der Vergangenheit haben Standardeinstellungen wie der öffentliche Zugriff auf Speicherobjekte dazu geführt, dass sensible Daten offen liegen und von jedem, der auf der Suche nach diesen Schwachstellen ist, leicht gestohlen werden können.
In einer neuen Umgebung können leicht Fehler gemacht werden, da ständig neue Einstellungen eingeführt werden, wenn die Cloud-Anbieter neue Funktionen hinzufügen. Die Konfiguration Ihrer Cloud-Umgebung liegt immer in Ihrer Verantwortung. AWS und andere haben keine Kontrolle darüber, wie Sie ihre Dienste nutzen. Sie sind eine Vorlage für Sie, auf der Sie aufbauen können.
Wenn Sie die Auswirkungen Ihrer Konfigurationen und die Art und Weise, wie Sie Cloud-native Anwendungen erstellen, nicht verstehen, kann dies katastrophale Folgen haben. Und selbst die versiertesten Cloud-Kunden können unter diesen Folgen leiden.
Ein Beispiel dafür ist der Einbruch bei Capital One vor fast drei Jahren, bei dem ein Angreifer Zugang zu den Sozialversicherungsnummern von 100 Millionen US-Bürgern und den Sozialversicherungsnummern von 6 Millionen kanadischen Bürgern hatte. Der Angreifer nutzte verschiedene Techniken, um sich Zugang zu den Daten zu verschaffen. Eine wichtige Erkenntnis aus dem Angriff war jedoch, dass eine Sicherheitsfunktion, die den Zugriff auf virtuelle Maschinen - Elastic Compute Cloud oder EC-Instanzen - schützen sollte, dem Angreifer hinzugefügt wurde. Die Funktion wird Instance Metadata Service oder IMDS genannt.
Angriffe auf Instanz-Metadaten
Version 1 von IMDS (IMDSv1) wurde 2012 veröffentlicht, um EC2-Instanzen einen sichereren Weg zur Interaktion mit anderen AWS-Services zu ermöglichen. Anstatt AWS-Schlüssel auf der Instanz zu hinterlassen, konnten Kunden nun die EC2-Instanz den Metadaten-Service abfragen lassen, um Anmeldeinformationen zu erhalten und AWS-API-Aufrufe an andere AWS-Services zu tätigen. Wenn eine EC2-Instanz beispielsweise Kundendaten erhält, kann sie IMDSv1 verwenden, um diese Daten in einem Amazon Simple Storage Service (S3)-Bucket zu speichern. Genau diese Fähigkeit nutzte der Angreifer, um sensible Daten aus einem S3-Bucket abzurufen, in dem Informationen über Capital One-Kunden gespeichert waren.
In unseren eigenen Tests konnten wir nachvollziehen, wie diese Datenextraktion in einer beliebigen Anwendung funktionieren könnte. In unserem Beispiel baute ein Team von Epidemiologen eine Cloud-native Anwendung in AWS mit einem öffentlichen Dashboard, um Daten visuell darzustellen, die ihren Fortschritt bei der Analyse eines Virusgenoms zeigen.
Während der Entwicklungsphase dieser Anwendung stieß das Team auf eine Herausforderung. Die meisten Ressourcen in ihrer Virtual Private Cloud (VPC) sollten vor dem Internet verborgen sein. Die einzige Ressource in ihrer VPC, die für die Öffentlichkeit bestimmt war, war das Dashboard.
Der S3-Bucket, in dem die Daten gespeichert sind, musste privat bleiben. Um die Daten aus S3 auf das öffentliche Dashboard zu übertragen, fügten sie einen Reverse Proxy hinzu, der als Vermittler fungierte. Eine schnelle Google-Suche und ein paar Zeilen Code genügten, um dies in ihre Anwendung einzubauen.
Für das Team von Epidemiologen war der Reverse Proxy eine einfache, elegante Lösung, die für ihren Anwendungsfall perfekt funktionierte. Was sie nicht wussten, war, dass sie damit einen massiven Einbruch riskierten.
Der Recheninstanz, auf der der Reverse-Proxy läuft, wurde eine IAM-Rolle mit der Berechtigung zum Zugriff auf ihren privaten S3-Bucket zugewiesen. Die Zugangsdaten für den Reverse-Proxy für den Zugriff auf S3 wurden aus den Instanz-Metadaten bezogen.
Ein Angreifer, der die Website besuchte und sich für deren Daten interessierte, bemerkte, dass das Team im Dashboard auf die IP-Adresse des Reverse-Proxys verwiesen hatte. Der Angreifer überprüfte daraufhin, ob er eine Verbindung zu diesem herstellen konnte. Nachdem er die Verbindung bestätigt hatte, prüfte der Angreifer, ob er über den Reverse-Proxy auf die Instanz-Metadaten zugreifen konnte. Erfolgreich.
Über den Reverse-Proxy und die Instanz-Metadaten gelangte der Angreifer an die Zugangsdaten für den privaten S3-Speicher-Bucket des Teams.
Mit dem Zugriff auf den S3-Bucket konnte der Angreifer nun hochsensible Daten stehlen, die das Team für seine Anwendung gespeichert hatte. Der Angreifer synchronisierte den Ziel-S3-Bucket einfach mit seinem eigenen S3-Bucket in einem anderen AWS-Konto, und schon gehörten die Daten ihm.
Diese Art von Angriff ist nur eine von 43 Techniken, die MITRE in seinem ATT&CK Framework für Cloud-Umgebungen beschreibt: https://attack.mitre.org/matrices/enterprise/cloud/
Wie AWS Angriffe auf Instanz-Metadaten abwehrt
Um die Sicherheit dieses Dienstes zu verbessern, hat AWS IMDSv2 veröffentlicht, das mehrere neue Schutzschichten hinzufügt.
In IMDSv2 wird externen Benutzern der Empfang von Anmeldedaten verwehrt, so dass nur Anwendungsressourcen diese erhalten können. Lesen Sie mehr über diese Schutzschicht und IMDSv2 hier: https://aws.amazon.com/blogs/security/defense-in-depth-open-firewalls-reverse-proxies-ssrf-vulnerabilities-ec2-instance-metadata-service/
Die Herausforderung besteht jedoch darin, dass IMDSv1 immer noch weiterlebt. Es gibt bei AWS nichts, was Kunden daran hindert, IMDSv1 zu verwenden, und Sie können es immer noch standardmäßig für alle Ihre EC2-Instanzen verwenden. Wie wir bereits erwähnt haben, liegt es nicht in der Verantwortung von AWS, dafür zu sorgen, dass Sie die Cloud sicher nutzen. Diese Verantwortung liegt allein bei den Kunden.
Bei dem soeben beschriebenen Angriff war der Reverse Proxy falsch konfiguriert, so dass externe Anfragen auf interne Ressourcen zugreifen konnten. Hätte das Team seine Recheninstanz so konfiguriert, dass sie IMDSv2 verwendet, wäre der unbefugte Zugriff durch den externen Bedrohungsakteur blockiert worden.
Wie Skyhigh Cloud Native Application Protection helfen kann
Auf Skyhigh Security haben wir mehrere Ansätze, die Ihnen helfen können, solche Angriffe zu erkennen und zu verhindern. Skyhigh Cloud Native Application Protection Platform (CNAPP) ist unsere Cloud-native Sicherheitsplattform, die es Ihnen ermöglicht, Konfigurationen in AWS, Azure und GCP zu überwachen und zu aktualisieren, zusammen mit einer Vielzahl zusätzlicher Sicherheitsmaßnahmen, die Sie hier nachlesen können.
Über eine direkte API-Integration mit AWS überwacht Skyhigh CNAPP kontinuierlich Amazon CloudWatch - einen Dienst zur Überwachung von Anwendungen und Infrastrukturen - um anzuzeigen, welche Version von IMDS Sie in jeder EC2-Instanz verwenden.
Wenn CloudWatch eine Instanz protokolliert, die aktiv IMDSv1 verwendet, generiert Skyhigh CNAPP einen Sicherheitsvorfall und benachrichtigt Sie, dass Sie Ihre Konfiguration auf IMDSv2 aktualisieren müssen, um den unbefugten Zugriff auf Ihre Anmeldedaten durch externe Benutzer zu verhindern.
Skyhigh CNAPP-Richtlinienvorfälle für die Konfiguration der IMDS-Version
Es ist die beste Praxis, IMDSv2 auf Ihren EC2-Instanzen für alle lokalen Codes und Benutzer zu erzwingen. Sobald Sie festlegen, dass IMDSv2 verwendet werden muss, wird IMDSv1 nicht mehr funktionieren. AWS bietet hier eine schrittweise Anleitung, wie Sie Ihre Instanzen für die Verwendung von IMDSv2 konfigurieren.
Über dieses Angriffsbeispiel hinaus können Sie mit Skyhigh CNAPP eine Reihe von Best Practices zum Schutz Ihrer Cloud-nativen Anwendungen implementieren:
- Überprüfen Sie kontinuierlich Ihre Konfigurationen. Mit Skyhigh CNAPP können Sie AWS CloudFormation-Vorlagen scannen, bevor sie in Produktion gehen, und dann jede "Abweichung" in Ihren Konfigurationen im Laufe der Zeit erkennen. Auf diese Weise können Sie Fehlkonfigurationen erkennen und ein Least-Privilege-Modell für die Ressourcenberechtigung durchsetzen.
- Erzwingen Sie Zero-Trust. Verwenden Sie Zero-Trust als Methode, bei der nur bestimmte Ressourcen ausgeführt werden und miteinander kommunizieren dürfen. Alles andere wird blockiert.
- Scannen Sie nach Code-Schwachstellen. Insbesondere bei offenen Softwareverteilungsmodellen wie Docker ist es wichtig, Ihre Anwendungsressourcen kontinuierlich auf Schwachstellen zu überwachen.
- Erkennen Sie Anomalien und Bedrohungen. Mit User and Entity Behavior Analytics (UEBA) können Sie Millionen von Cloud-Ereignissen auswerten, um anormale Aktivitäten und echte Bedrohungen wie den Diebstahl von Zugangsdaten aufzudecken.
- Führen Sie DLP für Speicherobjekte aus. Wie bei jedem anderen Cloud-Service, den Sie genehmigen, Ihrem Netzwerk oder Ihren Endpunkten können und sollten Sie auch bei AWS Ihre Daten in S3 klassifizieren und data loss prevention ausführen, um Exfiltrationsversuche zu verhindern.
Setzen Sie sich mit uns in Verbindung, um über die Umsetzung dieser Maßnahmen in Ihrem eigenen Unternehmen zu sprechen.
Zurück zu Blogs