SSRF-Angriffe erklärt: Wie DNS ausgenutzt wird

Server-Side Request Forgery (SSRF) liegt vor, wenn ein Angreifer einen Server dazu bringt, in seinem Auftrag eine HTTP-Anfrage (oder eine andere Netzwerkanfrage) an ein Ziel zu senden, das der Angreifer gewählt hat und nicht der Entwickler der Anwendung. Ein klassischer Vektor: eine Funktion, die eine vom Nutzer angegebene URL abruft – ein Bildimport, ein Webhook-Ziel, eine Linkvorschau –, wobei der Angreifer eine URL einreicht, die auf interne Infrastruktur statt auf eine öffentliche Ressource zeigt.

Wo DNS in den Angriff passt

Die naive Abwehr prüft, ob der Hostname der übermittelten URL wie eine interne Adresse aussieht. Das lässt sich mühelos umgehen: Ein Angreifer registriert eine öffentliche Domain, lässt deren DNS-Record auf eine interne IP zeigen und übergibt Ihrem Server einen völlig normal aussehenden Hostnamen. Ihre Validierung sieht eine Domain, keine IP – der gefährliche Teil zeigt sich erst nach der DNS-Auflösung, und die geschieht oft tief in der HTTP-Client-Bibliothek, die die eigentliche Anfrage stellt, weit nach jedem vorgelagerten Validierungsschritt.

Wie echter Schutz aussieht

• Lösen Sie den Hostnamen vor jeder Anfrage selbst und ausdrücklich auf – überlassen Sie das nicht unsichtbar einem HTTP-Client.
• Prüfen Sie jede aufgelöste Adresse (alle – eine Domain kann mehrere zurückgeben) gegen eine Sperrliste für private, Loopback-, Link-Local- und Cloud-Metadaten-Adressen.
• Lehnen Sie die Anfrage ab, wenn irgendeine aufgelöste Adresse unzulässig ist, statt nur die zuerst zurückgegebene zu prüfen.
• Validieren Sie zum Zeitpunkt der Anfrage erneut, nicht nur bei der Eingabe, um die separat beschriebene DNS-Rebinding-Lücke zu schließen – SSRF und Rebinding werden in der Praxis häufig kombiniert.

Cloud-Metadaten-Endpunkte verdienen hier besondere Erwähnung: Bei den meisten Cloud-Anbietern kann eine Anfrage aus einer VM heraus an eine bestimmte Link-Local-Adresse Zugangsdaten, Instanz-Metadaten oder Konfiguration zurückliefern, die nie von außerhalb der Maschine erreichbar sein sollten. SSRF in Kombination mit einem Metadaten-Endpunkt als Ziel ist eine der häufigsten und folgenreichsten Angriffsketten der Praxis, und sie beginnt jedes Mal mit einem unauffällig aussehenden Domainnamen.

Filter, die die Zeichenkette statt der Adresse prüfen, funktionieren nicht

Eine IP-Adresse hat mehr gültige Textdarstellungen, als die meiste Validierungslogik berücksichtigt. Ein Filter, der als String-Vergleich mit „127.0.0.1“ oder „localhost“ geschrieben ist, lässt jede der folgenden alternativen Formen unbehelligt durch, weil keine von ihnen wie die geprüfte Zeichenkette aussieht.

Die einzig verlässliche Abwehr wandelt die Adresse zuerst in ihren tatsächlichen numerischen Wert um und wertet die Sperrliste gegen diesen aus – genau der Ansatz, den der Resolver dieses Tools verfolgt, statt Muster in der zufällig gewählten Schreibweise der Adresse abzugleichen. Ein Resolver liefert eine normalisierte Adresse zurück, unabhängig davon, wie der Record des ursprünglichen Hostnamens sie kodiert hat – und genau deshalb ist es robuster, zuerst aufzulösen und das aufgelöste Ergebnis zu validieren, als zu versuchen, einen Rohstring in jeder Form zu validieren, die ein Angreifer schreiben könnte.

Weiterleitungen sind die andere verbreitete Umgehung

Selbst ein System, das die ursprüngliche URL korrekt auflöst und validiert, kann durch eine HTTP-Weiterleitung ausgetrickst werden. Eine Anfrage an eine zugelassene, öffentliche URL kann mit einem 302 antworten, der auf eine interne Adresse zeigt, und ein HTTP-Client, der Weiterleitungen automatisch folgt (das Standardverhalten der meisten Bibliotheken), stellt diese zweite Anfrage bereitwillig, ohne die Validierung, die beim ersten Mal bestanden wurde, erneut auszuführen. Jede SSRF-Abwehr, die einmal vorab validiert und die Weiterleitungen dann dem zugrunde liegenden HTTP-Client überlässt, hat eine Lücke von genau derselben Form wie die, die die DNS-Auflösung erzeugt – und die Lösung ist dieselbe: vor dem Folgen jeder Weiterleitung ausdrücklich erneut validieren, statt darauf zu vertrauen, dass eine URL, die einmal bestanden hat, weiter auf etwas Sicheres zeigt.