Kill Chains von Angreifern in AWS durchbrechen: IAM-Rollen

Im vergangenen Jahr habe ich ein stark gestiegenes Interesse an konkreten Empfehlungen zum Umgang mit Sicherheitsvorfällen in der Cloud mit cloud-nativen Techniken beobachtet. Wenn Unternehmen ihre Produktivlasten in die Cloud verlagern, erkennen die Sicherheitsverantwortlichen schnell, dass die Grundlagen zwar konzeptionell ähnlich, in der Praxis jedoch deutlich anders sind. Eines dieser Kernkonzepte ist die Kill Chain, ein Begriff, der erstmals von Lockheed Martin geprägt wurde, um den Vorgehensprozess eines Angreifers zu beschreiben. Wird ein einzelnes Glied unterbrochen, scheitert der Angriff – das lässt sich gut auf die Kombination aus mehrschichtiger Verteidigung und den aktiven Komponenten der Incident Response übertragen.

In Cloud-Umgebungen gibt es vier wesentliche Angriffskategorien, jede mit einer eigenen Kill Chain:

1. Angriffe auf die Cloud-Plattform selbst. Sieht man von einer grundlegenden Kompromittierung des Cloud-Anbieters ab (die außerhalb des Einflussbereichs des Cloud-Kunden liegt), zielen diese Angriffe typischerweise auf Fehlkonfigurationen von Cloud-Diensten. Wenn Sie einen S3-Bucket öffentlich lassen, keinen Authorizer an einem API Gateway einsetzen oder Ihre Zugangsdaten für AWS auf GitHub offenlegen, fällt das in diese Kategorie.
2. Angriffe auf vom Kunden in der Cloud bereitgestellte Ressourcen und Anwendungen. Diese klassischen Angriffe unterscheiden sich nicht von denen gegen Ihr Rechenzentrum. Gängige Beispiele sind SQL-Injection in einer Webanwendung sowie verwundbare Server mit falsch zum Internet geöffneten Ports. Sie sind meist etwas stärker eingegrenzt als gegen ein Rechenzentrum, sofern Sie Accounts/Subscriptions/Projects und VPCs oder virtuelle Netzwerke nutzen, um den Blast Radius zu begrenzen.
3. Angriffe auf Ihre Cloud-Administratoren und -Entwickler. Lassen Sie beim nächsten Penetrationstest die Angreifer auch versuchen, Ihre Entwickler und Administratoren zu phishen. Das ist einer der besten Wege, um in die Cloud zu pivotieren, denn oft ist es für einen Angreifer deutlich einfacher, Zugriff auf ein Entwicklersystem zu erlangen, als die Cloud-Anwendung selbst zu kompromittieren. Wir behandeln das künftig noch ausführlicher; für den Anfang gilt: „MFA ist mein Freund“.
4. Kombinierte Angriffe. Auf diese Kategorie konzentrieren wir uns heute. Bei diesen Angriffen dringt der Bedrohungsakteur in etwas ein, das in der Cloud bereitgestellt ist, und nutzt das anschließend, um in die Cloud-Management-Ebene zu pivotieren. (Manche würden Angriffe auf Entwickler ebenfalls als kombiniert einstufen, ich betrachte sie jedoch lieber gesondert.)

Als Faustregel gehe ich stets davon aus, dass jeder erfolgreiche Angriff auf jeder Ebene zu einem kombinierten Angriff eskalieren oder pivotieren kann – und ab diesem Punkt sind die Sicherheit Ihrer Management-Ebene und Ihre Incident Response Ihre beste Verteidigung.

Heute konzentriere ich mich auf einen der häufigsten kombinierten Angriffsabläufe und skizziere eine Mischung aus detektiven und präventiven Kontrollen, die helfen, die Kill Chain zu unterbrechen. Bevor ich ins Detail gehe: Verstehen Sie diesen Beitrag nicht als übermäßige Vereinfachung eines komplexen Problems. Das, was ich gleich beschreibe, im großen Maßstab zu handhaben, ist außerordentlich schwierig – selbst wenn Sie wissen, was Sie tun.

In den kommenden Wochen stellen wir unseren Early-Access-Kunden die ersten speziell für diese Problemstellungen entwickelten Ops bereit; relativ kurz danach sollten sie produktiv verfügbar sein.

Der kombinierte AWS-Angriff: Extraktion von IAM-Rollen-Anmeldeinformationen

