Die Cloud-Vorteile für Nutzer sind auch Vorteile für Angreifer

München/Zürich, den 23.05.2023 – Die Cloud hat den Kontext durcheinandergebracht, auf den sich die Verteidigungskräfte von IT-Systemen bisher meistens gestützt haben, um die Angriffslinien besser zu verstehen. Die Angreifer bewegen sich nicht mehr entlang einer linearen Netzwerkebene, von einer Ressource zu einer anderen, auf denen die Sichtbarkeit auf einer vorhersehbaren Ebene im Netzwerkstapel verfolgt werden konnte. In der Cloud muss dagegen jeder Schritt, den ein Angreifer unternimmt, im Zusammenhang mit der Cloud-Infrastruktur, in der er operiert, verstanden werden.

Vectra AI erläutert einen der besonderen Ansätze, die zur Verteidigung von Cloud-Systemen erforderlich sind, wobei die der Cloud zugrunde liegende Architektur, das daraus resultierende Bedrohungsmodell und schließlich die Art und Weise, wie Angreifer solche Systeme missbrauchen, erörtert werden.

Zunächst ein kurzer Überblick über die klassische On-Premises-Architektur und die Wendepunkte, die Angreifer auszunutzen versuchen: Die Architektur eines Cloud Service Providers (CSP) steht in der Regel im Gegensatz zu einem traditionellen Tech Stack. Es geht zunächst um die Grundlagen der Cloud-Architektur, das neue Bedrohungsmodell und diejenigen Schritte, die Angreifer unternehmen, um in die in der Cloud bereitgestellten Ressourcen einzudringen. Sobald man sich darüber im Klaren ist, warum die Cloud anders ist, wird es um eine cloud-spezifische Art und Weise gehen, mit der Angreifer diese Umgebung für ihre Zwecke missbrauchen, und wie die Verteidigungskräfte über die Sichtbarkeit ihrer Systeme in der Cloud denken sollten.

Das Bedrohungsmodell des traditionellen Tech Stack

Dabei kann es nach Erfahrung von Vectra AI hilfreich sein, sich zunächst einen kurzen Überblick über die Architektur von Rechenzentren zu verschaffen, auch wenn die meisten Leser mit diesem traditionellen Technologie-Stack vertraut sein werden. Die Beschäftigung mit dem Bedrohungsmodell von Architekturen der Rechenzentren ist geeignet, bei der Gegenüberstellung mit dem Cloud-Bedrohungsmodell zu helfen. Dieser Schritt wird uns auch an die impliziten Annahmen erinnern, die man zum Schutz von Systemen besitzt.

Untersuchung von Vektoren der ursprünglichen Gefährdungsfaktoren

Klassische IT-Architekturen können mit ungeschützten Management-Ports zu tun haben, über die Angreifer direkten Zugriff auf einen Server erlangen können.

Wir müssen auch die Risiken im Modell darstellen, die mit Schwachstellen auf der Anwendungsebene verbunden sind, und wie diese extern ausgenutzt werden können, um Zugang zur Ebene des Betriebssystems zu erhalten.

Zu den weiteren häufigen Angriffspunkten auf ein klassisches System gehören die ständig präsenten Phishing-Angriffe, also jene Implantate von Codes, die per E-Mail ankommen, und die Ausnutzung von Schwachstellen auf der Host-Schicht.

Jeder dieser Punkte kann von einem Angreifer verwendet werden, um in einer Umgebung Fuß zu fassen oder um in ein System einzudringen, um ein bestimmtes Ziel zu erreichen – häufig besteht dies in dem Zugang zu vertraulichen Daten.

Die Techniken der Angreifer werden von den Merkmalen des Technologie-Stacks bestimmt

Es mag wie eine offensichtliche Beobachtung erscheinen, dass Angreifer von der bestehenden Umgebung profitieren und ihre Methoden an den Technologie-Stack anpassen, mit dem sie es zu tun haben. Trotz ihrer Einfachheit kann diese universelle Wahrheit dabei helfen, die verschiedenen Vorgehensweisen zu erklären, mit denen Bedrohungsakteure auf lokale Systeme und Cloud-Infrastrukturen abzielen.

Die lokalen Systeme, mit denen es die Angreifer zu tun haben, sind wahrscheinlich mit voll funktionsfähigen Betriebssystemen installiert. Diese Angriffsfläche kann jedoch auch dazu benutzt werden, um sich von einer kompromittierten Workstation zu einem routing-fähigen Server im Rechenzentrum des Opfers fortzubewegen.

Die Server laufen nicht einfach so in der Luft, sondern sind über ein Netzwerk für bestimmte Aufgaben miteinander verbunden. Über dieses Netzwerk können sich Angreifer von Host zu Host bewegen. In der traditionellen Rechenzentrumsarchitektur sind häufig zulässige Egress-Regeln zu beachten. Auf solchen Netzwerkpfaden versuchen Angreifer häufig, über Command-and-Control-Kanäle eine Präsenz aufzubauen und Daten aus einem vertrauenswürdigen Bereich des Netzwerks nach außen weiterzuleiten.

