Es war kurz vor 21 Uhr. Ein Unternehmen geriet unter Beschuss: Zwei bis drei Millionen Anfragen pro Minute wurden auf eine einzige Domain gerichtet. Die Abwehr griff und blockierte über 99,9 Prozent des Traffics. Dennoch kamen rund 1.000 Anfragen pro Minute durch. Nicht, weil der Schutz versagte. Der Angreifer kannte eine Annahme, auf der die Schutzregeln basierten, und hatte sie gezielt ausgehebelt.
Gesamtvolumen des Angriffs über dessen gesamte Dauer mit zwei bis drei Millionen Anfragen pro Minute
Eine Lücke, die keine Schwachstelle war
Moderne WAF-Architekturen arbeiten häufig mit Rate-Limiting-Regeln auf URL-Ebene. Die zugrunde liegende Logik ist solide: Wenn eine IP-Adresse dieselbe URL übermäßig oft anfragt, wird sie geblockt. Das funktioniert bei der überwältigenden Mehrheit aller volumetrischen Angriffe, da Angreifer in der Regel genau das tun: Sie treffen wieder und wieder einen Endpunkt, eine Login-Seite oder eine API-Route.
Dieser Angreifer tat es jedoch nicht. Stattdessen generierte er für jede einzelne Anfrage eine neue, zufällig erzeugte URL nach dem Schema /en/ gefolgt von sechs zufälligen Kleinbuchstaben. /en/nwbiod. /en/onoqzi, /en/nlvacu usw. Jede Anfrage, eine neue URL. Jede URL, ein neuer Eintrag. Keine URL wurde oft genug angefragt, um den Rate-Limit-Schwellenwert zu überschreiten. Die Schutzregeln griffen nicht, da jede Anfrage wie eine legitime Erstanfrage auf eine bisher unbekannte Seite aussah.
Der hervorgehobene Bereich isoliert den Datenverkehr, der aufgrund des zufälligen URL-Musters die WAF-Architektur umgangen hat.
Das war keine Zero-Day-Lücke. Es handelte sich um eine präzise ausgenutzte Regelannahme.
Warum der CDN-Cache die Last nicht abfing
Ein naheliegender Gedanke: Hätte ein vorgelagertes CDN die Anfragen nicht abfangen können? Normalerweise schon, allerdings nur für statische Inhalte. Bilder, Skripte, CSS-Dateien: Diese werden vom CDN gecacht und müssen in der Regel den Ursprungsserver nicht erreichen.
Zufällig generierte URLs existieren jedoch per Definition nicht im Cache. Das CDN kennt „/en/nwbiod” nicht. Also leitet es die Anfrage an den Origin weiter und fragt dort nach. Jedes Mal. Dieser Mechanismus, der sogenannte CDN-Cache-Miss, verwandelte die zufälligen URLs von einem Ausweichmanöver in einen Verstärker: Der Angreifer zwang jeden einzelnen Request bis zum Ursprungsserver durch, weil kein Cache-Layer greifen konnte. Die Schutzwirkung des CDN war für diese Anfragen somit ausgeschaltet.
Automatisierung als Angriffswerkzeug: Was hinter der URL-Rotation steckt
Die Technik selbst, also die URL-Rotation bei jeder Anfrage, ist nicht neu. Theoretisch war sie schon vor Jahrzehnten denkbar. Was sich verändert hat, ist die Geschwindigkeit und Leichtigkeit, mit der sie heute umgesetzt werden kann. Ein einfaches Skript rotiert sechs zufällige Kleinbuchstaben in eine URL-Vorlage. Es ist keine manuelle Pflege nötig, es gibt keinen menschlichen Loop. Die Anfragen erzeugen sich selbst.
Genau hier liegt der eigentliche Trend. Es entstehen nicht neue Angriffstechniken, sondern bekannte Techniken werden durch Automatisierung skalierbar und zugänglich. Was früher Kenntnisse und Aufwand erforderte, lässt sich heute mit dem richtigen Skript und verfügbarer Cloud-Infrastruktur innerhalb weniger Minuten aufsetzen. In diesem Fall nutzte der Angreifer die Infrastruktur von Telekommunikationsanbieter und andere legitime Netzwerkressourcen als Durchlaufstation. Dabei wurden aus rund 300 unterschiedlichen IP-Adressen zwei Millionen Anfragen pro Minute erzeugt.
Erfahren Sie mehr über eine einfach zu implementierende und äußerst effektive WAAP-Lösung.
Alles aus einer Hand und auf Wunsch als vollständig verwalteter Service.
Was bedeutet dieser Angriff für WAF-Architekturen und Betreiber?
URL-Rate-Limiting ist zwar wirksam gegen die überwiegende Mehrheit aller volumetrischen Angriffe, setzt jedoch voraus, dass Angreifer denselben Endpunkt wiederholt treffen. Wer URL-Randomisierung einsetzt, bricht genau diese Annahme auf. Ergänzende Regeln auf Basis der URL-Pfadstruktur oder regulärer Ausdrücke schließen diese Lücke. Die relevante Frage ist nicht, ob die bestehenden Regeln scharf genug sind, sondern ob sie das richtige Angriffsbild vor Augen haben.
Gleichzeitig zeigt dieser Fall, dass vorgelagerte Schutzschichten keine Vollkaskoversicherung sind. Keine IT-Sicherheitslösung garantiert hundertprozentigen Bypass-Schutz für jeden erdenklichen Angriffstypus. Die Ursprungsinfrastruktur muss deshalb so aufgebaut sein, dass sie auch unter Last stabil bleibt: Die Software muss aktuell sein, der Stack muss gehärtet sein und es müssen ausreichend Ressourcen vorhanden sein. Wer ausschließlich auf den vorgelagerten Schutz vertraut, hat keinen Plan B für den Moment, in dem ein Angreifer bisher unbekannte Lücken findet.
Und schließlich: Automatisierte Systeme erkennen bekannte Muster. Neue Techniken erkennen Menschen, wenn die Eskalationsprozesse funktionieren und wenn genügend Zeit bleibt, um die Logs wirklich zu lesen. Denn manchmal liegt die Lücke nicht dort, wo man sie sucht. Nicht in der Plattform. Nicht im Prozess. Sondern in einer Annahme, die so selbstverständlich wirkte, dass niemand sie in Frage gestellt hat. Sechs zufällige Buchstaben haben gereicht, um sie sichtbar zu machen.
Kennen Sie die Annahmen, die Ihrer WAF-Konfiguration zugrunde liegen – und welche davon ein Angreifer ausnutzen könnte? Wir analysieren Ihre Schutzarchitektur und zeigen Ihnen konkret, wo Lücken zwischen Regelwerk und realer Angriffsmethodik entstehen können. Vereinbaren Sie jetzt Ihr unverbindliches Gespräch.
Das könnte Ihnen auch gefallen:
