SSRF, TOCTOU und DNS-Rebinding

Warum KI Pentester nicht ersetzen kann

Man stelle sich eine Schutzfunktion vor, die genau das tut, was sie soll. Sie nimmt eine vom Nutzer eingegebene URL, löst den Hostnamen auf, schaut sich die IP-Adresse an und entscheidet: öffentliche Adresse, kein internes Netz, alles in Ordnung. Die Funktion ist getestet, sie greift, sie wehrt offensichtlich bösartige Eingaben ab. Und trotzdem schickt der Server am Ende einen Request an „127.0.0.1“, also an sich selbst.

Genau das ist einer bekannten Plattform für die Softwareentwicklung auf Git-Basis 2019 passiert, und es ist bis heute eines der schönsten Lehrbeispiele für eine ganze Fehlerklasse. Bevor man sich ansieht, wie der Angriff funktioniert, lohnt ein Schritt zurück zur eigentlichen Schwachstellenart.

Was ist SSRF?

Server-Side Request Forgery, kurz SSRF, heißt im Kern: Ein Angreifer bringt einen Server dazu, einen Request an ein Ziel zu schicken, das der Angreifer bestimmt. Interessant ist dabei nicht der Weg nach draußen ins Internet. Interessant wird es, wenn sich der Server überreden lässt, nach innen zu telefonieren. Auf Dienste, die nur intern erreichbar sind. Zum Beispiel auf sich selbst („localhost“) oder ins interne Netzwerk.

Der Grund, warum SSRF so verbreitet ist: Viele Features verlangen geradezu danach, dass der Server eine fremde URL aufruft. URL-Vorschau, Bild-Importe per Link, PDF-Generatoren, und eben Webhooks. Ein Webhook hat als einzigen Zweck, dass der Server bei bestimmten Ereignissen eine vom Nutzer hinterlegte Adresse aufruft. Damit ist er ein klassisches Einfallstor, denn die Zieladresse kommt per Definition vom Nutzer.

Die naheliegende Verteidigung ist eine Prüfung: Bevor der Server die URL aufruft, schaut man nach, wohin sie zeigt. Löst sie auf eine interne oder reservierte Adresse auf, wird sie abgelehnt.

Klingt solide. Und genau hier wird es spannend.

Eine gute Prüfung zum falschen Zeitpunkt

Die besagte Code-Hosting-Plattform hatte ebenfalls ein Feature für Webhooks, war sich der Gefahr bewusst und hatte genauso eine Prüfung implementiert. Die Komponente hieß „UrlBlocker“: Sie löste den Hostnamen der Webhook-URL auf, prüfte die resultierende IP und blockte interne sowie reservierte Bereiche. Wer „http://127.0.0.1“ oder eine Adresse aus dem privaten Bereich eintrug, flog raus. Auf dem Papier alles richtig gemacht.

Das Problem war nicht die Prüfung selbst. Das Problem war der Zeitpunkt der Prüfung.

TOCTOU: die Lücke zwischen Prüfen und Benutzen

TOCTOU steht für Time-of-Check-to-Time-of-Use. Die Idee ist alt, unscheinbar und genau deshalb so wirkungsvoll: Man prüft einen Wert zu einem Zeitpunkt und benutzt ihn zu einem anderen. Kann sich der Wert dazwischen ändern, ist die Prüfung wertlos.

Im genannten Fall steckte die Lücke in der DNS-Auflösung. Der HackerOne-Report #541169 hat es klar benannt: Der „UrlBlocker“ löste den Hostnamen mehrfach auf, einmal für die Prüfung und später noch einmal für den eigentlichen Request. Die bereits geprüfte IP wurde verworfen, statt sie für die Verbindung wiederzuverwenden. Klassisches TOCTOU. Und der Angreifer kontrolliert genau die Variable, die sich dazwischen ändert: seinen eigenen DNS-Eintrag.

Diese Technik heißt DNS-Rebinding, und sie ist erschreckend simpel.

Der Angriff, Schritt für Schritt

Die folgende Grafik zeigt den Ablauf.

Der Angreifer hinterlegt als Webhook eine URL auf einer Domain, die er selbst kontrolliert. Auf seinem autoritativen DNS-Server setzt er einen entscheidenden Wert: die TTL („Time-To-Live“) auf eine Sekunde. Die TTL gibt an, wie lange ein DNS-Eintrag gültig ist, bevor neu aufgelöst werden muss. Eine Sekunde bedeutet praktisch: sofort wieder ungültig.

Dann läuft das Spiel ab. Zur Prüfung fragt die DevOps-Plattform den Resolver nach der IP der Domain, und der DNS-Server des Angreifers antwortet mit einer harmlosen öffentlichen IP-Adresse. Der „UrlBlocker“ schaut sie sich an, stuft sie als öffentlich und unverdächtig ein und akzeptiert die Eingabe. Die eine Sekunde ist da jedoch längst vorbei, der Eintrag verfallen. Für den echten Request fragt die Plattformerneut nach derselben Domain, und diesmal antwortet der DNS-Server allerdings mit „127.0.0.1“ (äquivalent zu „localhost“). Die Plattform verbindet sich folglich mit sich selbst. Ein fataler Fehler.