Wie man sieht, wird der Verlauf des im obigen Diagramm dokumentierten Angriffs on-premises durch die dem Angreifer zur Verfügung stehende Oberfläche bestimmt. Im nächsten Abschnitt, in dem es um die Cloud-Architektur geht, kann man feststellen, dass die gleichen Regeln gelten: Der Technologie-Stack bestimmt die Taktiken und Techniken, die Angreifer einsetzen, um ihre Ziele zu erreichen.

Die Cloud-Architektur und das neue Bedrohungsmodell

Die Cloud basiert auf dem Konzept einer gemeinsam benutzten Infrastruktur, bei der Kunden einen bestimmten Zugriff auf einige Schichten des Infrastruktur-Stacks erhalten, um Ressourcen zu erstellen und zu warten. Ein Cloud-Kunde verf?gt über die vollständige Autonomie, um IaaS-Ressourcen zu erstellen, PaaS-Services zu verwenden, Daten zu übertragen und IAM-Richtlinien (Identity and Access Management) zu erstellen, um den Zugriff auf das Netz zu organisieren – und das alles geschieht aufgrund seiner zugewiesenen Berechtigung für einen Teil der Infrastruktur, die der Cloud-Service-Provider bereitstellt und pflegt.

Zu beachten ist: Der Zugriff auf die Funktionen wird delegiert und dem Nutzer über eine Schicht von APIs offengelegt, die allgemein als APIs der Cloud Control Plane bezeichnet werden.

Alle Interaktionen der Endanwender mit einer Cloud-Umgebung werden über die Cloud Control-Plane durch Tausende von öffentlich verfügbaren APIs (Application Programming Interfaces) vermittelt. Die APIs der Control Plane ermöglichen den Nutzern die Durchführung von Verwaltungsaufgaben wie zum Beispiel die Erstellung neuer Umgebungen, die Bereitstellung von Benutzern, die Verwaltung von Ressourcen und den Zugriff auf Daten, die in verwalteten PaaS-Diensten gespeichert sind.

Die API der Control Plane hat folgende Aufgaben:

• Autorisierung von Anrufern, um sicherzustellen, dass sie über die geeigneten Berechtigungen zur Durchführung der angeforderten Aktionen verfügen.
• Weitergabe der Aktion an die nachgelagerte Komponente. Eine Aktion könnte das Einschalten einer VM (virtuellen Maschine) sein, das Kopieren eines Objekts von einem Behälter in einen anderen oder die Aktualisierung der Berechtigungen eines Benutzers.

Die Cloud ist wirklich sehr performant!

Indem alle Funktionen über eine Reihe bekannter, öffentlicher APIs zugänglich gemacht werden, können Unternehmen Geschwindigkeit und Skalierbarkeit in einem Maße nutzen, wie es bisher nicht möglich war. Auf die Cloud zu setzen bedeutet einen riesigen Fortschritt für die IT, und das ist der entscheidende Grund, warum die große Migration zur Cloud in allen Wirtschaftsbereichen ernsthaft im Gange ist. Und dass trotz der zunächst hohen Kosten der Migration und der laufenden Ausgaben für die Cloud-Infrastruktur.

Doch wie sollte man angesichts dieses neuen Paradigmas die Gefahren genau bezeichnen, denen in der Cloud gespeicherte Daten ausgesetzt sind?

In diesem Zusammenhang ist es sinnvoll, sich auf die anfängliche Beeinträchtigung zu konzentrieren, weil dieser Schritt ein hervorragendes Instrument darstellt, um die Ähnlichkeiten und die Unterschiede zwischen Szenarien der Bedrohungen bei On-Premises- und Cloud-Modellen herauszustellen.

Einige Vektoren der anfänglichen Gefährdungen in der Cloud sollten uns dabei bekannt vorkommen. Die anfängliche Beeinträchtigung des Funktionierens in der Cloud kann durch offene Management-Ports bei IaaS-Ressourcen erfolgen. Es ist allgemein bekannt, dass ein offener SSH- oder RDP-Port unerwünschte Aufmerksamkeit erregt. In der Cloud bleiben diese Risiken bestehen.

Auch Schwachstellen auf der Anwendungsebene sind nach wie vor von großer Bedeutung. Unsicherer Code, der in öffentlich zugänglichen Web-Anwendungen eingesetzt wird, führt zumindest zu einer Unterbrechung der Geschäftsabläufe und verschafft Angreifern im schlimmsten Fall ein Standbein in der eigenen DMZ (Demilitarized Zone).

