CloudNative Ransomware - Wie Angriffe auf die Verfügbarkeit cloud Dienste ausnutzen

Wie sich Ransomware auf cloud-gehostete Unternehmensdaten auswirkt

Ransomware ist ein finanziell motiviertes Verbrechen mit dem Ziel, Geschäftssysteme zu blockieren und eine Lösegeldzahlung zu erhalten. In der Vergangenheit hat die Erpressung von Daten, die sich in traditionellen lokalen Unternehmenssystemen und Regierungssystemen befanden, den Angreifern mit ransomware -Angriffen reichlich finanziellen Gewinn eingebracht. Mit dem wachsenden cloud Fußabdruck moderner digitaler Systeme versuchen Unternehmen nun herauszufinden, ob ransomware auf cloud basierende Arbeitslasten in gleichem Maße beeinträchtigen kann, und fragen sich außerdem, ob es einen evolutionären Druck auf Angreifer geben wird, der sie dazu zwingt, ihre Taktiken zu entwickeln."

Angesichts der jüngsten Beobachtungen der Trends bei der Einführung von cloud und der Datenmigration komme ich zu folgendem Schluss: Ich sehe nicht, wie ransomware NICHT zu einem größeren Problem für globale Unternehmen werden KÖNNTE.

Meine These zu diesem Thema lässt sich einfach wie folgt zusammenfassen: Wo auch immer kritische Daten sind, ransomware wird mitgenommen. Wenn Geschäftsdaten auf Cloud und nicht etwa in einer lokalen Datenbank gespeichert sind, macht es für Angreifer finanziell Sinn, ihre Taktik so zu entwickeln, dass sie cloud Systeme mit denselben Zielen angreifen wie lokale Systeme.

In diesem Papier werden die Wege aufgezeigt, die ein böswilliger Akteur auf cloud einschlagen könnte, um die Verfügbarkeit von Daten zu beeinträchtigen, indem er die vom Cloud Service Provider (CSP) bereitgestellten Tools nutzt. Zusätzlich zu den Verhaltensweisen der Angreifer habe ich proaktive Schritte zur Absicherung von cloud APIs, die kryptografische Dienste bereitstellen, Architekturmuster, die die Absicherung dieser Systeme erleichtern, sowie Methoden zur Erkennung von cloud-native ransomware skizziert.

Angriff auf die Verfügbarkeit im Cloud

In den ersten mehr als 10 Jahren der Umwandlung von cloud haben sich die Migrationen von cloud und die Ablage immer größerer Datenmengen auf cloud beschleunigt. Selbst wenn wir diesen Wandel miterleben, denken wir oft weiterhin über ransomware ausschließlich im Kontext von On-Premises-Umgebungen nach und dehnen diese Konzepte naiv auf cloud aus.

Auf cloud sind die verfügbaren Werkzeuge, die Entwickler und Kunden zur Erledigung alltäglicher Aufgaben benötigen, bereits integriert und werden von den Dienstanbietern von cloud als Funktionen angeboten. Mit dem Zugang werden dieselben Tools und Funktionen oft von böswilligen Akteuren genutzt, um Sicherheitskontrollen zu überwinden, die Entdeckung zu vermeiden und bestimmte Ziele zu erreichen. Die Nutzung dieser Funktionen in böser Absicht wird oft als Funktionsmissbrauch bezeichnet.

Die Offenheit von cloud-nativen Diensten über APIs macht es Angreifern leicht, entsprechende Tools zu missbrauchen bzw. zu missbrauchen.

APIs, die von jedem CSP erstellt werden, sind leicht auffindbar und können schnell verstanden und auf unbeabsichtigte Weise genutzt werden. Der Missbrauch von Funktionen stellt ein zusätzliches Risiko zu Code-Schwachstellen dar. Anders als bei der Ausnutzung einer Schwachstelle gibt es keinen zu manipulierenden Code-Fehler, der durch Musterabgleich entdeckt oder durch Patches gesichert werden könnte. Stattdessen nutzen Bedrohungsakteure die vom CSP bereitgestellten Tools für die Bereitstellung oder Wartung von Produktionssoftware und -infrastrukturen, um ruchlose Aufgaben zu erfüllen.

