ECScape: Kritische Schwachstelle in Amazon ECS gefährdet Cloud-Sicherheit

Amazon Elastic Container Service (ECS) ist ein Cloud-Dienst, mit dem Unternehmen Anwendungen in Form von Containern einfach bereitstellen und verwalten können. Jeder Container – oder genauer gesagt: jede einzelne Aufgabe (Task) – erhält dabei automatisch eigene, zeitlich begrenzte Zugangsdaten zu den benötigten AWS-Diensten. Diese sogenannte IAM-Rolle legt genau fest, welche Aktionen ein Task in der Cloud ausführen darf. Dieses fein abgestufte Berechtigungssystem soll dafür sorgen, dass Container nur auf die Ressourcen zugreifen können, die sie wirklich benötigen.

Angriff auf das Herzstück der ECS-Sicherheit

Doch genau dieses Sicherheitsmodell wurde nun von Naor Haziz einem Sicherheitsexperten von Sweet Security, spektakulär ausgehebelt: ECScape ermöglicht es einem Container mit geringen Zugriffsrechten, an die Zugangsdaten anderer, höher berechtigter Container auf derselben physischen Maschine (EC2-Instanz) zu gelangen. Normalerweise ist jeder Container durch seine eigene IAM-Rolle klar begrenzt. Doch durch ECScape kann ein Angreifer diese Grenze überschreiten, sich unbemerkt höhere Berechtigungen aneignen und sich seitlich im System bewegen. So lassen sich vertrauliche Daten auslesen, sensible Cloud-Dienste manipulieren oder sogar die Kontrolle über zentrale Komponenten übernehmen.

So funktioniert der Angriff

Im Kern nutzt ECScape die Tatsache aus, dass ein interner Metadatenservice (169.254.170.2) die temporären IAM-Zugangsdaten für jeden Task bereitstellt. Normalerweise stellt der ECS-Agent sicher, dass nur der jeweils berechtigte Container auf seine eigenen Credentials zugreifen kann. Doch Haziz zeigte, wie ein Angreifer den ECS-Agenten erfolgreich imitieren kann.

Die Angriffskette verläuft wie folgt:

• Der Angreifer beschafft sich zunächst die IAM-Rolle des Hosts (EC2 Instance Role), um den Agenten zu imitieren.
• Anschließend wird der Endpoint der ECS-Steuerungsebene identifiziert, mit dem der Agent kommuniziert.
• Der Angreifer sammelt Metadaten wie Cluster-ARN (Amazon Resource Name, ein eindeutiger Bezeichner, mit dem Amazon Web Services jede Ressource innerhalb der AWS-Infrastruktur eindeutig identifiziert), Container-Instanz-ARN, Agenten- und Docker-Versionen sowie Protokollinformationen.
• Damit erstellt er eine gefälschte WebSocket-Verbindung zum Agent Communication Service (ACS), die scheinbar legitim wirkt.
• Durch Setzen des Parameters sendCredentials: true wird der ECS-Agent überlistet, und der Angreifer erhält die IAM-Credentials aller laufenden Tasks.

Besonders tückisch: Der gefälschte Agentenkanal verhält sich exakt wie ein echter – inklusive Heartbeats, Sequenznummern und Antwortverhalten. So bleibt der Angriff für Monitoring-Systeme weitgehend unsichtbar.

Konsequenzen für die Cloud-Sicherheit

Der Angriff trifft ECS-Setups besonders hart, in denen mehrere Tasks mit unterschiedlichen IAM-Rechten auf derselben EC2-Instanz betrieben werden. Denn: Eine kompromittierte Containerumgebung reicht aus, um Zugriff auf hochprivilegierte Tasks zu erhalten – etwa für das Management von S3-Buckets, Secrets oder administrativen Ressourcen.

Haziz beschreibt es so: „ECScape kollabiert das gesamte Vertrauensmodell. Ein kompromittierter Container kann sich stillschweigend die Rollen aller anderen Tasks aneignen.“

Amazon hat nach einer verantwortungsvollen Meldung der Schwachstelle klargestellt, dass keine Isolierung der IAM-Rollen zwischen Tasks auf EC2-Hosts gewährleistet ist. Die Empfehlung: Kunden sollen auf stärkere Isolierungsmodelle umstellen – etwa durch den Einsatz von AWS Fargate, bei dem jeder Task in einer eigenen VM-ähnlichen Umgebung läuft.

Empfohlene Schutzmaßnahmen

Um die Risiken durch ECScape zu minimieren, sollten Unternehmen folgende Maßnahmen umsetzen:

• Keine gemischten Berechtigungslevels auf einem Host: Tasks mit sensiblen Rechten sollten nie mit unprivilegierten Tasks auf derselben Instanz laufen.
• Fargate statt EC2-Hosts: Die Umstellung auf Fargate bietet echte Isolation und schützt vor diesem Angriffsvektor.
• Instanz-Metadatenservice (IMDS) beschränken: Der Zugriff auf IMDS sollte stark limitiert oder ganz deaktiviert werden.
• ECS-Agent-Rechte einschränken: Nur minimale IAM-Berechtigungen für den ECS-Agent vergeben.
• CloudTrail-Überwachung aktivieren: Ungewöhnliche IAM-Rollenwechsel oder Token-Nutzung können so besser erkannt werden.

Zudem gilt grundsätzlich: Container müssen als potenziell kompromittierbar behandelt werden. Sicherheitszonen und Berechtigungen sollten so gestaltet sein, dass ein einzelner Container im Ernstfall nur begrenzten Schaden anrichten kann.

ECScape steht nicht allein

Die Enthüllung von ECScape reiht sich ein in eine Serie aktueller Cloud-Schwachstellen. In den vergangenen Wochen wurden unter anderem folgende Sicherheitslücken bekannt: Die Angriffsflächen reichen von fehlerhaften Zugriffsrechten über unsichere APIs bis hin zu Schwächen in der Cloud-Konfiguration. Hier eine Auswahl der wichtigsten Vorfälle:

• Google Cloud Build: Eine sogenannte Race-Condition hätte es Angreifern ermöglicht, den vorgeschriebenen Code-Review zu umgehen und nicht freigegebenen Code auszuführen – einfach durch Auslösen des Befehls „/gcbrun“.
• Oracle Cloud Infrastructure (OCI): In einem Editor für Cloud-Code konnten Angreifer Schadcode einschleusen. Wer als Opfer bereits bei Oracle eingeloggt war und eine präparierte Website aufrief, riskierte, dass seine Cloud-Umgebung übernommen wurde.
• Microsoft Entra ID: Die Angriffstechnik „I SPy“ missbraucht einen offiziellen Microsoft-Dienst, um sich dauerhaft Zugriff auf ein System zu sichern und Berechtigungen per Schein-Authentifizierung auszuweiten.
• Azure Machine Learning: Angreifer mit Zugriff auf ein Speicherkonto konnten manipulierte Skripte in eine Machine-Learning-Pipeline einschleusen. So gelang ihnen die Ausführung beliebigen Codes, das Auslesen von Geheimnissen aus Key Vaults und das Ausweiten der eigenen Zugriffsrechte.
• Amazon GuardDuty: Eine zu weit gefasste, ältere AWS-Richtlinie ermöglichte es, von einem gehackten Mitgliedskonto aus die Kontrolle über eine gesamte AWS-Organisation zu übernehmen.
• Azure Arc: Über eine zu starke Azure Connected Machine Resource Administratorrolle konnten Angreifer ihre Kontrolle auf Systeme ausweiten und sogar einen dauerhaften Kommunikationskanal für weitere Angriffe einrichten.
• Azure VPN-Zugänge: Eine Kombination aus überprivilegierten Benutzerrollen und einer Schwachstelle in der Azure API erlaubte es, VPN-Schlüssel auszulesen – und sich so Zugang zu Cloud-Systemen und sogar zu internen Netzwerken vor Ort zu verschaffen.
• Google Gerrit – „GerriScary“ (CVE-2025-1568): In mindestens 18 Google-Projekten – darunter Chromium, ChromiumOS und Dart – konnten Angreifer durch fehlerhafte Rechte und Zeitlücken unautorisierten Code einschleusen. Die Schwachstelle wurde mit einem CVSS-Wert von 8,8 eingestuft.
• Google Cloud Netzwerk-Konfiguration: Eine falsche Einstellung machte interne Subnetze sichtbar, die an Internet-Knotenpunkten (IXPs) verwendet werden. Angreifer hätten dies ausnutzen können, um Zugang zu interner Google-Infrastruktur zu erhalten.
• „ConfusedFunction“ auf mehreren Plattformen: Eine ursprünglich in Google Cloud entdeckte Schwachstelle zur Rechteausweitung wurde inzwischen auch für AWS (Lambda) und Azure (Functions) angepasst. Darüber hinaus lässt sich damit die gesamte Umgebung systematisch auskundschaften.

Fazit: Zero Trust auch für Container

Die zentrale Erkenntnis aus ECScape: Vertraue keinem Container. In modernen Cloud-Umgebungen mit dynamisch bereitgestellten Ressourcen muss Zero Trust auch innerhalb eines Hosts gelten. Entwicklerfreundliche Mechanismen wie IAM-Rollen für Tasks sind nützlich – aber nur sicher, wenn die Isolation tatsächlich gewährleistet ist.

Cloud-Sicherheitsstrategien sollten deshalb nicht nur auf Netzwerkgrenzen und Benutzeridentitäten setzen, sondern auch die Kommunikation und Rechtevergabe innerhalb der Plattform sorgfältig analysieren und absichern. ECScape ist ein eindringlicher Weckruf für alle, die Sicherheit in der Cloud ernst nehmen.

THN/Stefan Mutschler, freier Journalist