Skip to content

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 PUT ausfü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 einfache GETs 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?

Quellen

Erhalte 100 Cybersecurity-Interviewfragen + Antworten

Gib deine E-Mail-Adresse ein und wir senden dir das kostenlose PDF-Paket und das Flashcard-Deck.

Kein Spam. Jederzeit abbestellbar.