So nutzen Sie Request Enrichment bei unserer Next-Gen WAF, um kompromittierte Nutzerdaten zu identifizieren

Datenlecks, die Nutzernamen und/oder Passwörter beinhalten, treten bedauerlicherweise immer häufiger auf. Angreifer wissen, dass Nutzer oft dasselbe Passwort für unterschiedliche Websites wählen. Gelangen vertrauliche Login-Informationen einer Website einmal in die Hände von Hackern, lassen sich diese leicht mit anderen Websites abgleichen, um Account-Übernahmen durchzuführen, die weit über die ursprünglich kompromittierte Website hinausgehen. Erst im Juni 2021 wurde die bisher längste bekannte Liste an Passwörtern geleakt, wovon Millionen von User Accounts betroffen waren. Mithilfe von Fastlys Request Enrichment können Sie nachverfolgen, ob Nutzeranmeldungen mit als kompromittiert bekannten Anmeldedaten durchgeführt werden.

Ein vor Kurzem in unserem Developer Hub veröffentlichtes Tutorial zum Thema Request Enrichment beschreibt, wie Sie die Daten einer Drittanbieter-API zu den Requests hinzufügen, die über Fastly abgewickelt werden. Dort wird zum Beispiel die API für Have I Been Pwned (HIBP) genannt. HIBP ist eine Open-Source-Website, über die geprüft werden kann, ob beispielsweise ein bestimmter Nutzername oder ein bestimmtes Passwort als kompromittiert gemeldet wurde. Wird der Anfrage der Header „fastly-password-status“ hinzugefügt, ermittelt der Origin-Server, wie HIBP den Inhalt der Anfrage beurteilt.

Unsere Edge Cloud überlässt die Entscheidung, was mit dieser Information passieren soll, Ihrem Origin-Server. Was aber, wenn Sie unsere Next-Gen WAF (ehemals Signal Sciences) auf Ihrem Origin ausführen? Können Sie die erweiterten Request-Daten dann als Signal in der WAF nutzen? Aber klar doch! Ich zeige Ihnen, welche Verknüpfungen dafür notwendig sind.

Ihre Fastly Konfiguration

Anfragen an Login Endpoints

Loggen Sie sich zunächst in der Managementkonsole Ihrer Next-Gen WAF ein, um zu überprüfen, ob die über Compute gerouteten Anfragen auf als kompromittiert bekannte Passwörter geprüft werden. Über die unten stehende Regel können Sie nachsehen, ob der Header „fastly-password-status“ in den Anfragen vorhanden ist. Dieser Header sollte sämtlichen Anfragen hinzugefügt werden, unabhängig davon, ob ein Passwort als kompromittiert gilt oder nicht. Ob das Passwort überprüft wurde, erkennen Sie, indem Sie ein Signal hinzufügen, wenn der Header „fastly-password-status“ vorhanden ist.

Anfragen mit als kompromittiert bekannten Passwörtern

Wie im oben genannten Tutorial erwähnt, können Sie anhand des Key-Value-Paares des Anfrage-Headers überprüfen, ob das Passwort als kompromittiert bekannt ist. Bauen Sie dazu eine zusätzliche Regel ein, über die ermittelt wird, ob der Header „fastly-password-status“ vorhanden ist und den Wert „compromised-credential“ besitzt. Wenn dieses Key-Value-Paar vorhanden ist, wissen Sie, dass der konfigurierte Wasm Service ein kompromittiertes Passwort gefunden hat.

Ein Fallbeispiel

Ist die obige Konfiguration einmal eingerichtet, lassen sich potenzielle Bedrohungen viel leichter aufspüren. So liefern zum Beispiel eine erhöhte Anzahl an Anmeldeversuchen, fehlgeschlagene Anmeldeversuche oder innerhalb kurzer Zeit wiederholt auftretende „compromised-credential“-Signale mögliche Hinweise auf einen Brute-Force-Angriff.

An dieser Stelle helfen Ihnen die Daten dabei, fundiertere Entscheidungen zu treffen. Um das Ganze für Sie noch besser zu veranschaulichen, habe ich die Karte „Compromised Passwords“ mit den Signalen „checked-pw“ und „compromised-pw“ erstellt. Parallel zur Login-Card kann ich also sehen, dass es in dem zu überprüfenden Zeitraum mehrere fehlgeschlagene Anmeldeversuche, aber keinen einzigen erfolgreichen Anmeldeversuch gab. Die meisten Anmeldeversuche in diesem Zeitraum erfolgten mit Passwörtern, die als kompromittiert bekannt sind.

Aus dieser Information kann ich die Schlussfolgerung ziehen, dass mein Login Endpoint höchstwahrscheinlich von einem Brute-Force-Anmeldeangriff betroffen ist.

Gezieltere Maßnahmen

Mit unserer Next-Gen WAF können Sie für die Abwehr von böswilligem Verhalten Schwellenwerte festlegen. Nachfolgend finden Sie eine Rate-Limiting-Regel, durch die von derselben IP-Adresse stammende Anfragen mit dem Signal „All Requests“ nach einer begrenzten Anzahl von Anmeldeversuchen mit kompromittierten Passwörtern blockiert werden.

Diese Art von Abwehr gibt Ihrem Sicherheits- oder Betrugspräventionsteam Zeit, das Verhalten zu untersuchen und zu bestimmen, ob der Angriff gegen einen einzelnen Nutzer, eine Gruppe von Nutzern oder als größerer Passwort-Spraying-Angriff gegen viele verschiedene Nutzer geht.

Eine mögliche Reaktion des Sicherheitsteams auf einen Angriff gegen eine Gruppe von Nutzern könnte zum Beispiel lauten, sicherzustellen, dass diese spezifischen Nutzer starke, nicht kompromittierte Passwörter und eine Zwei-Faktor-Authentifizierung verwenden, und bei erfolgreicher Anmeldung von diesen IP-Adressen genau diese Nutzersitzungen zu terminieren und eine Passwortzurücksetzung zu erzwingen.

Fazit

Durch die Verknüpfung unserer Next-Gen WAF mit den Daten von Have I Been Pwned können Sie besser verfolgen, wie oft Anmeldeversuche mit als kompromittiert bekannten Passwörtern auf Ihrer Website vorgenommen werden. Diese Informationen können Ihnen dann bei der Abwehr von Account-Übernahmen und dem Schutz Ihrer Nutzerkonten helfen. Dies ist nur ein Beispiel dafür, was Sie mit Request Enrichment auf Fastly erreichen können. Haben Sie weitere Beispiele für uns? Twittern Sie uns!