Alle Erfahrungen, die man im lokalen Umfeld mit der Verhinderung und Erkennung einer ersten Beeinträchtigung mittels dieser beiden Vektoren gesammelt hat, werden in der Cloud von Nutzen sein. Die Regeln zur Verhinderung und Erkennung mögen zwar leicht cloud-nativ sein, sind aber grundsätzlich identisch, wenn sie in einer Cloud-Umgebung auftreten.

Aber was ist mit den APIs auf der Steuerungsebene? Hierbei handelt es sich um öffentliche Endpoints, bei denen die Autorisierung durch den Kunden konfigurierbar ist. Diese Angriffsfläche ist völlig neu, und hier werden versierte Angreifer die Eigenschaften der Cloud verwenden, um ihre Ziele zu erreichen.

Wenn man den Verlauf eines Angriffs näher betrachtet, falls ein Angreifer die Control-Plane-APIs im Gegensatz zu einer lokalen Angriffsfläche verwendet, ergibt sich dieses Resultat:

Die anfängliche Kompromittierung über den Einsatz von Phishing ist eine beliebte Taktik von Angreifern, da sie in der Regel funktioniert. Die Auswirkungen der erbeuteten Anmeldeinformationen können sich in die Cloud verlagern, wenn sie zur Authentifizierung und Autorisierung von Aktivitäten in Cloud-Umgebungen verwendet werden.

Es ist unwahrscheinlich, dass die mit der anfänglichen Kompromittierung verbundenen Anmeldeinformationen einen direkten Weg für den Angreifer darstellen. Infolgedessen kann eine der vielen bewährten Techniken zur Erweiterung der Privilegien in der Cloud eingesetzt werden, um zusätzliche Berechtigungen zu erhalten.

Bei Kampagnen wird oft versucht, eine gewisse Form des Widerstands zu erreichen. Auf der Cloud-Kontrollebene sieht das aber ganz anders aus als on-premises. Widerstand in der Cloud bedeutet oft, dass der Zugriff auf Konten durch die Manipulation von IAM-Richtlinien zurückerobert wird.

Wenn wir diesen Angriffsverlauf durchgehen, befinden wir uns nun an einem Punkt, an dem der Zugriff auf das Ziel erlangt wurde. In der Cloud bedeutet dies einfach, dass die entsprechenden IAM-Berechtigungen für den Zugriff auf die in der Cloud gehosteten Daten erlangt wurden. Und schließlich geht es in diesem Szenario um die Eroberung von Daten aus der Umgebung. Auch hier werden APIs der Cloud-Control-Plane verwendet, um Daten aus der Umgebung des Opfers in eine vom Angreifer kontrollierte Umgebung zu verlagern.

Die gesamte Angriffssequenz, von der anfänglichen Kompromittierung bis hin zu den Auswirkungen, wurde über die öffentlich zugänglichen APIs des Cloud Service Providers (CSP) gesteuert. Zu keinem Zeitpunkt kamen die Layer des Netzwerks oder des Hosts ins Spiel. Es waren nicht einmal präventive Kontrollen oder Sensoren in einem Netzwerk möglich.

Das cloud-native Herausziehen von Daten

Ein wesentliches Merkmal jeder CSP-Lösung besteht in ihrem Backbone-Netzwerk. Aber was genau ist ein Backbone-Netzwerk? Ein solches Netzwerk stellt die Service-Schicht des Cloud- Providers dar, die für betriebliche Aufgaben im Hintergrund des CSP verwendet wird: Es geht um das Back-Channel Network, das für die Kommunikation mit der mandantenfähigen Infrastruktur und der Aufrechterhaltung der Verfügbarkeit verwendet wird.

Dieses Backbone bezieht sich auch auf das Netzwerk, das vom CSP zur Übertragung von Kundendaten verwendet wird, im Gegensatz zum Transport von Bytes über das offene Web. Das Backbone-Netz führt dazu, dass viele verwaltete Dienste wie zum Beispiel Cloud-Speicher-Repositories automatisch zu allen anderen Speicher-Repositories des CSP weitergeleitet werden können.

Taktisch betrachtet bedeutet das, wenn man Daten von einem S3-Bucket in ein anderes S3-Bucket verschieben möchte, benötigt man lediglich die entsprechenden IAM-Berechtigungen. Der Netzwerkpfad ist bereits über das Backbone-Netzwerk des CSPs angelegt.

Als Cloud-Kunde ist es nicht möglich, Beschränkungen des Netzwerks für die Daten einzurichten, die sich im cloud-nativen Speicher (siehe Anmerkung 1) befinden, und man besitzt keinen Einblick in das Netzwerk, über das die Daten übertragen werden. So ist es beispielsweise nicht möglich, irgendwelche Protokolle auf der Netzwerkebene zu erstellen, um den Datenverkehr zwischen zwei S3-Buckets zu erfassen. Dies sind attraktive Bedingungen für einen Angreifer, der Daten aus einer Cloud-Umgebung herausziehen möchte.

