Cloud-Metadaten-Endpunkte: die unterschätzte Angriffsfläche

Jeder große Cloud-Anbieter stellt den virtuellen Maschinen auf seiner Plattform einen Instance-Metadatendienst bereit – üblicherweise erreichbar über die Link-Local-Adresse 169.254.169.254. Aus der Instanz heraus kann eine einfache HTTP-Anfrage an diese Adresse die Konfiguration der Instanz, Netzwerkdetails und – in vielen Standardkonfigurationen – temporäre Sicherheits-Zugangsdaten für die jeweils zugewiesene Rolle oder Identität zurückliefern.

Warum er in Kombination mit SSRF besonders gefährlich ist

Der Metadaten-Endpunkt soll eigentlich nur von der Instanz selbst erreichbar sein – er ist nicht mit dem öffentlichen Internet verbunden. Lässt sich jedoch ein serverseitiger Prozess dazu verleiten, eine HTTP-Anfrage an eine vom Angreifer gewählte Adresse zu senden (klassisches SSRF), und diese Adresse ist zufällig der Metadaten-Endpunkt, ruft der Server seine eigenen Cloud-Zugangsdaten ab und liefert sie in der Antwort aus. Von außen ist kein direkter Netzwerkzugriff auf den Metadaten-Endpunkt nötig – der verwundbare Server erledigt den Abruf im Auftrag des Angreifers.

• 169.254.169.254 liegt im größeren Link-Local-Bereich 169.254.0.0/16, der niemals als legitimes Ziel einer öffentlichen DNS-Auflösung behandelt werden sollte.
• Einige Anbieter sind auf eine tokengeschützte Version des Metadatendienstes umgestiegen, um naiven SSRF-Angriffen gezielt eine höhere Hürde entgegenzusetzen. Die Adresse auf Anwendungsebene komplett zu sperren, bleibt aber die robustere Verteidigung.
• Genau deshalb gehören Link-Local-Adressen in jedem Tool, das vom Nutzer angegebene Domains auflöst, auf dieselbe Sperrliste wie private und Loopback-Bereiche – sie sind keine eigene, harmlosere Risikokategorie.

Die praktische Konsequenz

Jedes System, das im Auftrag eines Nutzers eine URL auflöst und abruft, muss 169.254.169.254 – und den gesamten Link-Local-Bereich, in dem die Adresse liegt – strikt ausschließen. Und zwar bei jeder Anfrage, genau im Moment des tatsächlichen Abrufs, unabhängig davon, wie die Adresse zustande kam (direkt eingegeben oder über einen DNS-Eintrag, der direkt darauf zeigt).

Das Problem beschränkt sich nicht auf einen Cloud-Anbieter

169.254.169.254 ist speziell die Konvention von AWS, Google Cloud und Azure. Das zugrunde liegende Muster – eine Link-Local-Adresse, die Identität und Zugangsdaten der Instanz ausschließlich der Instanz selbst offenlegt – findet sich in nahezu jeder großen Cloud- und Container-Plattform in irgendeiner Form, mal unter derselben Adresse, mal unter einer anbieterspezifischen. Kubernetes-Cluster haben häufig eigene interne, metadatenähnliche Endpunkte, die aus einem Pod heraus erreichbar sind. Die konkrete Adresse sollten Sie sich für die gängigen Cloud-Anbieter merken, doch verallgemeinern lässt sich vor allem das Prinzip: Jeder Endpunkt nach Art eines Metadatendienstes ist für alles tabu, das eine vom Nutzer angegebene URL auflöst und abruft – unabhängig davon, auf welcher Plattform es läuft.

IMDSv2: eine echte Schutzmaßnahme, nicht nur ein Filter

AWS hat auf jahrelange Ausnutzung genau dieses Musters mit einer zweiten Version seines Metadatendienstes reagiert, IMDSv2. Sie verlangt ein Sitzungstoken, das über eine spezielle PUT-Anfrage bezogen wird, bevor Metadaten gelesen werden können – und entscheidend ist: Diese PUT-Anfrage lässt sich nicht durch die einfache, per SSRF ausgelöste GET-Anfrage nachbilden, die die meisten verwundbaren Codepfade tatsächlich absetzen.

Das ist eine spürbare Verbesserung, doch aus Gründen der Abwärtskompatibilität ist sie bei vielen Konten nur optional, und sie schützt ausschließlich den Metadaten-Endpunkt – gegen alle anderen privaten und internen Adressen, die ein SSRF-Angriff weiterhin erreichen könnte, hilft sie nicht. Die Filterung aufgelöster Adressen auf Anwendungsebene bleibt deshalb unabhängig von der verwendeten Version des Metadatendienstes notwendig.