Unabhängig von der Umgebung, in der sie sich befinden, werden die Bedrohungsakteure die ihnen zur Verfügung stehenden Werkzeuge nutzen, um ihre schändlichen Aufgaben zu erfüllen. In gewissem Sinne wird ransomware auf cloud durch den Missbrauch öffentlicher APIs den Trend des "Living off the Land" fortsetzen, bei dem die "LOL Binaries" von Cloud die funktionsreichen und öffentlichen APIs sind. Im Gegensatz zu ausführbaren Windows-Programmen, die als überflüssige Software deinstalliert werden können, sind die APIs von AWS cloud immer verfügbar. Offenheit, Zugriff und Verfügbarkeit sorgen weiterhin für die Offenheit, die Dienste benötigen, und geben den Weg frei für verheerende ransomware Angriffe.

Wo werden Ihre Cloud Daten gehostet?

Um zu verstehen, welche Missbrauchstechniken die Betreiber von ransomware anwenden könnten, muss man zunächst die Systeme verstehen, in denen die Daten gespeichert sind. Daten vor Ort werden wahrscheinlich in verschiedenen Technologien gespeichert, von Oracle-Datenbanken bis hin zu Microsoft SQL-Servern. Diese Systeme haben gemeinsam, dass es sich um physische Hosts handelt, die vollständig unter Ihrer Kontrolle stehen.

Bei Data-Warehouse-Servern vor Ort handelt es sich in der Regel um physische Hosts, die in einer Full-Stack-Umgebung implementiert sind und aufgrund der großen Angriffsfläche ein leichtes Ziel für malware darstellen. Full-Stack-Umgebungen profitieren jedoch davon, dass sie durch robuste Datenschutzstrategien gesichert sind, die Sicherheitskontrollen einsetzen, die sich in den letzten 20 Jahren bei der Modellierung netzwerkbasierter Bedrohungen entwickelt haben. So sind herkömmliche lokale Datenbanken hinter Schichten von Netzwerkkontrollen versteckt, in den Tiefen von Unternehmensnetzwerken eingeschlossen und werden mit agentenbasierter Bedrohungserkennung streng überwacht.

Der ortsgebundene Ansatz zur Sicherung herkömmlicher Datenspeicher lässt sich nicht auf cloud übertragen, und das sollte er auch nicht. Die auf cloud migrierten Daten befinden sich in Systemen, in denen alle Endbenutzer, einschließlich böswilliger Akteure, einen begrenzten, eingeschränkten Zugang zum zugrunde liegenden System haben. Das bedeutet, dass cloud Datenspeicher ganz andere Angriffsflächen haben.

Jeder der großen cloud Service Provider (z. B. AWS, AZURE, GCP) verfügt über eine eigene Version eines verteilten, hochverfügbaren Allzweck-Datenspeichers: AWS S3, Azure Blob Storage und GCP Storage Buckets. Jeder von ihnen ist ein zentraler Speicher für unstrukturierte Daten und ein allgegenwärtiger, stabiler und hochverfügbarer Dienst, der mit vielen anderen Diensten auf den jeweiligen Plattformen integriert werden kann und nahezu alle Anforderungen der Kunden an die Datenspeicherung erfüllt. Cloud Anbieter nutzen Speicherdienste zum Aufbau von Pipelines, und sie dienen als Backing-Datenspeicher für Big-Data-Plattformen oder als öffentliche Repositories für Webinhalte.

Wenn Sie ein AWS-Kunde sind, ist es schwer, S3 nicht zu verwenden. Das macht es zu einem wahrscheinlichen Ziel von cloud-native ransomware Autoren.

Traditionelle Ransomware Verschlüsselungsstrategie

Ransomware für lokale Systeme wird ein hybrides Verschlüsselungsverfahren verwendet, das die Vorteile der symmetrischen und der asymmetrischen Verschlüsselung nutzt, um die Einschränkungen beider Verfahren zu ^umgehen1.

Einschränkungen sind:

• Während asymmetrische Verschlüsselungsvorgänge langsam sind, ist die Verschlüsselung von Daten mit einem symmetrischen Schlüssel schnell!
• Bei der symmetrischen Verschlüsselung wird derselbe Schlüssel sowohl für die Verschlüsselung als auch für die Entschlüsselung verwendet. Bei einer rein symmetrischen Strategie verbleibt der Entschlüsselungsschlüssel oft auf dem System, was die Wiederherstellung durch forensische Teams erleichtert.

Die Strategien, die die Autoren von ransomware anwenden, um diese Einschränkungen zu umgehen, sind dieselben Techniken, die auch die internen Krypto-Teams verwenden. Unabhängig davon, ob sie wohlwollende oder böswillige Absichten verfolgen, können Schlüsselhierarchien verwendet werden, um einen Satz von Schlüsseln aus einem anderen abzuleiten und dann die symmetrischen Datenschlüssel zu verschlüsseln.

