Ein Angriff auf eine Authentifizierungs­schnittstelle, der aussieht wie echter Traffic

Ein Angriff auf die Authentifizierungs-API eines europäischen Finanzinstituts lief fünf Minuten, erzeugte über 900.000 Anfragen – und löste keine signaturbasierte Detection aus. Der Grund: Die Requests trugen gestohlene, valide Transaktionsdaten. Was das für die WAAP-Architektur von Banken und Zahlungsdienstleistern bedeutet, ist unbequem.

von Jag Bains, VP So­lu­ti­on En­gi­nee­ring, Link11

Wenn der Schutz das Problem nicht sieht

Kurz nach Mitternacht. Die Monitoring-Dashboards zeigen grünen Traffic. Wenige Anfragen pro Minute auf einem API-Endpunkt für Kredit­karten­authentifizierung. Das entspricht dem erwarteten Muster für diese .de-Domain zu einer solchen Uhrzeit. Dann, innerhalb von fünf Minuten: mehr als 900.000 Requests auf einen einzigen Endpunkt.

Was auf den ersten Blick nach einem klassischen volumetrischen Angriff aussieht, ist jedoch keiner. Es ist ein zweiphasiger, vorbereiteter Angriff, der auf die Zahlungsinfrastruktur abzielt. Dabei hat er eine Schutzlücke aufgezeigt, die je nach Konfiguration der WAF heute noch andere Organisationen haben können.

Phase eins: Echte Daten als Angriffswerkzeug

Vor dem Start des volumetrischen DDoS-Angriffs muss eine Sondierung stattgefunden haben. Die Angreifer hatten zuvor legitime Authentifizierungs­anfragen aus dem Kreditkarten­transaktions­flow abgefangen, konkret die strukturell validen HTTP-Anfragen, die Kartenterminals an den ACS-Endpunkt (Access Control Server) senden, um Transaktionen zu verifizieren. Diese Anfragen spielten sie massenhaft zurück, was als Replay-Angriff bezeichnet wird. Dabei werden nicht gefälschte, sondern echte Transaktionsdaten als Payload verwendet.

Das Resultat: Jede einzelne Anfrage sah aus wie eine legitime Terminalanfrage. Session-Struktur, Header-Profil, Payload-Inhalt – alles korrekt.“

Kein signaturbasierter Erkennungsmechanismus schlug an, da es keine Angriffssignatur gab. Was es stattdessen gab, waren valide Requests in ungewöhnlicher Frequenz.
Systeme, die primär auf Signaturmatching setzen, also den Abgleich eingehender Requests gegen bekannte Angriffsmuster, sind auf diesem Auge „blind“. Der Angriff trug keine Signatur, sondern eine Transaktions-ID.

Phase zwei: Verteilte Last, eine Session pro IP

In der Volumenphase änderte sich das Muster. Aus Indonesien, China, Russland, den USA und Brasilien wurden innerhalb von fünf Minuten knapp eine Million Requests gegen denselben Endpunkt generiert. Die Angreifer setzten auf eine breite Verteilung: Jede IP-Adresse eröffnete genau eine Session, also eine Verbindung zum Server, und nutzte diese, um eine einzelne Anfrage zu stellen. Dadurch fiel keine einzelne Quell-IP durch eine ungewöhnlich hohe Häufigkeit auf.

Wer Rate-Limiting auf Basis einzelner IP-Adressen oder bekannter URL-Muster konfiguriert hat, wird von diesem Angriff nicht getroffen. Wer nicht weiß, wie normaler Traffic für diesen spezifischen Endpunkt zu dieser Uhrzeit, aus diesen Regionen und mit dieser Request-Tiefe aussieht, hat keine Referenz für eine solche Anomalie. Die Streuung über verschiedene ASNs macht IP-Blocklisting wirkungslos. Die Verteilung über Länder ohne reguläre Kundenbasis macht Geo-Blocking theoretisch sinnvoll, aber nur, wenn vorab definiert wurde, welche geografischen Quellen für diesen Endpunkt legitim sind.

Was das für regulierte Institute konkret bedeutet

Transaktionskritische APIs sind strukturell anders exponiert als klassische Webanwendungen. Ein Ausfall der Kartenauthentifizierung hat zur Folge, dass Terminals keine Transaktionen mehr genehmigen können. Das ist ein direkter, messbarer Betriebsschaden und unter DORA ein meldepflichtiges Ereignis, da die Meldepflicht für schwerwiegende zahlungsbezogene Betriebs- und Sicherheitsvorfälle besteht, also für Vorfälle, die sich negativ auf die Bereitstellung von zahlungsbezogenen Diensten auswirken (Art. 3 Nr. 9 und 11 DORA).

Die Einstufung als „schwerwiegend” erfolgt gemäß Art. 18 Abs. 1 DORA anhand von Kriterien wie der Anzahl und dem Wert der betroffenen Transaktionen, der Dauer des Vorfalls sowie der Kritikalität der betroffenen Dienste.“

Drei Konfigurationsdefizite, die dieser Angriff aufdeckt

Fehlende endpunktspezifische Baseline. Generisches Rate-Limiting auf Systemebene erkennt Anomalien auf einem einzelnen Endpunkt nur, wenn das Gesamtvolumen globale Schwellenwerte überschreitet. Wenn ein ACS-Endpunkt im Normalbetrieb einstellige Anfragen pro Minute verarbeitet, im Angriff jedoch auf mehrere Hunderttausend Requests pro Minute steigt, greift ein globales Rate-Limit möglicherweise zu spät oder gar nicht. Notwendig wäre eine eigene Endpunkt-Baseline. Was ist normaler Traffic für diesen Pfad, zu dieser Tageszeit und aus diesen Regionen?
Ausschließliche Abhängigkeit von Signaturerkennung. Signaturbasierte WAF-Regeln sind effektiv gegen bekannte Angriffsmuster. Replay-Angriffe mit validen Transaktions-Payloads tragen jedoch keine Signatur. Behavioral Detection, also die kontinuierliche Analyse von Verhaltensparametern wie Request-Rate, Session-Tiefe, geografischer Verteilung und Payload-Entropie gegen eine Baseline, ist ein Mechanismus, der diesen Angriffstyp zuverlässig erkennt. Wer diesen Mechanismus nicht implementiert hat, ist gegen diese Angriffskategorie strukturell blind.
Keine endpunktspezifischen Identifier-Rate-Limits. Für Authentifizierungs-APIs empfiehlt sich eine Rate-Limiting-Regelung auf Basis eindeutiger Identifier pro Quell-IP. Dabei sollte nicht nur die Anzahl der Requests pro IP, sondern auch die Anzahl der verschiedenen Transaktions-IDs oder Kartentoken pro IP innerhalb eines bestimmten Zeitfensters begrenzt werden. Dieser Mechanismus erkennt automatisierte Replay-Angriffe auch dann, wenn jede IP nur eine Sitzung eröffnet, da die Anzahl der versuchten Identifier pro IP die statistische Normalverteilung echter Terminalanfragen übersteigt.

Konfiguration ist kein Einmalprojekt

Das bedeutet: Die Konfiguration einer Web Application and API Protection (WAAP)-Lösung ist kein Einmalprojekt. Endpunktspezifische Baselines müssen definiert, regelmäßig überprüft und auf Basis beobachteter Angriffsmuster aktualisiert werden. Behavioral Detection ergänzt die Signaturerkennung, da ohne sie eine strukturelle Blindstelle bestehen bleibt. Vordefinierte Incident-Response-Playbooks verringern die Zeitspanne zwischen Erkennung und Behebung von Vorfällen. Zudem sind sie unter den DORA-Anforderungen an das ICT-Risikomanagement ohnehin zu dokumentieren. Jag Bains, Link11/aj