Was ist der Instance Metadata Service (IMDS) und wie mindert IMDSv2 SSRF?
Kurzantwort
IMDS ist ein link-lokaler Endpunkt (169.254.169.254), der einer Instanz ihre Metadaten liefert, einschließlich temporärer Anmeldedaten für ihre angehängte IAM-Rolle. SSRF kann den Server dazu bringen, diese URL abzurufen und diese Anmeldedaten zu leaken. IMDSv2 verlangt ein PUT, um ein kurzlebiges Session-Token zu erhalten, setzt ein standardmäßiges IP-TTL/Hop-Limit von 1 und lehnt Anfragen mit bestimmten Headern ab — sodass ein einfaches SSRF-GET es nicht mehr erreichen kann.
Dies ist eine beliebte Senior-Cloud-Frage, weil sie eine Web-Schwachstelle (SSRF) mit einem cloud-nativen Angriff (Diebstahl von Anmeldedaten) verbindet — und die Lösung elegant ist.
Was IMDS tut
Jede Instanz kann eine link-lokale Adresse, 169.254.169.254, abfragen, um ihre eigenen Metadaten zu lesen: Region, Instanz-ID, Netzwerk und — entscheidend — die temporären Anmeldedaten der ihr angehängten IAM-Rolle. Anwendungen nutzen dies, sodass sie nie statische Schlüssel brauchen. Das Problem: Der Endpunkt vertraut jeder Anfrage, die von der Instanz ausgeht.
Warum SSRF hier so gefährlich ist
Bei einem Server-Side-Request-Forgery-Angriff zwingt ein Angreifer die Anwendung, eine HTTP-Anfrage an eine vom Angreifer gewählte URL zu stellen. Richtet er sie auf http://169.254.169.254/latest/meta-data/iam/security-credentials/..., ruft der Server die Anmeldedaten der Rolle ab und gibt sie zurück. Der Angreifer hält nun gültige, auf die Rolle beschränkte Cloud-Anmeldedaten — der Capital-One-Breach ist das kanonische Beispiel.
Wie IMDSv2 es schließt
IMDSv1 beantwortete ein einfaches GET, was genau das ist, was SSRF erzeugt. IMDSv2 ist sitzungsorientiert:
- Der Client muss zuerst ein
PUTausführen, um ein kurzlebiges Session-Token zu erhalten, und dieses Token dann bei jedem Lesen in einem Header senden. Die meisten SSRF-Primitive können nur einfacheGETs ausführen und damit den Handshake nicht abschließen. - Das standardmäßige Antwort-Hop-Limit (IP-TTL) ist 1, sodass die Antwort keinen weiterleitenden Proxy durchqueren oder dem Netzwerk-Namespace eines Containers entkommen kann, um einen externen Angreifer zu erreichen.
- Anfragen mit einem
X-Forwarded-For-Header werden abgelehnt, was den Missbrauch offener Proxys blockiert.
Erzwinge ausschließlich IMDSv2 beim Start (und kontoweit per Richtlinie) und grenze die Instanz-Rolle dennoch eng ein, damit ein Leck einen minimalen Wirkungsradius hat.
Worauf Interviewer achten
Die Metadaten-IP kennen, dass sie Rollen-Anmeldedaten liefert, den SSRF-Bezug und konkret, warum das Design aus PUT-Token plus Hop-Limit es vereitelt.
Wahrscheinliche Anschlussfragen
- Warum bricht ein standardmäßiges Hop-Limit von 1 SSRF durch einen Container oder Proxy?
- Wie würdest du kontoweit ausschließlich IMDSv2 erzwingen?
- Welchen Wirkungsradius hat ein geleaktes Instanz-Rollen-Anmeldedatum, und wie begrenzt du ihn?