Durch die Kombination von symmetrischer und asymmetrischer Verschlüsselung können die Autoren von ransomware eine Reihe von komplexeren Zielen erreichen.

• Erhöhte Geschwindigkeit bei der Durchführung von Verschlüsselungsaufgaben
  > Durch das Anvisieren von Daten mit symmetrischen Schlüsseln kann ransomware die Ausnutzung oft abschließen, bevor die Verteidigungsfunktionen eine Chance haben zu reagieren.
• Die Verschleierung des symmetrischen Schlüsselmaterials erschwert die Wiederherstellung bei der Analyse nach der Ausbeutung.
  > Durch die Verschlüsselung des symmetrischen Datenschlüssels mit einem asymmetrischen Schlüssel ist die Wiederherstellung des Schlüsselmaterials für Forensiker schwierig, wenn nicht gar unmöglich.

Die Erstellung von malware zur Durchführung komplexer Verschlüsselungstechniken ist für die Verschlüsselungsdienste vor Ort notwendig. Diese Verschlüsselungsstrategie dürfte jedoch umständlich und völlig unnötig sein, wenn sie auf Daten in cloud abzielt. In diesem Dokument werden Methoden beschrieben, die ein Angreifer einsetzen könnte, um die von cloud angebotenen Tools zu nutzen und die herkömmlichen ransomware Techniken obsolet zu machen.

Verschlüsselung von S3-Objekten mit vom Angreifer kontrollierten KMS-Schlüsseln

Cloud Die Dienstanbieter haben die Schwerstarbeit geleistet, um für ihre Kunden, die ihre Verschlüsselungsdienste nutzen, eine sichere Vertrauensbasis zu schaffen. Angreifer können sich diese Annehmlichkeiten zunutze machen, um die Verfügbarkeit der auf cloud gehosteten Daten zu beeinträchtigen.

AWS Key Management Service (AWS KMS) ermöglicht es seinen Kunden, Schlüssel zu generieren, den Zugriff auf diese Schlüssel zu kontrollieren und sie für kryptografische Operationen wie Signieren, Verifizieren und Verwalten des für S3 Server-Side Encryption (SSE) erforderlichen Verschlüsselungsprozesses zu verwenden.

Wenn kein KMS verwendet wird, werden verschlüsselte Objekte auf S3 mit einem AmazonMaster-Schlüssel verschlüsselt. Wenn eine autorisierte Partei Zugriff auf ein Objekt in diesem Bucket anfordert, entschlüsselt AWS die Daten transparent im Hintergrund. Anstatt AWS die Generierung und Verwaltung der SSE-Backing-Schlüssel zu überlassen, können Kunden einen KMS-Schlüssel verwenden und die mit dem Schlüssel verbundene ressourcenbasierte Richtlinie als weitere Ebene der Zugriffskontrolle für die verschlüsselten Daten nutzen. Die Möglichkeit, Richtlinien anzuwenden und den Zugriff auf einen Schlüssel zu beschränken, bietet Angreifern die Möglichkeit, die Verfügbarkeit der mit dem Schlüssel verschlüsselten Daten zu beeinträchtigen.

Zur Veranschaulichung der Rolle von KMS in SSE sei auf das folgende Szenario verwiesen, in dem ein Betreiber von ransomware erheblichen Zugriff auf S3 und KMS in einem AWS-Konto erhält. Der böswillige Akteur kann Objekte aus S3 lesen, kopieren und löschen sowie die Berechtigung erhalten, einen neuen KMS-Schlüssel zu erstellen. Das Szenario beschreibt außerdem, wie ein Bedrohungsakteur den Zugriff nutzen könnte, um die Verfügbarkeit von Daten zu beeinträchtigen und Lösegeld für deren Wiederherstellung zu verlangen.

Szenario: Demonstration von Cloud-Native Ransomware auf S3

In dem dargestellten Szenario hat es ein Bedrohungsakteur auf die Daten in dem treffend benannten "Opfer-Bucket" abgesehen. In diesem Bucket ist die serverseitige Verschlüsselung (SSE) aktiviert, was bedeutet, dass Objekte transparent mit einem von Amazon verwalteten Hauptschlüssel (SSE-S3) verschlüsselt werden. Ein Endbenutzer, der nur Zugriff auf das Abrufen von Objekten (Aktion s3:GetObject) aus diesem Bucket hat, verfügt über ausreichende Berechtigungen, um den Klartext der gespeicherten Objekte herunterzuladen. Zum Entschlüsseln der Objekte, die mit einem von Amazon verwalteten Hauptschlüssel verschlüsselt sind, sind keine zusätzlichen Berechtigungen erforderlich.