Der Angreifer hat nichts überrannt, keinen Speicher überlaufen lassen, kein Passwort geknackt. Er hat schlicht zweimal eine andere Antwort auf dieselbe Frage gegeben. Weil das System die Frage zweimal gestellt hat, gewinnt der Angreifer.

An dieser Stelle möchte ich noch einmal auf den Begriff „Race Condition“ eingehen. Bei einer echten Race muss man das Timing treffen und auf Glück hoffen, daher unterscheidet sich eine „Race Condition“ von dem genannten „TOCTOU“-Beispiel. Hier braucht es kein Glück. Der Angreifer sitzt am Ende der DNS-Antwort und liefert beim ersten Mal eine öffentliche IP-Adresse und beim zweiten Mal die bösartige IP-Adresse.

Der Fix ist so deutlich unspektakulärer als der Angriff

Die Lösung ist keine weitere Blocklist und kein zusätzlicher Regex auf die URL. Sie besteht darin, die Lücke zwischen Check und Use schlicht zu schließen: einmal auflösen, diese eine IP-Adresse prüfen, und sich danach mit genau dieser geprüften IP verbinden, nicht erneut über den Hostnamen. In der Praxis nennt sich das DNS-Pinning. Die validierte IP wird für die Verbindung festgehalten.

Daraus lässt sich eine Faustregel ziehen, die weit über SSRF hinausreicht: so spät und so nah am eigentlichen Vorgang prüfen wie möglich, und danach exakt den Wert benutzen, den man geprüft hat.

Warum das kein Museumsstück ist

Man könnte einwenden: schön, 2019, alter Hut, längst behoben. Wäre das so, gäbe es vermutlich diesen Artikel nicht.

Dieselbe Fehlerklasse taucht in den Schwachstellendatenbanken bis heute regelmäßig in aktuellen Projekten auf, quer durch Webhook-Handler, Daten-Connectoren und URL-Vorschau-Features. Das Muster ist immer dasselbe: Der Hostname wird zur Prüfung aufgelöst, der eigentliche HTTP-Client löst beim Verbindungsaufbau unabhängig noch einmal auf, und niemand pinnt die geprüfte IP.

Der Eindruck aus der Praxis: SSRF-Schutz scheitert selten an fehlender Absicht. Er scheitert an dieser einen Lücke zwischen „geprüft“ und „verbunden“, die im Code unauffällig bleibt, weil sie sich über zwei Funktionen, zwei Bibliotheken oder zwei Zeitpunkte verteilt. Im Review fällt das fast nie auf. In einem Pentest jedoch schon, sofern man weiß, wonach man sucht.

Daher sollten solche Themen von zwei Seiten angegangen werden. Im Pentest haben wir ein besonderes Augenmerk auf Themen wie SSRF oder verwandten Themen wie CSRF („Cross-Site-Request-Forgery“). Wenn man Quellcode mit KI und SAST-Tools („Static Application Security Testing“) analysiert oder dynamische Tests mittels KI oder DAST-/IAST-Tools („Dynamic-/Interactive-Aplication-Security-Testing“) durchführt, fallen solche Schwachstellen nicht auf. Dafür braucht es ein tiefgehendes Verständnis wie Vorgänge zusammenhängen, welche Abhängigkeiten bestehen und nicht zuletzt sehr viel Kreativität. Natürlich kann man LLMs auf solche Fälle trainieren, um so etwas zu erkennen, aber morgen gibt es dann schon wieder den nächsten Fall der minimal anders ist und lediglich gefunden werden konnte, weil ein Hacker des Nachts von einer Muse geküsst wurde.

Zusätzlich lehren wir in Schulungen zur sicheren Softwareentwicklung über den Tellerrand hinaus zu denken und das Mindset eines Angreifers einzunehmen. Das erreichen wir durch einen mehrfachen Wechsel zwischen theoretischen Grundlagen und echten Hacking-Sessions, um selbst kreativ zu werden und ein entsprechendes Ziel zu hacken.

Dieses Denken und diese Erfahrung hilft, dass so einen Bug schon im Entwurf verhindert wird: Wo wird geprüft, wo wird benutzt, und kann sich zwischen diesen beiden Punkten etwas ändern, das nicht unter eigener Kontrolle steht?

Wer diese Frage reflexartig stellt, baut TOCTOU gar nicht erst ein. Allgemein stellen sich die Teilnehmer einer unserer Schulungen beim Programmieren immer wieder die Frage: Ich habe nun die Funktion fertig, an welcher Stelle würde ich nun als Angreifer ansetzen, um meine Funktion auszutricksen?

Der genannte Fall ist gerade deshalb so lehrreich, weil hier niemand geschludert hat. Die Schutzfunktion war vorhanden, sie war durchdacht, und sie hat trotzdem versagt, an einer Stelle, die auf den ersten Blick wie ein Detail aussieht. Sicherheit entscheidet sich oft genau in diesen Details. Eine korrekte Prüfung zum falschen Zeitpunkt ist eben keine Prüfung. Sie ist nur ein gutes Gefühl.