Was ist SSRF und warum ist der Cloud-Metadaten-Dienst ein Ziel?
Kurzantwort
SSRF bringt einen Server dazu, HTTP- (oder andere) Anfragen an ein vom Angreifer gewähltes Ziel zu stellen, und missbraucht die Netzwerkposition des Servers, um interne Dienste hinter der Firewall zu erreichen. In der Cloud ist es besonders gravierend, weil der Instanz-Metadaten-Dienst (z. B. 169.254.169.254) IAM-Anmeldedaten zurückgeben kann und so ein SSRF zur Kompromittierung des Cloud-Kontos macht.
Server-Side Request Forgery (SSRF) liegt vor, wenn eine Anwendung eine URL oder Adresse aus der Nutzereingabe übernimmt und vom Server aus eine Anfrage daran stellt. Denk an eine Funktion, die ein entferntes Bild abruft, einen Webhook validiert oder ein Dokument über einen Link importiert. Der Angreifer liefert eine URL, die der Entwickler nie vorgesehen hat, und der Server — der innerhalb der Vertrauensgrenze sitzt — stellt die Anfrage im Auftrag des Angreifers.
Warum die Position des Servers der Gewinn ist
Der Server kann Dinge erreichen, die der Angreifer nicht erreichen kann: interne Admin-Oberflächen, Datenbanken, andere Microservices und Link-Local-Adressen, alle hinter der Firewall. SSRF verwandelt den verwundbaren Server damit faktisch in einen Proxy ins interne Netzwerk und ermöglicht internes Port-Scanning und das Erreichen nicht authentifizierter interner APIs. Die Formen, die diese Anfragen annehmen — Link-Local-Adressen, Schema-Tricks, Codierungs-Umgehungen —, sind in Sammlungen von SSRF-Payloads katalogisiert.
Die Cloud-Metadaten-Wendung
Cloud-Instanzen stellen einen Instanz-Metadaten-Dienst unter einer Link-Local-Adresse bereit (AWS/GCP/Azure nutzen 169.254.169.254). Er gibt die Instanzkonfiguration zurück — und entscheidend temporäre IAM-Anmeldedaten für die der Instanz zugewiesene Rolle. Ein SSRF, das diesen Endpunkt erreicht, kann diese Anmeldedaten lesen und gegen das Cloud-Konto einsetzen und so einen einzelnen Web-Fehler zu einer breiten Cloud-Kompromittierung eskalieren. Dies ist der Weg hinter mehreren großen Sicherheitsverletzungen.
Gegenmaßnahmen
- IMDSv2 (AWS) erfordert ein Sitzungstoken, das über eine
PUT-Anfrage mit Hop-Limit bezogen wird, was ein einfaches SSRF-GETnicht leisten kann — und blockiert so den Weg des Anmeldedaten-Diebstahls. - Setze ausgehende Ziele auf eine Zulassungsliste statt auf eine Sperrliste; Sperrlisten übersehen DNS-Rebinding, Weiterleitungen, IPv6, dezimale/oktale IP-Codierungen und
0.0.0.0. - Löse die Ziel-IP nach der DNS-Auflösung auf und validiere sie, deaktiviere nicht benötigte URL-Schemata und isoliere den abrufenden Dienst in einem eingeschränkten Netzwerksegment.
Prüfer achten auf die Definition, dass der Server vom Angreifer gewählte Anfragen stellt, auf die Eskalation über Metadaten/IAM-Anmeldedaten, auf IMDSv2 und auf die Erkenntnis, dass Sperrlisten fragil sind, weshalb Zulassungslisten bevorzugt werden.
Wahrscheinliche Anschlussfragen
- Wie mildert IMDSv2 metadatenbasiertes SSRF ab?
- Warum ist das Blockieren von 'localhost' eine unvollständige SSRF-Abwehr?
- Wie lässt sich SSRF für internes Port-Scanning nutzen?