UPDATE: Dieser Beitrag wurde aktualisiert, um neue Informationen zu berücksichtigen, die in Zusammenarbeit mit den AWS S3 Replication-, CloudTrail- und Sicherheitsteams gewonnen wurden.
Eine umfassende Backup-Strategie ist ein Eckpfeiler eines jeden Notfallplans. Aber wie können Sie zwischen legitimen Backup-Aktivitäten und böswilliger Datenexfiltration unterscheiden?
Cyber-Angreifer verschaffen sich zunehmend Zugang zu cloud Kontrollplattformen, die Funktionen zur Durchführung von cloud-nativen Backups enthalten. Im Folgenden werde ich zeigen, wie diese Tools genutzt werden können, um Daten aus der Produktionsumgebung eines Unternehmens zu exfiltrieren.
In diesem Blog sehen Sie sich genau an, wie ein Angreifer S3 Replication missbrauchen kann, um Ihre Daten effizient aus Ihrer Umgebung zu migrieren. Ich hoffe, die Lektüre ist genauso unterhaltsam wie die Erstellung des Blogs.
Sie werden sehen, wie sich dieser Angriff in verschiedenen Erzählsträngen aus der Perspektive von vier verschiedenen Akteuren abspielt, die hier aufgeführt sind.
- Der S3-ReplikationsdienstDer S3 Replication Service ist ein Dienst, der die Replikationsregeln befolgt, um S3-Daten über Buckets hinweg zu replizieren.
- Der böse S3-ReplikationsdienstDer böse S3-Replikationsdienst, der dazu missbraucht wird, Daten an externe Speicherorte zu kopieren.
- Der Angreifer der die Kontrolle über den S3-Replikationsdienst erlangt, den Dienst für seine Zwecke missbraucht und dessen fehlende Protokollierung nutzt, um unerkannt zu bleiben.
- Mitglieder des SOC-Teams (Security Operations Center), die erfahren, dass sie für Datenbewegungen über den S3 Replication Service teilweise blind sind, können nun ihre Erkennungsstrategie ändern, um dies zu kompensieren.
Einführung in den S3 Replikationsdienst, seine Möglichkeiten und Anwendungsfälle für gute
Der AWS S3 Service ist nicht mehr der "Simple Storage Service", für den er ursprünglich gehalten wurde. Mit Dutzenden von Funktionen und Integrationen ist er der Datenspeicher der Wahl für AWS-Unternehmenskunden geworden. Außerdem ist er so kompliziert, dass es schwierig ist, alle seine Funktionen zu verstehen und damit zu sichern. Eine der zahlreichen Funktionen von S3 ist die Möglichkeit, Daten über Regionen und Konten hinweg zu kopieren und aktive Backups Ihrer Daten zu erstellen.
Wie Sie in diesem Beitrag sehen, kann diese Funktion missbraucht werden, und es kann schwierig sein, Einblick in sie zu erhalten.
Der Replikationsservice in AWS tut genau das, was Sie vielleicht denken: Wenn er mit Regeln gesteuert wird, kopiert er S3-Daten zwischen Buckets.
Der Dienst erhält seine Befehle von den Replikationsregeln. Sie können Regeln konfigurieren, um den Dienst anzuweisen, Daten in mehrere Buckets zu kopieren und so mehrere Replikate desselben Quellobjekts zu erstellen.
Die Ziel-Buckets müssen sich nicht einmal in der gleichen Region oder im gleichen Konto wie der Quell-Bucket befinden.
Seine Datenreplikationsfunktionen sind nur möglich, wenn dem Dienst die entsprechenden Berechtigungen erteilt werden. Um den S3 Replication Service zu aktivieren, konfigurieren Sie ihn so, dass er eine IAM-Rolle annimmt, der IAM-Berechtigungen für den Zugriff auf Quell- und Ziel-Buckets gewährt werden.
Welche Folgen hat es, wenn ein Angreifer die Fähigkeit erlangt, S3 Replication in AWS zu nutzen?
Die kontoübergreifende Replikation kann Unternehmen bei der Wiederherstellung nach einem Datenverlust unterstützen. In den falschen Händen jedoch ermöglicht der Replikationsdienst Bedrohungsakteuren, Daten an nicht vertrauenswürdige Orte abzuschöpfen.
Der S3-Replikationsdienst hat ein hohes Missbrauchspotenzial und ist daher ein bevorzugtes Ziel für Angreifer.
Wenn ein Angreifer in der Lage wäre, Replikationsregeln zu erstellen, könnte er den S3 Replication Service anweisen, Daten in einen vom Angreifer kontrollierten, externen Bucket zu kopieren. Sogar einen, der sich außerhalb der AWS-Organisation des Opfers befindet.
Welche IAM-Berechtigungen sind für die externe Replikation erforderlich?
Der S3-Replikationsdienst benötigt Berechtigungen für S3-Objekte, um sowohl das Objekt aus dem Quell-Bucket zu holen als auch das Objekt in den externen, vom Angreifer kontrollierten Bucket zu replizieren.
Hier ein Beispiel für eine IAM-Richtlinie, in der die für die Replikation erforderlichen Aktionen definiert sind, in der aber die Berechtigungen für eine Ressource nicht festgelegt sind, so dass das Ressourcenfeld mit "*" angegeben ist. Diese Richtlinie ist so freizügig, dass sie es dem S3-Replikationsdienst ermöglicht, Objekte in jeden Bucket zu kopieren, auch in Buckets außerhalb Ihres Kontos.
Bei einer allzu freizügigen Richtlinie müsste ein Angreifer in der Lage sein, Replikationsregeln zu aktualisieren und den Replikationsdienst anzuweisen, Daten in einen vom Angreifer kontrollierten Bucket zu kopieren. Für die Objekte selbst sind keine Berechtigungen erforderlich, sondern nur die Möglichkeit, Regeln zu aktualisieren.
Kurz gesagt: Anstatt Daten direkt aus einem Konto zu kopieren oder zu verschieben, kann der S3-Replikationsdienst von einem Angreifer ausgenutzt werden, um dieselben Aktionen in seinem Namen durchzuführen, und zwar als Ergebnis einer bösartigen Replikationsregel. Hierbei handelt es sich nicht um einen Fehler, der behoben werden kann, sondern um eine Art von cloud Schwachstelle, die als "Funktionsmissbrauch" bezeichnet wird.
Wie protokolliert der S3-Replikationsdienst seine Aktivitäten? Und wie hilft das einem Angreifer, unbemerkt zu bleiben?
Die autorisierte Bewegung von Daten über den S3-Replikationsdienst ist wenig transparent, was es besonders schwierig macht, nach Datenexfiltration zu suchen, und es einem Angreifer ermöglicht, seine Aktivitäten in Ihrer cloud Umgebung zu verbergen.
Schauen wir uns an, wann und wohin der Replikationsdienst Ereignisse in CloudTrail schreibt, basierend auf Ihren Data-Plane-Trail-Konfigurationen Bucket Scoping.
Um Einblick in Ereignisse zu erhalten, die S3-Objekte betreffen, müssen Sie sich für die Sammlung von S3-Datenereignissen entscheiden. Der Umfang dieser Ereignisse kann so konfiguriert werden, dass er "alle aktuellen und zukünftigen S3-Buckets" umfasst, oder es können einzelne Buckets aufgezählt werden. Diese CloudTrail-Einstellung dient als Filtermechanismus, um bestimmte Buckets in die S3-Data-Plane-Protokollierung einzubeziehen.
Wenn Daten vom S3-Replikationsdienst kopiert werden, wird ein GetObject-Ereignis ausgelöst, da der Dienst das Objekt bei der Replikation abgreift. Dieses Ereignis wird in den CloudTrail des Quellkontos geschrieben.
Nach dem GetObject-Ereignis wird das PutObject-Ereignis, das den Zielbereich angibt, sowohl im externen Zielkonto als auch im Quellkonto aufgezeichnet.
Wie verhält sich das CloudTrail S3 Data-Plane Logging, wenn die Logs auf bestimmte Buckets beschränkt sind?
Um die Kosten unter Kontrolle zu halten, aktivieren Unternehmen häufig S3-Data-Plane-Protokolle nur für ihre hochwertigen Buckets, anstatt für die Protokollierung aller aktuellen und zukünftigen Buckets zu zahlen. Wie verändert diese Protokollierungskonfiguration die Sichtbarkeit des S3-Replikationsdienstes?
Im Anschluss an das GetObject-Ereignis kann im Zielkonto ein PutObject-Ereignis in Übereinstimmung mit der CloudTrail-Konfiguration des Zielkontos aufgezeichnet werden. Insbesondere wird im Quellkonto kein PutObject-Ereignis aufgezeichnet.
In der Praxis bedeutet dies, dass es beim Kopieren von Daten durch den Replikationsdienst keinen Eintrag im CloudTrail des Quellkontos gibt, aus dem der externe Ziel-Bucket hervorgeht.
Wenn CloudTrail so konfiguriert ist, dass S3-Data-Plane-Ereignisse von bestimmten Source-Account-Buckets erfasst werden, entsteht eine Lücke in der Protokollierung, die das Kopieren von Daten ohne Aufzeichnung des Data-Plane-Ereignisses PutObject im Source-Account ermöglicht.
Ohne Data-Plane-Protokolle, die die Protokolle aller aktuellen und zukünftigen Buckets enthalten, könnte ein Angreifer die Replikationsregeln aktualisieren, um Objekte in seinen externen Bucket zu replizieren - und sich entspannt zurücklehnen, während der Replikationsdienst stillschweigend Daten aus dem Unternehmen verschiebt.
Glücklicherweise sind die präventiven Kontrollen eindeutig.
Wie immer, wenn Sie AWS IAM-Identitätsrichtlinien definieren, lassen Sie das Ressourcenfeld nicht leer, damit die Richtlinienberechtigungen für jede Richtlinie gelten können. Stellen Sie sicher, dass die IAM-Rolle, die der Replikationsservice annimmt, explizit auflistet, mit welchen Buckets er arbeiten darf.
Was sind die Folgen für cloud Verteidiger?
Theaterveteranen können die böswillige Aktualisierung von Replikationsregeln als Hinweis darauf nutzen, dass in ihrer Umgebung möglicherweise unbemerkt eine Datenexfiltration stattfindet.
Wenn man bedenkt, wie vermeidbar Service-Missbrauch mit dem S3 Replication Service ist und warum ist dieser Mangel an Sichtbarkeit für die Bedrohungsjäger und cloud Verteidiger der Welt von Bedeutung?
Um zu verstehen, warum diese Unstimmigkeiten bei der Protokollierung von Bedeutung sind, müssen wir die Aufgabe des Verteidigers in einem Unternehmen erörtern. Cloud Verteidiger stellen ständig Fragen zur cloud Umgebung auf der Suche nach Anzeichen für eine Gefährdung. Ihre Aufgabe ist es, zu erkennen, wenn die Dinge aus dem Ruder laufen - trotz aller Bemühungen um Präventivmaßnahmen.
Das A und O eines Verteidigers sind die Protokolle, die er zur Erkennung verwendet, um Frühwarnsignale zu liefern, dass Daten aus dem Umkreis fließen. Die den Verteidigern zur Verfügung stehenden Data-Plane-Protokolle können auf bekannte, hochwertige Buckets beschränkt werden, um Kostengründe zu berücksichtigen und die schiere Menge der Data-Plane-Protokolle zu reduzieren, die bei der Erfassung aller Daten erzeugt werden können.
Wenn Daten kopiert werden können, ohne dass eine Aufzeichnung des Ziel-Buckets erfolgt, können Verteidiger nicht umfassend auf die Exfiltration von Daten hinweisen oder danach suchen, indem sie in Data-Plane-Ereignissen wie CopyObject- oder PutObject-Ereignissen nach schlechten Buckets suchen.
Die Verteidiger müssen die Ereignisse, die sie überwachen, auf die Aktualisierung von Replikationsregeln ausweiten, um eine umfassende Überwachung ihres Datenperimeters zu gewährleisten.
Wenn ein SOC nicht in der Lage ist, die Protokollierung der S3-Datenebene für "alle aktuellen und zukünftigen Buckets" zu erzwingen, ist die Überwachung des Ereignisses "PutBucketReplication" und die entsprechende Warnung der einzige Ort, an dem ein Verteidiger Einblick in externe Ziel-Buckets erhält. Dieses Ereignis zeigt nicht an, dass Daten kopiert wurden, sondern nur, dass der Replikationsdienst eine Regel zum Kopieren von Daten konfiguriert hat.
Lehren aus dem Missbrauch des Replikationsdienstes
Der S3-Replikationsdienst kann Unternehmen dabei helfen, widerstandsfähiger gegen Ransomware zu werden. Bei der Erstellung unseres Bedrohungsmodells ist es jedoch wichtig, bösartige Benutzergeschichten zu erstellen, damit wir die Fähigkeiten von cloud aus der Sicht eines Angreifers betrachten können.
Aufgrund der Kosten zögert ein typisches Unternehmen möglicherweise, die S3-Protokollierung auf der Datenebene für alle Buckets in einem Konto zu aktivieren, und zieht es vor, Protokolle nur für hochwertige Buckets selektiv zu erfassen. Wie wir gesehen haben, führt diese Strategie zu einer Lücke in der S3-Exfiltrationstransparenz, da das PutObject-Ereignis nicht in das Quellkonto geschrieben wird.
Im August 2022 hatte sich AWS geweigert, das Protokollierungsproblem mit dem S3-Replikationsdienst zu beheben. In der Diskussion mit AWS wurden die folgenden Lösungen oder "Feature Requests" vorgeschlagen.
- Den Zielbereich in das GetObject-Ereignis einbeziehen
- Betrachten Sie die GetObject- und PutObject-Ereignisse vorzugsweise als Paare - schreiben Sie diese beiden Ereignisse als Ergebnis des Scoping-Filters des Quellbereichs in das Quellkonto, anstatt den Data-Plane-Log-Bereich des Zielbereichs zu berücksichtigen.
Zeitplan für die Berichterstattung
10/19/21
[Vectra]: Erster Schwachstellenbericht eingereicht und Empfang am selben Tag bestätigt.
10/20/21
[AWS]: Sie antworteten mit dem Hinweis, dass sie nicht glauben, dass es sich um eine Sicherheitslücke handelt:
"Wir glauben nicht, dass das von Ihnen in diesem Bericht beschriebene Verhalten ein Sicherheitsproblem darstellt, sondern dass es ein erwartetes Verhalten ist. Wir bieten CloudWatch-Alarmierung, die alle Änderungen an der Replikationsrichtlinie eines Buckets protokolliert [1], was bei dem beschriebenen Bedrohungsmodell Einblick in das Ziel der Daten geben würde. Siehe den Abschnitt "S3BucketChangesAlarm".
10/20/21
[Vectra]: Bitte um Bestätigung, dass AWS das Fehlen der Protokollierung nicht als Schwachstelle betrachtet. Angedeutet, dass ich die Antwort von AWS auf diesen Bericht bei jeder öffentlichen Bekanntgabe als "wird nicht behoben" darstellen werde.
10/26/21
[AWS]: AWS fragte, wo ich die Offenlegung veröffentlichen würde und ob sie eine Vorabkopie des Textes erhalten könnten.
10/26/21
[Vectra]: Sie bestätigten, dass sie eine Vorabkopie jeder Veröffentlichung erhalten können.
2/2/22
[Vectra]: Ich habe den ursprünglichen Schwachstellenbericht erneut an einen internen Kontakt im AWS-Sicherheitsteam geschickt und ihm vorgeschlagen, eine verbesserte Protokollierung für den S3-Replikationsservice anzufordern.
2/3/22
[AWS]: Sie haben bestätigt, dass sie das Ticket intern eingereicht haben.
7/20/22
[Vectra]: Veröffentlichte erste Untersuchungen zu diesem Thema, in denen das Protokollierungsproblem als nur dann auftretend beschrieben wurde, wenn die Replikationszeitsteuerung (RTC) aktiviert war.
7/25/22
[Vectra]: Erneut getestete Funde, um einen Mangel an Protokollierung zu entdecken, der mit oder ohne aktivierter RTC auftritt.
7/26/22
[Vectra]: Präsentierte Ergebnisse bei fwd:cloudSec
8/18/22
[Vectra und AWS]: Treffen zur Besprechung der Ergebnisse. Bei diesem Treffen wurde festgestellt, dass der CloudTrail S3 data-plane scoping filter der Mechanismus ist, der steuert, ob ein PutObject-Ereignis in das Quellkonto geschrieben wird oder nicht.
[1] https://docs.aws.amazon.com/awscloudtrail/latest/userguide/awscloudtrail-ug.pdf