Mit den entsprechenden IAM-Berechtigungen könnten Daten aus dem Bucket eines Opfers in einen Bucket eines vom Angreifer kontrollierten Accounts verschoben werden, indem API-Anfragen zu Schicht 7 an die Cloud-Kontrollebene gestellt werden. Um dies auszuführen, kontaktiert ein Angreifer ausschließlich die öffentlich zugänglichen APIs der Cloud-Kontrollebene und nutzt das Backbone-Netzwerk des CSP als eine vorkonfigurierte Netzwerkroute, die für den Kunden nicht zugänglich ist.

Die Sichtbarkeit auf der Control-Plane

Daten, die von einem Bucket in einen anderen verschoben werden, hinterlassen keine Spuren, und die meisten Verteidiger sind daran gewöhnt. Protokolle der Netzwerkebene, aus denen hervorgehen könnte, welche Datenpakete vom eigenen Bucket zu einem anderen verschoben wurden, sind für einen Cloud-Kunden nicht zugänglich. Die Datenbewegungen erfolgen über das Backbone-Netz, auf das Cloud-Kunden keinen Einblick haben.

Wie sieht es mit der Sichtbarkeit auf der Host-Ebene aus?

Cloud-native Speicher wie S3-Buckets, Azure Storage Blobs und dergleichen sind allesamt verwaltete Dienste. Der Kunde hat keinen Zugriff auf die Ebene der Host- oder Betriebssysteme, wie es beim Modell "Infrastruktur als Service" der Fall ist. Auf verwalteten Diensten können keine Agenten eingesetzt werden.

Bleibt also noch die Steuerungsebene übrig. Keine der von einem Angreifer durchgeführten Aktionen könnte mit traditionellen Sensoren identifiziert werden, aber es tauchen Indikatoren für die Aktivität in den Protokollen auf, die von der Cloud-Kontrollebene geschrieben werden. Alle Handlungen auf den Ebenen von Ressourcen und den in der Cloud gehosteten Daten werden von den Proxy-APIs der Cloud-Kontrollebene autorisiert und führen zu einer Art von Aufzeichnung.

Die Aktionen der eigenen Entwickler werden aufgezeichnet, wenn sie ihre Buckets erstellen, auch das normale Verarbeiten und Lesen von Daten wird aufgezeichnet und führt zu entsprechenden Ereignissen. Und umgekehrt werden die Handlungen von Angreifern, die APIs der Cloud Control-Plane verwenden, als solche aufgezeichnet.

Diese Aufzeichnungen von Ereignissen geben Aufschluss über die eigene Cloud-Umgebung, das heißt darüber, wer von wo aus und mit welchen Anmeldeinformationen auf was zugegriffen hat, nicht aber über die Absichten des jeweiligen Benutzers. Um festzustellen, ob eine bestimmte Handlung in böswilliger oder in gutartiger Absicht erfolgte, sind zusätzliche Hinweise auf den Kontext erforderlich, und oft muss die ganze Umgebung durch eine wesentlich größere Brille betrachtet werden.

Abschließende Überlegungen

Die Schlussfolgerungen von Vectra AI: Angreifer werden die einzigartige Architektur der Cloud und der cloud-nativen Dienste aus demselben Grund verwenden, aus dem Entwickler die Cloud einsetzen: Sie ist schnell! Sie skaliert ohne Probleme! Und die APIs der Cloud Control Plane helfen ihnen dabei, ihre Ziele zu erreichen.

Die Control-Plane ist der Ort, an dem man Beweise für bösartige oder andere Aktivitäten in einer Cloud-Umgebung finden kann. Eine netzwerk- und hostbasierte Überwachung bietet einem allein nicht die nötige Transparenz.

----

Anmerkung (1): Service-Kontrollen mit VPC (Virtual Private Cloud): Nur Google Cloud bietet Funktionen zur Durchsetzung von Perimetern für verwaltete Dienste, die nicht an VPCs gebunden sind. Mehr hierzu: https://cloud.google.com/vpc-service-controls#section-6.

# # # ENDE # # #

Vectra ist ein führender Anbieter von intelligenten Lösungen für Netzwerkerkennung und Reaktionen in hybriden und Multicloud-Umgebungen. Vectra bietet diese Lösungen für On-Premises-Netzwerke und die Cloud an (IaaS, SaaS und PaaS). Der Hersteller verwendet dabei speziell entwickeltes, patentiertes Machine Learning (ML) und Artificial Intelligence (AI), die 97 Prozent der netzwerkbasierten Techniken von MITRE ATT@CK abdecken.

Pressekontakt

tech2com UG (haftungsbeschränkt)
Philipp Haberland
0049 163 2722 363
p.haberland@tech2com.de