In diesem Szenario gehen wir davon aus, dass ein böswilliger Akteur einen Endbenutzer mit der Absicht kompromittiert hat, Lösegeld für die Daten zu verlangen. Der böswillige Akteur hat einen neuen S3-Bucket erstellt, den wir "Staging-Bucket" nennen und den er als Landezone für gezielte S3-Daten verwenden wird. Für das neu erstellte "staging-bucket" müssen hochgeladene Objekte ebenfalls verschlüsselt werden, allerdings mit einem KMS-Schlüssel. Wir haben den KMS-Schlüssel in AWS generiert und in einem AWS HSM gespeichert und uns dann auf eine vom Kunden verwaltete Richtlinie verlassen, um die Zugriffskontrolle für den Schlüssel durchzusetzen.

Bei der Migration von Daten aus dem "Opfer-Bucket" in das "Staging-Bucket" werden die Objekte mit dem neu erstellten KMS-Schlüssel erneut verschlüsselt. Die mit den S3-Objekten und dem KMS-Schlüssel verbundenen Berechtigungen bestimmen den Zugriff auf die Objekte. Erwarten Sie Antworten auf Zugriffsverweigerung, wenn Anfragen von Anrufern stammen, die keine expliziten Berechtigungen für den Zugriff auf die S3-Objekte und den KMS-Schlüssel haben. Wenn ein Endbenutzer eine explizite "Verweigerungs"-Berechtigung für das S3-Objekt oder den KMS-Schlüssel hat, ist zu erwarten, dass die Zugriffsanfragen ebenfalls verweigert werden.

An diesem Punkt hat unser fiktiver Bedrohungsakteur die Voraussetzungen für einen ransomware Angriff geschaffen, indem er die S3-Objekte auf einen neuen Datenspeicher migriert und die Objekte mit Schlüsseln unter seiner Kontrolle neu verschlüsselt hat. Der nächste Schritt in dieser Geschichte beinhaltet die Beeinflussung des Zugriffs auf den Schlüssel für kryptografische Operationen, wie z. B. die Entschlüsselung.

Key Policy Lock-Out - "DENY, außer wenn; ALLOW, nur wenn"

Die Technik, einen AWS-Kunden von einem KMS-Schlüssel auszuschließen, der sich in seinem eigenen Konto befindet, wurde erstmals von Spencer Geitzen im Cloud Village auf der DEFCON ²⁰²⁰² beschrieben.

Schauen wir uns an, wie eine bösartige Aktualisierung der Schlüsselrichtlinie aussehen könnte.

• DENY - alle Aktionen auf den KMS-Schlüssel - außer wenn der Schlüssel der Bedingung "aws:sourceIp" gleich der vom Angreifer kontrollierten IP ist.
• ALLOW - alle Aktionen auf der KMS-Taste - nur wenn der Anrufer von dem vom Angreifer kontrollierten Konto kommt.

Diese Art des ressourcenbasierten Politikjargons kann man als: "DENY, außer wenn; ALLOW, nur wenn".

Sie können sich vorstellen, dass ein Betreiber von ransomware , der dieses Muster anwenden möchte, andere Bedingungen nutzen kann. Die Anforderung, dass der Anrufer von einer bestimmten Quell-IP-Adresse stammen muss, ist in der Tat ein Mechanismus zur Einschränkung aller Aktivitäten auf einem Schlüssel, aber ebenso effektiv könnte die Verwendung der folgenden globalen AWS-Schlüsselbedingungen sein:

• aws:PrincipalArn
• aws:PrincipalAccount
• aws:sourceVPC
• aws:SourceVPCe

Jede Bedingung, bei der der Aufrufer einen eindeutigen und vom Angreifer kontrollierten Wert benötigt, kann genutzt werden, um einen AWS-Kunden von seinen Ressourcen auszusperren.

Wenn eine ressourcenbasierte Richtlinie, die mit dem KMS-Schlüssel verknüpft ist, auf das Muster "DENY, except when; ALLOW, only when" aktualisiert wird, wird das Opferkonto effektiv von seinen neu verschlüsselten Daten ausgesperrt. Selbst der Root-Benutzer kann nicht auf die verschlüsselten S3-Daten zugreifen.

