SSRF verstehen – Teil 4: SSRF in der Cloud (AWS, Azure & GCP)

---

Rückblick: Warum SSRF in der Cloud so kritisch ist

In klassischen Rechenzentren kann SSRF „nur“ interne Dienste wie Datenbanken, Admin-Panels oder Monitoring-Systeme treffen.
In der Cloud kommt eine neue Dimension hinzu:

• Jeder Compute- oder Container-Service hat Zugriff auf einen Metadata-Service (meist über die IP 169.254.169.254).
• Diese Endpoints liefern Informationen über die Instanz: Hostname, Netzwerk, aber auch IAM-Rollen & Zugangstokens.
• Mit einem einzigen HTTP-Request kann ein Angreifer also an Cloud-Zugangsdaten gelangen – und damit in die gesamte Cloud-Umgebung einbrechen.

---

AWS – Instance Metadata Service (IMDS)

Endpoint

http://169.254.169.254/latest/meta-data/

Wichtige Pfade:

• /iam/security-credentials/ → liefert Namen der IAM-Rolle
• /iam/security-credentials/<RoleName> → gibt temporäre AWS-Keys zurück (Access Key, Secret Key, Session Token)

Beispiel (ohne Schutz)

curl http://169.254.169.254/latest/meta-data/iam/security-credentials/
# → MyEC2Role

curl http://169.254.169.254/latest/meta-data/iam/security-credentials/MyEC2Role
# → JSON mit AccessKeyId, SecretAccessKey, Token

Schutz

• IMDSv2 aktivieren: erfordert einen Session-Token (PUT-Request vorab), erschwert SSRF erheblich.
• IAM Least Privilege: Rollen sollten nur minimale Rechte haben, niemals AdministratorAccess.
• Egress-Firewall: Zugriff auf 169.254.169.254 blocken, falls die App keinen Metadata-Service braucht.

---

Azure – Instance Metadata Service (IMDS)

Endpoint

http://169.254.169.254/metadata/instance

Besonderheit

Azure verlangt zwingend den Header:

Metadata: true

Beispiel

curl -H "Metadata:true" \
  "http://169.254.169.254/metadata/instance?api-version=2021-02-01"

Liefert Infos wie:

• VM-Name
• Resource Group
• Subscription ID
• Access Tokens für Azure-APIs (über identity/oauth2/token)

Schutz

• NSG (Network Security Groups) so konfigurieren, dass Instanzen nur von autorisierten Diensten auf IMDS zugreifen können.
• Apps niemals direkt mit IMDS kommunizieren lassen, wenn es nicht zwingend notwendig ist.
• Managed Identities minimal einschränken.

---

GCP – Metadata Server

Endpoint

http://169.254.169.254/computeMetadata/v1/

Besonderheit

GCP verlangt den Header:

Metadata-Flavor: Google

Beispiel

curl -H "Metadata-Flavor: Google" \
  "http://169.254.169.254/computeMetadata/v1/instance/service-accounts/default/token"

Das liefert ein OAuth2-Access-Token, das für Google Cloud APIs genutzt werden kann.

Schutz

• Metadata Concealment (in GKE) aktivieren, sodass Pods nicht direkt auf Metadata zugreifen können.
• Firewall Rules / VPC Service Controls nutzen, um den Zugriff stark einzuschränken.
• Service Accounts nur mit minimalen Rechten ausstatten.

---

Real-World Case: Capital One Breach (2019)

• Ursache: Eine fehlerhafte Web Application Firewall (WAF) in AWS ließ SSRF zu.
• Angreifer konnte über SSRF den Metadata-Service abfragen.
• Dadurch erhielt er AWS-Schlüssel einer Rolle mit weitreichenden Berechtigungen.
• Ergebnis: Millionen Kundendaten wurden gestohlen.

👉 Lektion: SSRF + Cloud-Metadata = potenzieller Full Cloud Takeover.

---

Schutzmaßnahmen – die große Cloud-Checkliste

Generell

• URLs validieren: Allowlist von Domains, keine direkten IPs.
• Protokolle einschränken: Nur http(s)://, keine file://, gopher://, etc.
• Redirects kontrollieren: Jeder Hop muss erneut geprüft werden.
• Egress-Kontrolle: App-Server dürfen nur zu notwendigen Hosts raus.

AWS

• IMDSv2 erzwingen
• Rollen mit minimalen Berechtigungen
• Blocken von 169.254.169.254, falls unnötig

Azure

• Zugriff auf IMDS nur über autorisierte Services
• NSGs restriktiv konfigurieren
• Managed Identities nur mit minimalen Rechten

GCP

• „Metadata Concealment“ für GKE aktivieren
• Metadata-Flavor Header prüfen (App darf nicht blind setzen)
• VPC Service Controls für Isolation

---

Fazit

SSRF ist in der Cloud nicht nur ein Einfallstor ins interne Netzwerk, sondern auch ein direkter Weg zu Cloud-Schlüsseln und API-Tokens.
Schon eine kleine SSRF-Lücke kann in AWS, Azure oder GCP zu einem kompletten Cloud-Kompromiss führen.