AWS IMDSv2.

IMDSv2 ist die zweite Version des EC2 Instance Metadata Service, die AWS im November 2019 als direkte Reaktion auf den Capital-One-Vorfall und weiteren SSRF-getriebenen Diebstahl von Cloud-Anmeldedaten eingeführt hat. Bei diesem am 19. Juli 2019 offengelegten Vorfall missbrauchte Paige Thompson ("erratic") eine Server-Side-Request-Forgery-Schwachstelle in einer fehlkonfigurierten Web Application Firewall, um den Link-Local-Endpunkt http://169.254.169.254/latest/meta-data/iam/security-credentials/ zu erreichen. Die überprivilegierte IAM-Rolle der WAF, ISRM-WAF-Role, lieferte temporäre STS-Anmeldedaten zurück, mit denen sie Daten aus mehr als 700 S3-Buckets auflisten und kopieren konnte — rund 106 Millionen Kundendatensätze. Der Vorfall kostete Capital One später eine OCC-Strafe von 80 Mio. US-Dollar sowie einen Vergleich von 190 Mio. US-Dollar aus einer Sammelklage.

Wie IMDSv2 SSRF vereitelt

Mit IMDSv1 lieferte jeder GET-Aufruf an die Metadaten-IP Anmeldedaten zurück, sodass eine reflektierte oder serverseitige Request-Forgery genügte. IMDSv2 macht den Ablauf sitzungsorientiert: Der Client muss zunächst mit einem X-aws-ec2-metadata-token-ttl-seconds-Header PUT /latest/api/token aufrufen und anschließend das zurückgegebene Token bei jedem Lesevorgang über X-aws-ec2-metadata-token mitsenden. Eine naive SSRF kann nicht ohne Weiteres einen PUT-Aufruf mit einem benutzerdefinierten Header absetzen, und das Setzen von HttpPutResponseHopLimit: 1 verhindert, dass Container, die einen Netzwerk-Hop entfernt sind, den Dienst erreichen.

flowchart TD
  A[App with SSRF flaw] -->|GET 169.254.169.254| B{Metadata mode?}
  B -->|IMDSv1 optional| C[Returns IAM credentials]
  C --> D[Attacker exfiltrates S3 data]
  B -->|IMDSv2 required| E[Rejected: no session token]
  E --> F[PUT /latest/api/token + TTL header needed]
  F -->|SSRF cannot issue PUT| G[Credential theft blocked]

Schutzmaßnahmen

Erzwingen Sie HttpTokens: required organisationsweit über eine SCP oder die kontoweite Einstellung instance-metadata-defaults, fixieren Sie das Hop-Limit auf 1 und nutzen Sie CSPM-/Wiz-Findings, um veraltete AMIs aufzuspüren, die weiterhin IMDSv1 erlauben. Beschränken Sie die IAM-Richtlinien der Instanzrollen nach dem Least-Privilege-Prinzip, damit ein geleaktes Token nur wenig einbringt.