Nur Anrufer, die von dem vom Angreifer kontrollierten AWS-Konto und der vom Angreifer kontrollierten IP-Adresse ausgehen, können auf den KMS-Schlüssel zugreifen und die S3-Daten entschlüsseln.

Die abschließende Bereinigung eines cloud-nativen ransomware Angriffs würde das Löschen des ursprünglichen "Opfer-Buckets" und das Hochladen einer Lösegeldforderung in ein neues, unverschlüsseltes Bucket umfassen.

Vorhandene KMS-Schlüssel

Der Ausschluss eines Opfers von einem KMS-Schlüssel ist nicht die einzige Möglichkeit, die Verfügbarkeit von S3 zu beeinträchtigen. Es ist jedoch einer der interessanteren Mechanismen, die ein Sicherheitsforscher modellieren kann.

Diese Technik ist nicht auf neue KMS-Schlüssel beschränkt. Die Beeinträchtigung der Verfügbarkeit durch die Beeinflussung eines vorhandenen KMS-Schlüssels würde sogar noch spärlichere Berechtigungen seitens des Bedrohungsakteurs erfordern. Die Aktualisierung einer bestehenden KMS-Schlüsselrichtlinie, um den Zugriff darauf für kryptografische Operationen einzuschränken, hätte die gleiche schwächende Wirkung auf die Datenverfügbarkeit wie die erneute Verschlüsselung von S3-Daten mit einem neuen, vom Angreifer erstellten Schlüssel.

In beiden vorherigen Szenarien wird der Zugang zum symmetrischen Schlüssel, der in der serverseitigen Verschlüsselung (SSE-KMS) verwendet wird, von böswilligen Akteuren durch Manipulation der Schlüsselpolitik als Geisel gehalten.

Wenn das Opfer zahlt

Wir können nicht davon ausgehen, dass wir wissen, wie es für eine cloud-native ransomware -Gruppe aussehen würde, die Kontrolle über den Datenentschlüsselungsschlüssel auf der Grundlage einer traditionellen ransomware vor Ort abzugeben. Auf cloud wird der Prozess der "Schlüsselübergabe" für verschlüsselte Daten anders aussehen, auch wenn er eine notwendige Komponente im Lebenszyklus von ransomwarebleibt. Schließlich ist das Produkt, das ransomware an seine Kunden liefert, ein Mechanismus zur Wiederherstellung verschlüsselter Daten. Wie jedes andere Unternehmen benötigen auch die Betreiber von ransomware ein zuverlässiges und vertrauenswürdiges Mittel, um ihre Produkte an ihre "Kunden" zu liefern.

In Szenario eins können nur Anrufer vom Konto des Angreifers aus auf den KMS-Schlüssel zugreifen, der zur Entschlüsselung geschäftskritischer Daten benötigt wird, aber die Aktualisierung der Schlüsselrichtlinie ist eine Aktion, die ein Angreifer nicht kontoübergreifend durchführen kann. Ein zuverlässiger Echtzeit-Mechanismus zur Rückgabe der Kontrolle an das Opfer kann also keine Aktualisierung der Schlüsselrichtlinie beinhalten. Stattdessen könnte eine ransomware -Bande ihr Augenmerk auf Key Grants richten, einen alternativen Zugriffskontrollmechanismus für KMS-Schlüssel, der zur Delegierung von Berechtigungen für kryptografische Operationen verwendet wird.

Eine ^{KMS-Schlüsselvergabe3} ist eine Übertragung von Berechtigungen an einen Berechtigten, der ein Token zurückgibt, das zur Durchführung kryptografischer Operationen mit diesem Schlüssel verwendet wird. Indem sie einen Key Grant erstellt und dem Konto des Opfers erlaubt, den gekaperten Schlüssel für die Entschlüsselung zu verwenden, kann die ransomware -Bande ihren zahlenden "Kunden" effektiv die Verfügbarkeit zurückgeben und so die Beschränkungen durch die eingeschränkte Schlüsselpolitik umgehen. Eine KMS-Schlüsselgewährung würde es dem Opfer ermöglichen, auf den KSM-Schlüssel zuzugreifen und den Prozess der Wiederherstellung seiner verschlüsselten Daten zu beginnen.

Könnte AWS Sie vor einer Cloud-Native Ransomware Attacke retten?

In Anbetracht der vorangegangenen Erkenntnisse ist es vernünftig, sich bei einem Ransomware Angriff in einer Cloudnative-Umgebung zu fragen, wo das "Modell der geteilten Verantwortung" eine Rolle spielt. Im Folgenden sind einige Überlegungen aufgeführt, die es wert sind, untersucht zu werden.