Bei einem kombinierten Angriff dringt der Bedrohungsakteur in etwas Klassisches ein und nutzt das anschließend, um in die Cloud-Management-Ebene zu pivotieren. Dafür gibt es im Wesentlichen drei Wege. In jedem Fall extrahiert der Angreifer entweder statisch gespeicherte Anmeldeinformationen oder kurzlebige Anmeldeinformationen einer IAM-Rolle, was wir gleich erläutern.

1. Direkte Kompromittierung einer Instanz oder eines Containers. Zum Beispiel, wenn Sie Port 22 offen lassen und der Angreifer sich Zugang verschaffen oder anderweitig Shell-Zugriff erlangen kann.
2. Server Side Request Forgery (SSRF). Der Angreifer nutzt (typischerweise) eine Schwachstelle in einem Webserver bzw. -dienst aus und kann Befehle ausführen, ohne Shell-Zugriff zu erlangen.
3. Kompromittierung einer Lambda-Funktion. Auch wenn Sie auf einem Lambda keine Shell erhalten können, sind sie dennoch anfällig für Schwachstellen bei der Codeausführung und – bei einem Anwendungsfehler – sogar für beliebige Codeausführung. Die konkreten Auswirkungen können denen von SSRF ähneln.

In jedem Fall ist das Ziel des Angreifers, Anmeldeinformationen für die AWS-Management-Ebene zu erlangen und anschließend vorhandene Berechtigungen zu nutzen oder Berechtigungen auszuweiten. Privilege Escalation behandeln wir in einem künftigen Beitrag; hier konzentrieren wir uns darauf, was diese Anmeldeinformationen sind und wie Sie ihren Missbrauch verhindern können.

Die meisten kennen statische Anmeldeinformationen; in AWS sind das ein Access Key und ein Secret Key. Sie entsprechen einem Benutzernamen und einem Passwort, werden aber für AWS-API-Aufrufe verwendet. Die aktuelle Version nutzt für die Signierung der HTTP-Anfragen bei diesen API-Aufrufen ein kryptografisches Verfahren namens Signature 4. Sie können und sollten sie genau wie Benutzername und Passwort behandeln – und Sie sollten sie niemals in Cloud-Ressourcen wie Instanzen oder Lambdas speichern.

IAM-Rollen sind zu Beginn der Arbeit mit AWS kniffliger; sie sind zugleich großartig und beunruhigend. Eine IAM Role in AWS ist im Grunde ein Container für Berechtigungen, den Sie für eine Sitzung nutzen. IAM-Rollen sind großartig, weil sie an sich keine Anmeldeinformationen sind … wenn Sie die Rolle annehmen, stellt AWS einen Satz Anmeldeinformationen für eine zeitlich begrenzte Sitzung bereit. Rollen existieren ausschließlich innerhalb von AWS. Sie können sie Ressourcen innerhalb von AWS zuweisen (etwa einer Instanz oder einer Lambda-Funktion), und diese Ressource kann dann API-Aufrufe tätigen – ohne statische, gespeicherte Anmeldeinformationen! Wir verwenden Rollen für föderierte Identitätsverbindungen, Instanzen, Lambda-Funktionen und jeden anderen Dienst innerhalb von AWS. Access Keys kommen eigentlich nur zum Einsatz, wenn Sie einen Benutzer in einem AWS-Konto anlegen; für alles andere nutzen wir Rollen.

Rollen sind vier Berechtigungsarten zugeordnet:

1. Was die Rolle innerhalb von AWS tun darf. Das sind schlicht die Berechtigungsrichtlinien, die Sie der Rolle zuweisen.
2. Wer oder was die Rolle nutzen darf (die Vertrauensrichtlinie). Das Anlegen einer Rolle bedeutet nicht, dass irgendetwas oder irgendjemand sie nutzen kann; diese Richtlinie beschränkt den Zugriff beispielsweise auf AWS-Instanzen oder eine bestimmte Lambda-Funktion.
3. Eine Berechtigungsgrenze, die den Geltungsbereich der Rolle einschränkt. Das ist etwas komplexer und für unsere heutige Betrachtung nicht relevant, daher behandeln wir es später.
4. Wenn Sie eine Rolle für eine Sitzung annehmen, können Sie zusätzlich eine Teilmenge Ihrer bestehenden Berechtigungen für diese Sitzung festlegen. Das ist eine praktische Funktion für das Least-Privilege-Prinzip, für unsere heutige Betrachtung aber ebenfalls nicht wirklich relevant.

Am einfachsten lässt sich das anhand eines Beispiels erklären. Angenommen, ich habe eine Anwendung, die auf einen S3-Bucket oder eine Dynamo-Datenbank zugreifen muss. Ich erstelle eine IAM-Rolle für die Instanz und setze die Vertrauensrichtlinie so, dass der EC2-Dienst die Rolle nutzen kann. Dann starte ich eine Instanz und weise die Rolle zu. AWS führt die Instanz aus und lässt sie die Rolle annehmen. Durch das Annehmen der Rolle wird eine Sitzung eröffnet und ein Access Key, ein Secret Key sowie ein Session Token zugewiesen. AWS rotiert diese Anmeldeinformationen anschließend alle 1-6 Stunden, und die Instanz kann nun die durch die Berechtigungsrichtlinien autorisierten API-Aufrufe tätigen.

Zwar liegen die Anmeldeinformationen nicht in der Instanz, die Anmeldeinformationen sind für die Instanz aber dennoch zugänglich. Jeder darin laufende Code muss die Anmeldeinformationen kennen, um die eigentlichen API-Aufrufe für den Zugriff auf S3 und Dynamo zu tätigen – daher stellt sie der sogenannte Metadatendienst bei Bedarf bereit. Der Metadatendienst ist eine Besonderheit in AWS für Instanzen und Container und enthält sämtliche Informationen zu deren Konfiguration. Es ist beispielsweise ziemlich wichtig, dass ein Server seine IP-Adresse abrufen kann.

Genau hier setzt der Angriff an.

Der Metadatendienst ist schlicht eine URL, die Sie aufrufen können und die die angeforderten Informationen zurückgibt. curl 169.254.169.254/latest/meta-data/ liefert alle grundlegenden Informationen, und über den Pfad curl 169.254.169.254/latest/meta-data/iam-security-credentials/ erhalten Sie Access Key, Secret Key und Token. (Bei einem Lambda-basierten Angriff sieht das alles anders aus und Sie verwenden SDK-Code statt curl, aber es gelten dieselben Prinzipien.)

Der Angreifer kann diese Anmeldeinformationen dann kopieren und anderswo verwenden, indem er sie in Tools einbettet, statt Code auf dem kompromittierten Server laden und ausführen zu müssen. Da der Metadatendienst zudem URL-basiert ist, öffnet er sich einem breiteren Spektrum von SSRF-Angriffen, weil keine vollständige beliebige Codeausführung erforderlich ist. Die Anmeldeinformationen laufen irgendwann ab, doch je nach Angriff kommen die Angreifer einfach zurück und holen sich einen neuen Satz, sobald die aktuellen nicht mehr funktionieren.

Versierte Angreifer nutzen die Anmeldeinformationen heute in einem AWS-Konto, das sie selbst kontrollieren, da Amazon über Werkzeuge verfügt, um extrahierte und außerhalb der bekannten Adressbereiche verwendete Anmeldeinformationen zu erkennen.

Die Kill Chain der IAM-Rollenextraktion durchbrechen

Zeichnen wir die Kill Chain nach. Der Angreifer muss Folgendes tun:

• Eine Schwachstelle in einer Instanz, einem Container oder einer Lambda-Funktion finden und ausnutzen, die den Zugriff auf die Rollen-Anmeldedaten ermöglicht. Das ist praktisch immer ein Fehler auf Kundenseite … etwa fehlendes Patchen, falsch geöffnete Ports oder die Bereitstellung verwundbaren Codes.
• Die aktuellen Rollen-Anmeldedaten extrahieren.
• Zulässige API-Aufrufe erfolgreich in einer von ihm kontrollierten Umgebung ausführen.
• Innerhalb des Berechtigungsumfangs der zulässigen IAM-Rolle etwas Schädliches tun. Vermutlich etwas Schädliches – die wenigsten Angreifer patchen schließlich Ihren Code für Sie.

Die folgenden Techniken können verschiedene Glieder dieser Kette durchbrechen und umfassen eine Mischung aus detektivischen und präventiven Kontrollen. Lassen Sie sich nicht entmutigen, falls das überwältigend wirkt … nur sehr, SEHR wenige der Organisationen, mit denen ich arbeite, setzen diese umfassend um, insbesondere im großen Maßstab.

