blueredix logo
SCAN Schwachstellenscans auf Abruf ab 149 €
info vuln-class-ssrf

Server-Side Request Forgery (SSRF), verständlich erklärt

SSRF erlaubt Angreifern, von Ihrem Server aus Web-Requests überall hin abzusetzen, wo der Server Zugriff hat, inklusive interner Admin-Panels und des Cloud-Metadata-Service. Der Capital-One-Breach in einem Artikel.

Worum es geht

Server-Side Request Forgery (SSRF) entsteht, wenn Ihre Anwendung eine URL als Eingabe nimmt und sie serverseitig abruft, und der Angreifer die URL kontrolliert. Der ausgehende Request stammt von der IP-Adresse Ihres Servers und passiert damit jede Firewall-Regel, die “interner Verkehr ist erlaubt” sagt. Damit erreicht der Angreifer alles, was Ihr Server erreicht, typischerweise deutlich mehr, als er aus dem öffentlichen Netz erreichen würde.

Häufige Features, die SSRF einschleppen:

  • Link-Vorschau. Die Person fügt eine URL ein, der Server holt Titel und Bild.
  • Webhooks und Integrationen. Die Person konfiguriert eine Callback-URL, der Server postet darauf.
  • PDF-/Bild-Rendering-Dienste. Die Person übergibt eine URL, der Server rendert sie.
  • Profilbild-Import per URL. “diese URL als Avatar nutzen”, der Server lädt sie.
  • Pingbacks, oEmbed, RSS-Aggregatoren. Funktionen, deren ganzer Zweck darin besteht, vom Nutzer angegebene URLs zu holen.

Warum das wichtig ist

Ein Webserver liegt typischerweise in einem Netzsegment voller ruhiger, authentifizierter “hinter der Firewall”-Dienste: ein internes Admin-Panel, eine Datenbank ohne externe Authentifizierung, ein Kibana-Dashboard, eine interne Artefakt-Registry. Keiner davon ist direkt aus dem Netz erreichbar. Vom Webserver aus aber schon.

In der Cloud wird es schärfer. AWS, Azure, GCP, DigitalOcean und Alibaba Cloud stellen alle einen Metadata-Service an einer festen internen Adresse bereit, der ohne Authentifizierung antwortet und die temporären Credentials der laufenden Instanz herausgibt. Ein SSRF, der diese Adresse erreicht, kann die Credentials der IAM-Rolle Ihres Servers abgreifen. Genau so verlor Capital One 2019 die Daten von 106 Millionen Kund:innen: eine fehlkonfigurierte Firewall erlaubte SSRF, der Angreifer rief den Metadata-Service ab, übernahm die Rollen-Credentials und las damit jeden S3-Bucket, auf den die Rolle Zugriff hatte.

Drei konkrete Ausnutzungspfade

  1. Interne HTTP-Dienste. http://10.0.0.5:8080/admin oder http://localhost:9200/_cluster/health: der Angreifer erkundet das interne Netz von innerhalb Ihrer Anwendung.
  2. Cloud-Metadata. http://169.254.169.254/latest/meta-data/iam/security-credentials/ auf AWS, die Pendants in anderen Clouds.
  3. Nicht-HTTP über ungewöhnliche Schemata. Akzeptiert der URL-Fetcher andere Schemata als http(s) (gopher://, file://, dict://), kann SSRF lokale Dateien lesen (/etc/passwd), mit internen Diensten wie Redis sprechen oder per SMTP Mail versenden.

Wie das behoben wird

Eine einzelne Codezeile reicht nicht. Die Lösung kombiniert Eingabe-Validierung, Netzwerk-Segmentierung und Credential-Hygiene. Ihre Entwickler oder das Hosting-Team sollten alle drei abdecken:

Eingabe-Validierung:

  • Nur die wirklich benötigten Schemata akzeptieren, meist http und https, nie file, gopher, dict, ftp.
  • Nach Auflösung des Hostnamens auf eine IP private und Link-Local-Bereiche blocken, bevor abgerufen wird: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 127.0.0.0/8, 169.254.0.0/16, ::1/128, fc00::/7, fe80::/10. Selbst auflösen und die literale IP an den HTTP-Client übergeben, sonst kann der Angreifer einen DNS-Rebinding-Trick einsetzen.
  • Redirects begrenzen (und das Ziel bei jedem Hop neu validieren). Ein angreifer-kontrollierter Redirect auf 169.254.169.254 ist der häufigste Bypass.

Netzwerk-Segmentierung:

  • Der Application-Server sollte interne Dienste nicht erreichen können, mit denen er nicht wirklich sprechen muss. Egress- Firewalls funktionieren.
  • Auf AWS IMDSv2 erzwingen (der Metadata-Service mit Session-Token). SSRF-Bugs, die nur einfache GETs können, erreichen Metadata damit nicht mehr. Azure und GCP bieten entsprechende Schutzmechanismen.

Credential-Hygiene:

  • IAM-Rollen, die Ihrer Anwendungsinstanz zugewiesen sind, sollten die kleinstmögliche Berechtigung haben. Wenn aus einem SSRF “lese jeden Kundendatensatz” wird, hatte die Rolle dieses Recht von vornherein nicht zu haben.

Wie blueredix SSRF meldet

Der Scanner meldet CVEs in Drittanbieter-Software, deren Beschreibung SSRF nennt, plus exponierte Cloud-Metadata-Endpunkte und bekannte verwundbare URL-Fetcher-Produkte über kuratierte nuclei-Templates. Den aktiven Versuch, Ihre Anwendung dazu zu bringen, beliebige URLs abzurufen, übernehmen wir nicht. Das ist Penetration-Testing-Territorium.

Mehr dazu