Das erste Szenario für einen AWS-Eingriff geht davon aus, dass AWS auf KMS-Schlüsselmaterial von einem AWS-HSM zugreifen könnte. Diese Vermutung ist so unplausibel, dass sie völlig außerhalb des Bereiches des Möglichen liegt. Es ist undenkbar, dass AWS einen KMS-Schlüssel von einem seiner HSMs abrufen könnte, die in seinen Rechenzentren untergebracht sind. AWS hat große Anstrengungen unternommen, um sicherzustellen, dass keine Person Schlüsselmaterial abrufen kann, und hat diesbezüglich ernsthafte öffentliche Erklärungen abgegeben.

Die beiden verbleibenden Szenarien für eine AWS-Intervention sind eher eine offene Frage. Die erste Möglichkeit der Unterstützung würde bedeuten, dass AWS die Umgebung des Opfers ändert. Es gibt keine Hinweise darauf, dass AWS eine böswillig angewendete Schlüsselrichtlinie in einem Opferkonto rückgängig machen und den Zugriff auf einen KMS-Schlüssel wiederherstellen kann. Es gibt keine Anzeichen dafür, dass AWS über "göttliche Fähigkeiten" bei ressourcenbasierten Richtlinien verfügt. Es gibt auch keinen großen Anreiz, diese Fähigkeit öffentlich zuzugeben, wenn sie vorhanden wäre.

Die letzte in Betracht zu ziehende unterstützte Abhilfemaßnahme wäre, dass AWS das Konto, in dem die böswilligen Akteure operieren, beschlagnahmt. Das Vertrauens- und Sicherheitsteam von AWS isoliert und schließt betrügerische Konten, die gegen die Nutzungsbedingungen verstoßen, z. B. solche, die in Botnet-Kampagnen verwendet werden. Die Quarantäne und Schließung von Konten ist jedoch etwas ganz anderes als die Übernahme der Kontrolle über die Ressourcen, die erforderlich wäre, um die Kontrolle über einen gekaperten KMS-Schlüssel wiederzuerlangen. Es ist zwar nicht klar, ob AWS über ein Verfahren zur Übernahme von Konten verfügt, aber es gibt einige Hinweise darauf, dass dies der Fall ist.

Bei AWS gibt es einen Mechanismus zum Ändern der Root-E-Mail-Adresse für ein Konto. Sie würden dies in Aktion sehen, wenn Sie jemals das Passwort für Ihren Root-Benutzer vergessen und den Zugriff auf die mit dem Root-Benutzer verknüpfte E-Mail verloren hätten. Der AWS-Support verlangt von Ihnen eine notariell beglaubigte Bestätigung Ihrer Kontoinhaberschaft, bevor er eine Änderung des zugrunde liegenden Root-E-Mail-Kontos vornimmt. Dieser interne Prozess deutet darauf hin, dass AWS die Kontrolle über Konten übernehmen kann und diese nicht einfach schließt, sondern mit administrativen Funktionen auf die darin enthaltenen Ressourcen zugreift.

Wie bei der "Hand Gottes"-Theorie hat AWS wenig Anreiz, die Möglichkeit der Beschlagnahme von Konten zu veröffentlichen. Aus Sicht der Verteidiger ist ohne einen klar dokumentierten Prozess für eine unterstützte Wiederherstellung durch AWS mit garantierten Service-Level-Vereinbarungen eine theoretische Unterstützung bei der Wiederherstellung durch AWS nicht sinnvoll. Die Planung für die Reaktion und Wiederherstellung nach einem ransomware -Ereignis sollte sich nicht auf die Hilfe von AWS konzentrieren und sollte nicht erwartet werden.

Prävention, Erkennung und Reaktion auf Cloud-Native Ransomware

Ausgehend von der Erkenntnis, dass es unwahrscheinlich ist, dass AWS bei einem ransomware -Ereignis helfen kann, richten wir unseren Blick auf das A und O aller Sicherheitsprogramme, auf präventive Kontrollen sowie auf Erkennungs- und Reaktionsmöglichkeiten.

SCP Einschränkung von KMS-Schlüsseln

Abhilfemaßnahmen mittels Service Control Policy (SCP) erfordern einen gewissen Reifegrad Ihres cloud Sicherheitsprogramms, was aber nicht bedeutet, dass ihr Einsatz nicht ein operatives Ziel sein sollte. Die Erstellung einer maßgeschneiderten Richtlinie für KMS-Schlüssel setzt voraus, dass Sie wissen, welche Schlüssel für die Durchführung kryptografischer Operationen an Ihren Daten autorisiert werden sollten und wer Zugang zu ihnen haben sollte.