6 Techniken, um verschiedene Glieder der Angriffskette zu durchbrechen

1. Schwachstellenmanagement
2. IAM-Berechtigungsrichtlinien nach dem Least-Privilege-Prinzip mit Ressourcenbeschränkungen
3. Bedingte Einschränkungen nach IP, VPC oder anderer Anfrageherkunft in den Berechtigungsrichtlinien verwenden
4. Service-Endpunkte mit Richtlinien + Ressourcenrichtlinien verwenden
5. Metadaten-Proxys mit HTTP-User-Agent-Filtern hinzufügen (Schutz des Metadatendienstes)
6. Schutz vor doppelter Rollennutzung

Schwachstellenmanagement

• Komplexität: Mittel
• Wirksamkeit: Gering
• Skalierbarkeit: Schwierig
• Typ: Detektivisch und präventiv

Wenig überraschend sollten Sie damit beginnen, alle anfänglichen Schwachstellen und Fehlkonfigurationen zu beseitigen, die der Angreifer nutzen kann, um sich seitlich zu bewegen und Anmeldedaten abzugreifen. Ich habe die Komplexität nur als mittel eingestuft, da daran nichts neu oder cloudspezifisch ist. Die Wirksamkeit bewerte ich jedoch als gering, denn umfassendes Schwachstellenmanagement hat die unzähligen Sicherheitsverletzungen der vergangenen Jahrzehnte ja auch nicht verhindert. Vom Konzept her einfach, im großen Maßstab unglaublich komplex.

IAM-Berechtigungsrichtlinien nach dem Least-Privilege-Prinzip mit Ressourcenbeschränkungen

• Komplexität: Mittel
• Wirksamkeit: Hoch
• Skalierbarkeit: Mittel bis schwierig
• Typ: Präventiv

IAM-Richtlinien in AWS verweigern standardmäßig den Zugriff und enthalten explizite Allow- und Deny-Anweisungen. Sie können beispielsweise eine Richtlinie schreiben, die ausschließlich den Lesezugriff auf einen S3-Bucket erlaubt. Sie enthalten außerdem Ressourcenbeschränkungen: Während die Allow-Anweisung die Rolle zum Aufruf der Lese-API berechtigt, erlaubt die Ressourcenbeschränkung der Rolle nur das Lesen bestimmter Buckets oder Objekte. Sie sollten Ihre Verteidigung IMMER hier beginnen. Bei meinen Assessments finde ich in nahezu jedem einzelnen Projekt IAM-Richtlinien mit zu vielen Berechtigungen (den API-Aufrufen) und zu wenigen Ressourcenbeschränkungen. Ja, dieser Service benötigt vielleicht Zugriff auf eine Dynamo-Datenbank, aber braucht er Zugriff auf jede Tabelle? Diese Kontrolle lässt sich in kleinem Maßstab recht gut umsetzen, doch je größer Sie sind und je mehr Menschen diese Richtlinienentscheidungen treffen, desto schwieriger wird Konsistenz im großen Maßstab. Ebenso wichtig ist es, explizite Deny-Anweisungen hinzuzufügen, falls jemand der Rolle eine neue Richtlinie mit neuen Berechtigungen hinzufügt. Berechtigungen sind kumulativ, aber jede Deny-Anweisung überschreibt Allow-Anweisungen.

Bedingte Einschränkungen nach IP, VPC oder anderer Anfrageherkunft in den Berechtigungsrichtlinien verwenden

• Komplexität: Hoch
• Wirksamkeit: Mittel bis hoch
• Skalierbarkeit: Schwierig
• Typ: Präventiv

IAM-Richtlinien unterstützen bedingte Anweisungen mit einer Reihe von Optionen, darunter die IP-Adresse oder die Quell-VPC. Wenn Sie wissen, dass eine bestimmte Rolle API-Aufrufe ausschließlich von einer bestimmten Ressource in Ihrem Anwendungsstack aus tätigen sollte, können Sie die Autorisierung genau auf diese IP-Adresse oder dieses Subnetz beschränken. Stiehlt der Angreifer die Anmeldedaten und versucht, sie anderswo zu verwenden, schlagen die API-Aufrufe fehl. Das ist ein präzisionsgelenkter Vorschlaghammer – konzeptionell einfach, in der Umsetzung schwierig, da andere Komplexitäten die korrekte Implementierung beeinträchtigen können. Beispielsweise gelangen API-Aufrufe an AWS-Services entweder direkt ins Internet, laufen über ein NAT-Gateway oder werden intern über einen Service-Endpunkt geroutet (den wir gleich besprechen). Die erkannte IP-Adresse hängt vom Weg des API-Aufrufs ins Internet ab. All das ist beherrschbar, erkennbar (und automatisierbar), aber Sie sollten sich zunächst einlesen, um die Varianten zu verstehen.

