Wie sicher ist eine CIS/AWS-konforme Cloud-Umgebung?

Nur auf Englisch verfügbar

Blogbeitrag 29. April 2021 von Roy Stultiens, Sicherheitsanalyst bei Bureau Veritas Cybersecurity

Bei Bureau Veritas Cybersecurity sehen wir Kunden, die Industriestandards oder Sicherheitsgrundlagen einhalten wollen, um sicherzustellen, dass ihre Cloud-Umgebung ordnungsgemäß gesichert ist. In Cloud-Umgebungen ist eine der gebräuchlichen Baselines die des CIS (Center for Internet Security [1]). Diese Baselines bringen Wert und grundlegende Sicherheit für eine Umgebung, aber wie unsere Untersuchungen zeigen, können Sie dennoch einem Angriff ausgesetzt sein.

Einer unserer Sicherheitsanalysten hat eine Untersuchung durchgeführt, um herauszufinden, wie sicher eine vollständig CIS-konforme AWS-Cloud-Umgebung ist und ob sie vor häufig auftretenden Fehlkonfigurationen und Schwachstellen schützt. Die Ergebnisse zeigen, dass mit drei häufig verwendeten Baselines immer noch 4 von 6 gängigen Angriffen durchgeführt werden können. In diesem Artikel teilen wir die Details dieser Untersuchung mit Ihnen und geben Ihnen Ratschläge zu häufigen Fehlkonfigurationen oder Sicherheitslücken, um Sie bei der Sicherung Ihrer Cloud zu unterstützen.

Häufig verwendete Sicherheits-Benchmarks/Baselines

Zunächst wurden die gängigsten AWS-Sicherheits-Frameworks gesammelt, die von unseren Kunden und aufgrund unserer Erfahrung mit Cloud-Bewertungen häufig verwendet werden. Für AWS wurden drei Sicherheits-Frameworks identifiziert, und zwar:

CIS Amazon Web Services Foundations Benchmark v1.2 (2018) [2].
Dieser Benchmark ist bei weitem der beliebteste und bietet 49 Sicherheitsempfehlungen zu IAM, Protokollierung, Überwachung und Netzwerken. Die Empfehlungen sind entweder Stufe 1 oder Stufe 2, wobei Stufe 2 tiefgreifende Verteidigungsmaßnahmen sind, die die Leistung eines Dienstes beeinträchtigen können. Die Empfehlungen sind generisch und können auf alle AWS-Umgebungen angewendet werden.
CIS AWS Three-tier Web Architecture Benchmark v1.0 (2016) [3]
Der Three-tier Benchmark besteht aus 96 Empfehlungen, die auf bestimmte Services wie EC2 (Elastic Computing) und Datenbanken zugeschnitten sind. Das Dokument ist auf die Verwendung der dreistufigen Architektur ausgerichtet. Die Implementierung dieses Benchmarks auf anderen Architekturen erfordert vom Benutzer tiefgreifende Kenntnisse.
AWS Foundational Security Best Practices Standard [4].
Dieser Standard wird von AWS veröffentlicht und ständig weiterentwickelt. Zum Zeitpunkt der Erstellung dieses Dokuments enthält er 70 Sicherheitsempfehlungen, während er während der Untersuchung 31 Regeln umfasste. Alle Regeln sind servicespezifisch und vollständig in den AWS Security Hub integriert.

Häufige Fehlkonfigurationen und/oder Schwachstellen in Cloud/AWS

Obwohl Bureau Veritas Cybersecurity bei seinen Cloud-Bewertungen Sicherheits-Benchmarks und -Baselines verwendet, neigen unsere Experten dazu, einen ganzheitlichen Ansatz zu verfolgen, anstatt nur diese Baselines zu überprüfen. Bei real durchgeführten Cloud-Bewertungen wurden viele verschiedene Fehlkonfigurationen und Schwachstellen gefunden. Eine Auswahl der häufigsten sind:

Server Side Request Forgery (SSRF) auf EC2 [5].
In diesem Szenario wird eine AWS-Recheninstanz (EC2) mit der Berechtigung gestartet, S3-Buckets zu lesen. Der auf der Instanz laufende Webservice enthält jedoch eine Schwachstelle, die es einem Angreifer ermöglicht, den Server Anfragen in seinem Namen ausführen zu lassen. Ein Angreifer kann dies missbrauchen, um den Instance Metadata Service von AWS abzufragen und die Anmeldeinformationen zu extrahieren, die der Rechner für den Zugriff auf die S3-Buckets verwendet. Weitere Einzelheiten finden Sie in diesem Video.
In Benutzerdaten auf EC2-Instanzen gespeicherte Geheimnisse [6]
Benutzerdaten auf EC2-Instanzen werden häufig für First-Boot-Setup-Skripte verwendet. Es könnte verlockend sein, Geheimnisse wie API- oder Zugriffsschlüssel in den Benutzerdaten zu speichern, so dass diese während der Installation auf die Maschine übertragen werden können. Diese Daten sind jedoch unverschlüsselt und können mit dem Instance Metadata Service oder mit der AWS-Konsole extrahiert werden. Die Speicherung von Geheimnissen in Benutzerdaten ist nicht nur ein Risiko für Angreifer von außen, auch Insider könnten wertvolle Informationen auslesen. Weitere Einzelheiten finden Sie in diesem Video.
Öffentliche Snapshots von EBS-Volumes [7]
Elastic Block Store (EBS) Volumes sind die Festplatten von EC2-Instanzen. Die Verwendung von Snapshots, um die Maschine in einen früheren Zustand zurückversetzen zu können, ist eine gängige und gute Praxis. AWS ermöglicht es Benutzern, ihre Snapshots entweder mit einem bestimmten AWS-Konto oder mit allen Konten (öffentlich) zu teilen. Öffentliche Snapshots können von jedem geklont werden, die im Snapshot befindlichen Daten sind nicht sicher und können leicht extrahiert und auf Geheimnisse untersucht werden. Siehe die Untersuchung von Bishopfox.
Öffentliche Lese-/Schreibberechtigungen für S3-Buckets
Die vielleicht bekannteste Ursache für Datenschutzverletzungen sind falsch konfigurierte S3-Buckets. Diese Buckets erlauben nahezu unbegrenzten Speicherplatz und können so konfiguriert werden, dass sie öffentlichen Zugriff erlauben. Wenn diese Konfiguration vorgenommen wird, reicht es aus, nur den Bucket-Namen zu kennen, um alle Daten zu extrahieren.
Code-Injection-Schwachstellen in Lambda-Funktionen [8]
Sie können für alle möglichen Aufgaben verwendet werden, z. B. für die Kennzeichnung von Objekten, die Bildverarbeitung und Benachrichtigungen. Um diese Aufgaben erfolgreich ausführen zu können, werden den Funktionen häufig über IAM-Rollen Berechtigungen für andere AWS-Services wie S3 oder EC2 erteilt. Wenn das Ereignis abgefeuert wird, wird die Lambda-Funktion ausgelöst und führt den programmierten Code aus. Wenn dieser Code eine Injektionsschwachstelle enthält, könnte ein Angreifer in der Lage sein, die Systemvariablen der Funktion zu extrahieren. Dazu gehören auch die AWS-Anmeldedaten, die für den Zugriff auf andere AWS-Services verwendet werden. Weitere Einzelheiten finden Sie in diesem Video.
In Umgebungsvariablen gespeicherte Geheimnisse in Lambda-Funktionen
Lambda-Funktionen sind serverlose Rechenservices, die die Umgebung überwachen. Bei der Erstellung einer Lambda-Funktion ist es möglich, Umgebungsvariablen zuzuweisen, die vom Code innerhalb der Funktion verwendet werden können. Oft enthalten diese Variablen Geheimnisse, wie API-Schlüssel oder sogar Zugangsdaten. Die Umgebungsvariablen können von einem Angreifer extrahiert werden, wenn eine Code-Injektionsschwachstelle im Code besteht. Außerdem können interne Angreifer die konfigurierten Umgebungsvariablen im Klartext lesen.

Eine anfällige konforme Umgebung

Um zu testen, ob tatsächlich konforme Cloud-Umgebungen für die oben genannten Angriffe anfällig sind, haben wir eine AWS-Testumgebung eingerichtet. Alle diese Schwachstellen wurden mit Hilfe von Terraform zu einsatzfähigen Szenarien entwickelt. Terraform ist ein infra-as-code Software-Tool, mit dem Benutzer Infrastrukturcode definieren können. Dadurch wird sichergestellt, dass die Szenarien jedes Mal, wenn sie bereitgestellt werden, genau gleich sind und keine manuellen Konfigurationen erfordern.

Die AWS-Testumgebung wurde so konfiguriert, dass sie mit den verschiedenen Benchmarks und Sicherheitsstandards übereinstimmt. Dann wurden die Ressourcen mit Terraform bereitgestellt. Nach der Bereitstellung wurde die Umgebung gescannt, um sicherzustellen, dass sie immer noch mit den Sicherheitsstandards konform ist.

Ergebnisse

Jeder Angriff wurde in der Testumgebung ausgeführt. Die Ergebnisse finden Sie in der folgenden Tabelle, wobei X für nicht geschützt steht und andernfalls das entsprechende Steuerelement angezeigt wird:

Die Ergebnisse zeigen, dass der am weitesten verbreitete Sicherheits-Benchmark, der CIS AWS Foundations Benchmark, vor keinem der implementierten Angriffe schützt! Das Framework bietet eine sicherere Umgebung, aber es fehlt ihm an tiefgreifenden Schutzmaßnahmen für beliebte und häufig genutzte AWS-Dienste wie EC2, S3 und Lambda.

Das dreistufige Framework verhindert aufgrund der Kontrollen 1.5 und 1.6. öffentliche EBS-Snapshots, aber andere Angriffe oder Fehlkonfigurationen sind immer noch möglich. Die Kontrollen 1.5 und 1.6 stellen sicher, dass die EBS-Volumes verschlüsselt sind. Dadurch wird verhindert, dass Snapshots öffentlich geteilt werden, da der Entschlüsselungsschlüssel nicht öffentlich zugänglich ist. Dieses Rahmenwerk ist weniger häufig zu sehen, da es schwieriger ist, es auf generische Cloud-Architekturen anzuwenden.

Der Standard AWS Foundational Security Best Practices bietet einen besseren Schutz, insbesondere gegen öffentlich zugängliche S3-Buckets. Die Kontrollen S3.1 - S3.3 regeln ausdrücklich, dass Buckets nicht öffentlich lesbar oder beschreibbar sein dürfen. Dies verhindert den häufigsten Grund für Datenschutzverletzungen im Zusammenhang mit der Cloud. Auch die EC2.1-Kontrolle verhindert EBS-Snapshots. Doch selbst mit dieser Grundeinstellung ist die Umgebung immer noch anfällig für 4 der 6 Angriffe!

Fazit

Diese Untersuchung gibt einen Hinweis darauf, warum wir bei unseren Cloud-Untersuchungen bei Kunden häufig feststellen, dass die oben genannten Angriffe erfolgreich sind. Die Einhaltung eines oder mehrerer Cloud-Sicherheits-Frameworks hilft dabei, eine sichere Umgebung zu haben, reicht aber nicht aus. Im Rahmen unserer Untersuchung haben wir mehrere gängige Angriffe identifiziert und sie mit bekannten Sicherheits-Baselines für AWS-Umgebungen verglichen. Die Ergebnisse zeigen, dass die bestehenden Sicherheits-Frameworks keinen angemessenen Schutz gegen diese häufigen Angriffe bieten. Konformität reicht nicht aus, um eine sichere Umgebung zu haben: Es müssen zusätzliche Prüfungen durchgeführt werden.

Das bedeutet nicht, dass die untersuchten Frameworks nicht verwendet werden sollten oder falsche Empfehlungen geben. Im Gegenteil, diese Frameworks bieten ein Basisniveau an Sicherheit, das vor der Implementierung weitergehender Maßnahmen erforderlich ist. Für unsere Experten bieten die Baselines eine gute Überprüfung der niedrig hängenden Früchte, während ihre Kreativität Ihre Defense-in-Depth testet. Wir empfehlen Ihnen, einen Blick auf Ihre Cloud-Umgebung zu werfen, der über diese Grundregeln hinausgeht, um sicherzustellen, dass Sie vor diesen häufigen Angriffen sicher sind.

Über Secura

Geschrieben von Roy Stultiens. Roy ist einer der Cloud-Experten von Bureau Veritas Cybersecurity. Mit großer Leidenschaft für Cloud-Sicherheit ist er ein aktives Mitglied der Cloud Knowledge Group. Gemeinsam mit dieser Gruppe führt er regelmäßig Cloud-Pentests durch und tauscht sich mit Kollegen und Kunden über seine Erfahrungen in diesem sich schnell entwickelnden Bereich aus.

Fußnoten:

[1] Center for Internet Securtiy: https://www.cisecurity.org
[2] CIS Amazon Web Services Foundations White Paper: https://d0.awsstatic.com/white...
[3] CIS Amazon Web Services Three-tierWeb White Paper: https://d0.awsstatic.com/white....
[4] AWS Foundational Security Best Practices Standard: https://docs.aws.amazon.com/se...
[5] Server Side Request Forgery (SSRF) auf EC2: https: //youtu.be/6U-DpyEoVRs....
[6] In Benutzerdaten gespeicherte Geheimnisse auf EC2-Instanzen: https: //youtu.be/-p5yCrrsTFA
[7] Dufflebag: Aufdeckung von Geheimnissen in offengelegten EBS-Volumes: https://labs.bishopfox.com/tec...
[8] Code-Injection-Schwachstellen in Lambda-Funktionen: https: //youtu.be/gl2hEmN67ms