Eine Service Control Policy (SCP), die die spezifischen KMS-Schlüssel benennt, die für die Verschlüsselung von Objekten zugelassen sind, könnte ein guter Anfang sein, um einen cloud-native ransomware Angriff der in diesem Papier beschriebenen Art zu verhindern. Die Beschränkung kryptografischer Operationen auf bestimmte Schlüssel würde einen Angreifer daran hindern, S3-Objekte böswillig entweder mit einem neu erstellten Schlüssel oder einem externen, von ihm kontrollierten Schlüssel zu verschlüsseln, nicht aber die Richtlinie eines vorhandenen, genehmigten Schlüssels zu missbrauchen.

Häufig wird diese Art von SCP mit einem Architekturmuster gekoppelt, das alle KMS-Schlüssel in einem einzigen Konto zusammenfasst. Dies sollte ein bevorzugtes Entwurfsmuster sein, nicht nur aus Gründen der ransomware Ausfallsicherheit, sondern auch wegen der Vorteile, die eine Zentralisierung mit sich bringt, wie z. B. die Überprüfbarkeit und vereinfachte Schlüsselrotation.

Die Verwendung dieses zentralisierten "Fort Knox"-Ansatzes für die Schlüsselverwaltung führt zu dem Konzept "alle Eier in einem Korb". Er ermöglicht auch den Ansatz "alle Sicherheitskontrollen in einem Korb". Ein zentrales Schlüsselverwaltungskonto ermöglicht es einer Sicherheitsorganisation, das Prinzip der geringsten Privilegien im strengsten Sinne durchzusetzen, eine Basislinie für normale Schlüsselnutzungsmuster festzulegen und abnormale Transaktionen zu überwachen.

S3-Eimer-Konfigurationen

Nicht alle S3-Buckets können als Festungen konfiguriert werden, aber es lohnt sich, auf die in S3 verfügbaren Kontrollen hinzuweisen, die die Gesamtstrategie für die Ausfallsicherheit von ransomware ergänzen können.

• Objekt-Sperre: Eine auf einen S3-Bucket angewandte Konfiguration, die das Löschen eines Objekts oder seiner Version verhindert.
• Objektversionierung: Mit dieser Einstellung wird die Erstellung neuer Objekte erzwungen, anstatt bereits hochgeladene Objekte zu überschreiben. In Kombination mit "Objektsperre" können diese Einstellungen verhindern, dass Objekte mit böswillig verschlüsselten Versionen überschrieben werden. Wenn die Versionierung aktiviert ist, sollten Sie unbedingt Richtlinien für die Verwaltung des Lebenszyklus Ihrer versionierten Objekte festlegen.
• MFA Löschen: Stellt sicher, dass das MFA-Bit im Sitzungs-Token des Aufrufers gesetzt wird, wenn dieser versucht, ein Objekt aus S3 zu löschen. Auch diese Kontrollen sind wahrscheinlich nicht mit hochgradig transaktionalen Daten kompatibel, könnten aber für die Sicherung sensibler Backups in Frage kommen. Voraussetzung für die Durchsetzung dieser Abschwächungsmaßnahmen auf Bucket-Ebene ist, dass Sie wissen, welche Daten Sie haben und wo sie sich befinden.

Aufspüren von Cloud-Native Ransomware

In diesem Beitrag werden zwei Möglichkeiten beschrieben, mit denen ein Bedrohungsakteur die Verfügbarkeit von auf S3 gehosteten Daten beeinträchtigen kann. Unser fiktiver Bedrohungsakteur nutzte eine Methode zur Sperrung von Schlüsselrichtlinien, um die Verfügbarkeit eines neuen KMS-Schlüssels zu beeinträchtigen. Es besteht auch die Möglichkeit, denselben Modus Operandi bei einem vorhandenen Schlüssel anzuwenden. Oder die böswillige Verschlüsselung von S3-Daten mit einem externen KMS-Schlüssel, der sich in einem vom Angreifer kontrollierten Konto befindet. Schauen wir uns jedes der Szenarien an, um zu erörtern, welche Ereignisse in Ihrem CloudTrail eine Untersuchung durch Ihre Mitarbeiter rechtfertigen könnten.

Sperrung der Schlüsselpolicy mit neuem Schlüssel