Beispiele finden Sie im ersten Teil dieses Beitrags von Netflix.

Sofern Sie Ihre Lambda-Funktion nicht in einer VPC ausführen, ist dies keine Option zum Schutz einer kompromittierten Funktion.

Service-Endpunkte mit Richtlinien + Ressourcenrichtlinien verwenden

• Komplexität: Mittel
• Wirksamkeit: Mittel bis hoch
• Skalierbarkeit: Mittel
• Typ: Präventiv

In AWS ist ein Service-Endpunkt wie ein Abgriff im Netzwerk, der Datenverkehr, der normalerweise über das Internet zu einem AWS-Service liefe, intern umleitet. Ursprünglich wurden sie geschaffen, damit vollständig private Subnetze in AWS ohne jede Verbindung zum Internet dennoch auf bestimmte AWS-Services zugreifen können. Endpunkte unterstützen Richtlinien, mit denen Sie Zugriff und Aktionen ganz ähnlich wie bei IAM-Richtlinien einschränken können. In diesem Fall fügen Sie der Endpunktrichtlinie Beschränkungen hinzu, die ausschließlich den Zugriff auf bestimmte Ressourcen hinter diesem Endpunkt erlauben (S3 ist das häufigste Beispiel). Sie geben an, welche Buckets zulässig sind, und keine andere Ressource in diesem Subnetz erhält Zugriff auf diesen Service. Betrachten Sie dies als Rückfallebene zur IAM-Richtlinie: Mit einem Service-Endpunkt und einer restriktiven Richtlinie kann die Rolle selbst dann, wenn ihr jemand versehentlich (oder absichtlich) weitergehenden Zugriff einräumt als vorgesehen, auf nichts zugreifen, was die Service-Endpunktrichtlinie nicht erlaubt. Damit haben wir nun drei Richtlinienebenen, die alle den Zugriff auf die Ressource erlauben müssen:

• Die IAM-Berechtigungsrichtlinie, die der Rolle Zugriff auf die Ressource gewährt.
• Die Service-Endpunktrichtlinie, die den Zugriff auf die Ressourcen erlaubt, wenn Anfragen über den Endpunkt eingehen – unabhängig von den Berechtigungen der verwendeten Rolle.
• Die Bucket- oder Ressourcenrichtlinie (abhängig von der Art der Ressource), die den Zugriff auf ausschließlich genehmigte IP-Adressen beschränken kann.

Sofern Sie Ihre Lambda-Funktion nicht in einer VPC ausführen, ist auch dies keine Option zum Schutz einer kompromittierten Funktion.

Metadaten-Proxys mit HTTP-User-Agent-Filtern hinzufügen (Schutz des Metadatendienstes)

• Komplexität: Hoch
• Wirksamkeit: Mittel
• Skalierbarkeit: Schwierig
• Typ: Präventiv

All diese Kontrollen gehen davon aus, dass ein Angreifer die Rollen-Anmeldedaten stehlen kann. Doch was, wenn wir seine Möglichkeiten, an diese Anmeldedaten zu gelangen, verringern könnten, selbst wenn er die autorisierte Instanz oder den Container kompromittiert? (Für Lambda-Funktionen funktioniert diese Technik nicht.) Eine aufkommende Option besteht darin, den Zugriff auf den Metadatendienst von vornherein einzuschränken. Es gab zwar Versuche, dies mit IPTables zu lösen, doch das kann auch benötigte Funktionen des auf der Instanz laufenden Codes beeinträchtigen. Im November 2018 haben AWS und Netflix gemeinsam damit begonnen, Benutzerdaten für API-Aufrufe aus AWS-SDKs in die HTTP-Header aufzunehmen. Das ist eine Abwehr gegen SSRF, denn die meisten SSRF-Angriffe beruhen darauf, eine Anwendung dazu zu bringen, HTTP-Anfragen im Auftrag des Angreifers zu stellen. Diese Anfragen stammen jedoch meist von einem Kommandozeilenwerkzeug wie curl oder einem anderen Prozess und enthalten den Benutzerdaten-Header der AWS-SDKs nicht. Damit das funktioniert, müssen Sie einen Proxy für diese Anfragen einfügen. Für Instanzen und Container gibt es einige Open-Source-Optionen, darunter Proxys, die auf der Instanz selbst laufen, statt dass Sie den Datenverkehr zu einer virtuellen Appliance oder einem Squid-Proxy routen müssen.

Diese Technik funktioniert nicht, wenn der Angreifer die Host-Instanz kompromittiert und eine Shell ausführt, da er dann den Roxy deaktivieren oder den genehmigten Prozess übernehmen kann.

Alle Einzelheiten dazu finden Sie in diesem Beitrag von Netflix.

Schutz vor doppelter Rollennutzung

• Komplexität: Hoch
• Wirksamkeit: Hoch
• Skalierbarkeit: Hoch
• Typ: Detektivisch

Auch dieser Ansatz stammt vom Team bei Netflix. Es hat eine Anleitung für eine hervorragende Technik veröffentlicht, mit der sich erkennen lässt, wenn eine IAM-Rolle an einem nicht autorisierten Ort verwendet wird, selbst innerhalb von AWS. Ich empfehle Ihnen dringend, den verlinkten Beitrag zu lesen. Kurz gefasst: Sie kombinieren CloudTrail-Logs mit weiteren Werkzeugen, um eine Tabelle darüber zu führen, welche Instanzen welche Rollen von welchen IP-Adressen aus nutzen. Anschließend überwachen sie andere API-Aufrufe, um festzustellen, wann eine Rolle von einer neuen IP-Adresse aus wiederverwendet wird, während sie gleichzeitig von einer genehmigten Adresse aus im Einsatz ist. Mit dieser Methode müssen Sie nicht alle in der Organisation genutzten IP-Adressen kennen; Sie bauen dynamisch eine Tabelle der tatsächlichen Nutzung auf und erkennen, wenn diese Rolle gleichzeitig anderswo verwendet wird. Das ist äußerst skalierbar, da Sie die Logik zentral ausführen können, sofern Sie CloudTrail zentralisieren – was ohnehin gängige Best Practice ist.

Zusammenfassung

Dies ist erneut ein sehr umfangreicher Beitrag, und wir erwarten nicht, dass jeder jede dieser Optionen in allen Umgebungen umsetzen kann. Zur Vereinfachung gehen wir die Kill Chain des IAM-Rollenmissbrauchs durch:

• Eine Schwachstelle in einer Instanz, einem Container oder einer Lambda-Funktion finden und ausnutzen, die den Zugriff auf die Rollen-Anmeldedaten ermöglicht. Das ist praktisch immer ein Fehler auf Kundenseite … etwa fehlendes Patchen, falsch geöffnete Ports oder die Bereitstellung verwundbaren Codes.
  • Schwachstellenmanagement (einschließlich Werkzeugen wie SASST und DAST für Anwendungen) und die Bewertung Ihrer Cloud-Konfiguration (mit Werkzeugen wie DisruptOps oder Open-Source-Werkzeugen wie Prowler und CloudMapper) sind Ihre erste Verteidigungslinie.
• Die aktuellen Rollen-Anmeldedaten extrahieren.
  • Schutz des Metadatendienstes und Schwachstellenmanagement
• Zulässige API-Aufrufe erfolgreich in einer von ihm kontrollierten Umgebung ausführen.
  • Erkennung doppelter Rollennutzung, bedingte Einschränkungen nach IP, VPC oder anderer Anfrageherkunft in den Berechtigungsrichtlinien verwenden, Service-Endpunkte mit Richtlinien + Ressourcenrichtlinien verwenden
• Innerhalb des Berechtigungsumfangs der zulässigen IAM-Rolle etwas Schädliches tun. Vermutlich etwas Schädliches – die wenigsten Angreifer patchen schließlich Ihren Code für Sie.
  • IAM-Berechtigungsrichtlinien nach dem Least-Privilege-Prinzip mit Ressourcenbeschränkungen

Hoffentlich vermittelt Ihnen dies ein besseres Bild davon, wie sich der Erfolg solcher Angriffe verringern lässt.