Wenn ein Bedrohungsakteur diese Technik anwendet, gibt es zwei kritische Punkte, auf die während der Exploitation-Phase reagiert werden könnte: die Beobachtung der Verwendung eines neuen KMS-Schlüssels und die Erfassung der Ereignisse im Zusammenhang mit der Aktualisierung der Schlüsselrichtlinie. Wenn Ihr Unternehmen eine klare Vorstellung davon hat, welche Schlüssel für die Verschlüsselung verwendet werden sollten, sollte die Verwendung von nicht genehmigten KMS-Schlüsseln einen Alarm auslösen. Darüber hinaus sollte die Aktualisierung der Schlüsselrichtlinie, um einen der in diesem Dokument erwähnten globalen Bedingungsschlüssel einzubeziehen, ebenfalls ein Follow-up rechtfertigen.

Sperrung der Schlüsselpolicy mit vorhandenem Schlüssel

Ein Bedrohungsakteur kann sich darauf konzentrieren, einen vorhandenen KMS-Schlüssel anzugreifen. Dies lässt nur begrenzte Möglichkeiten zur Erkennung während der Ausnutzungsphase. Dennoch können benutzerdefinierte Warnmeldungen erstellt werden, um zu benachrichtigen, wenn die Schlüsselrichtlinie aktualisiert wird, um einen der in diesem Dokument erwähnten globalen Bedingungsschlüssel einzuschließen, was bedeuten könnte, dass ein cloud-native ransomware Angriff stattgefunden hat.

Verschlüsselung mit externem KMS-Schlüssel

Dieses Szenario wird in diesem Dokument zwar nicht näher erläutert, ist aber dennoch ein praktikabler Mechanismus für die böswillige Verschlüsselung von Daten. Sicherheitsteams möchten benachrichtigt werden, wenn Verschlüsselungsvorgänge mit KMS-Schlüsseln durchgeführt werden, die sich nicht auf einem Konto unter ihrer Kontrolle befinden.

Fazit

Cloud Dienstanbieter stellen kryptografische Tools zur Verfügung, die, wenn sie nicht ordnungsgemäß gesichert sind, von ransomware -Gangs genutzt werden können, um die Verfügbarkeit von Daten auf cloud zu beeinträchtigen. Eine erfolgreiche ransomware -Kampagne auf cloud nutzt cloud-native Dienste, um Daten schnell zu verschlüsseln, und integrierte Zugriffskontrollmechanismen, um das Opfer von wichtigen Geschäftsdaten auszusperren.

Die Ausarbeitung zentralisierter Architekturmuster für die Schlüsselverwaltung ist der erste Schritt zur Verhinderung von cloud-native ransomware. Eine zentralisierte Schlüsselverwaltung ermöglicht sowohl eine wirksamere Vorbeugung gegen ransomware als auch ein einheitlicheres Bild davon, wie ein normales kryptografisches Muster in Ihrem cloud Anwesen aussieht.

Obwohl eine präventive Haltung ideal ist, ist es unwahrscheinlich, dass die Mehrheit der Unternehmen diese architektonischen Kontrollen vom ersten Tag an hat. Darüber hinaus obliegt es jeder Organisation, selbst denen mit sehr restriktiven Umgebungen, für den Tag zu planen, an dem ihre Leitplanken versagen. Daher sollte die Erkennung, ob die auf cloud gehosteten Daten von ransomware betroffen sind, die oberste Priorität sein. Diese Erkennungsstrategien variieren je nach der vom Bedrohungsakteur verwendeten Technik, basieren jedoch auf dem Konzept, zu wissen, was extern für Ihren cloud -Bestand bedeutet, sei es bei der Überwachung der Gewährung von externem Zugriff, der Verwendung externer Schlüssel oder bedingter Anweisungen in Richtlinien.

---

Referenzen:

¹ Ransomware Verschlüsselungstechniken: https://medium.com/@tarcisioma/ransomware -encryption-techniques696531d07bb9

² Ransom in the Cloud - Spencer Gietzen (DEF CON Cloud Village): https://www.youtube.com/watch?v=8QdZ2- sAQFs&list=PL5944c_fOMYn2cQQuQe23gtqZfHWzyrPn&index=3

³ Berechtigungen in AWS KMS: https://docs.aws.amazon.com/kms/latest/developerguide/grants.html S3 Ransomware Teil 1: Angriffsvektor: https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/ S3 Ransomware Teil 2: Prävention und Verteidigung: https://rhinosecuritylabs.com/aws/s3-ransomware -part-2- prevention-and-defense/