Die Berichterstattung über NotPetya hat einen Vorfall in den Hintergrund gedrängt, der ein bedeutenderer Angriff hätte werden können: ein Brute Force-Angriff auf das britische Parlament. Für viele Beobachter war er zwar nur ein fruchtbarer Nährboden für Brexit-Witze auf Twitter, allerdings erinnert uns ein derartiger Angriff auf ein bedeutendes Regierungsorgan daran, dass Brute Force weiterhin eine verbreitete Bedrohung darstellt, auf die wir reagieren müssen.
Er führt uns auch zu wichtigen Fragen darüber, wie ein derartiger Angriff überhaupt erst möglich war:
Diese Probleme legen nahe, dass wir uns genauer mit diesem wichtigen, aber häufig falsch verstandenen Angriffstyp auseinandersetzen müssen.
Letzten Endes gibt es zwei Methoden, um in eine Organisation einzudringen: das Ausnutzen menschlicher Fehler oder raten. Das Ausnutzen menschlicher Fehler tritt in zahlreichen Varianten auf: Phishing (Fehler von Benutzern), Ausnutzen einer fehlerhaften Konfiguration (Fehler des Administrators) oder Ausnutzen einer Zero-Day-Lücke (Fehler des Entwicklers). Raterei anderseits nimmt ausschließlich die Form eines einzigen Angriffstyps an: Brute Force.
Am häufigsten wird Brute Force verwendet, um Anmeldeinformationen zu erraten, manchmal sollen jedoch auch andere Dinge wie URLs erraten werden.
Ein klassischer Brute-Force-Angriff ist der Versuch, Passwörter von der Ausgangsposition des Angreifers aus zu erraten, sobald der Angreifer in den Besitz verschlüsselter Passwörter gekommen ist. Damit kann der Angreifer leistungsfähige Computer benutzen, um eine große Anzahl von Passwörtern auszuprobieren, ohne das die Gefahr einer Entdeckung besteht. Andererseits kann ein derartiger Brute-Force-Angriff nicht der erste Schritt eines Angriffs sein, weil der Angreifer eine Kopie der verschlüsselten Passwörter des Opfers bereits haben muss.
Bei der Online (Echtzeit)-Variante des Angriffs wird die Anmeldefunktion eines Systems oder einer Anwendung bearbeitet, um Anmeldeinformationen zu erraten. Weil dabei keine verschlüsselten Passwörter als Ausgangslage benötigt werden, kann der Angreifer diese Technik auch bei Systemen anwenden, bei denen er noch keinen Fuß in der Tür hat.
Sowohl einen Benutzernamen als auch ein Passwort zu erraten, ist letzten Endes unglaublich schwer. Weil die meisten Systeme bei einer fehlgeschlagenen Anmeldung nicht angeben, ob der Benutzername oder das Passwort falsch waren, besteht die erste von Angreifern gewählte Abkürzung darin, bekannte Benutzer anzugreifen. Der Angreifer kann versuchen, Benutzernamen aus frei verfügbaren Informationen zu gewinnen: In zahlreichen Unternehmen haben die Benutzernamen beispielsweise eine vorhersehbare Struktur auf der Basis des Namens des Mitarbeiters – und eine einfache Suche bei LinkedIn ergibt so eine große Anzahl von Benutzernamen.
Dennoch ist diese Art des klassischen Brute-Force-Angriffs (zumindest bei gut eingerichteten Systemen) eher Mythos als Wirklichkeit. Das hat einen einfachen Grund: Bei den meisten modernen Systemen und Anwendungen ist eine Gegenmaßnahme eingebaut: die Sperrfunktion. Wenn ein Benutzer beim Anmelden mehrere Male Fahler macht, wird das Konto gesperrt und kann erst nach Intervention eines Administrators wieder entsperrt werden. Heutzutage sind es eher die Sperren, die in den IT-Abteilungen für Kopfschmerzen sorgen, als Brute Force. Dadurch wird die Überwachung von Sperren wichtiger als die Erkennung von Brute-Force-Angriffen.
Eine Ausnahme hiervon bilden individuell programmierte Anwendungen. Dabei ist es möglich, dass zwar die herkömmliche Windows-Anmeldung keine Lücke aufweist, dies bei einer neuen, extra für eine bevorstehende Ferien-Marketingkampagne programmierten Webanwendung durchaus der Fall ist.
Während die Anzahl von Online-Brute-Force-Angriffen rückläufig zu sein scheint, rückt das Credential Stuffing in das Rampenlicht. Als Credential Stuffing wird ein Angriff bezeichnet, bei dem Angreifer von öffentlichen Internetseiten gestohlene Anmeldeinformationen – Benutzername-Passwort-Paare – verwendet, um in ein Zielsystem einzubrechen. Die Anzahl der erfolgreichen Angriffe auf öffentliche Websites steigt, und die Angreifer veröffentlichen die Anmeldedatenbanken oder verkaufen sie über Handelsplätze im Untergrund. Dabei wird, häufig leider zu Recht, angenommen, dass Menschen denselben Benutzernamen und dasselbe Passwort auf mehreren Sites verwenden.
Beim Credential Stuffing werden Sperrfunktionen umgangen, weil jeder Benutzername nur einmal verwendet wird. Weil bekannte Benutzername-Passwort-Kombinationen verwendet werden, steigt beim Credential Stuffing auch die Erfolgswahrscheinlichkeit bei einer geringeren Anzahl von Versuchen.
Weil dagegen nicht mit Sperrfunktionen vorgegangen werden kann, setzen Organisationen Zwei-Faktor-Authentifizierung ein, um Credential Stuffing (und die Verwendung gestohlener Anmeldeinformationen im Allgemeinen) unmöglich zu machen. Bei der Zwei-Faktor-Authentifizierung benötigt der Benutzer neben Benutzername und Passwort ein zusätzliches Element, um sich zu authentifizieren, z. B. ein ihm zugeordnetes Mobiltelefon, auf dem er eine Textnachricht empfangen kann. Weil die Zwei-Faktor-Authentifizierung aufwändig ist, wird nach erfolgreicher Authentifizierung häufig ein „ähnlicher“ Zugriff genehmigt. Unter „ähnlich“ kann die Verwendung desselben Geräts oder derselbe geografische Standort verstanden werden. Wahrscheinlich hat jeder von uns schon einmal die Zwei-Faktor-Athentifizierung beim Zugriff auf öffentliche Websites von einem neuen Gerät, einem öffentlichen Computer oder auf Reisen erlebt.
Die Zwei-Faktor-Authentifizierung ist zwar eine robuste Lösung, hat aber bedeutende Nachteile: Sie greift in die Benutzerführung ein und macht eine interaktive Anmeldung erforderlich. Nichts ist frustrierender, als zu einer Zwei-Faktor-Authentifizierung über Ihr Telefon aufgefordert zu werden, wenn Sie gerade nach einem langen Flug an einem Flughafen im Ausland gelandet sind. Demzufolge wird sie häufig als Option für den Benutzer vorgesehen. Und deshalb ist in der Realität ein – häufig auf Analysefunktionen gestütztes – Erkennungssystem erforderlich, um Brute-Force-Angriffe zu erkennen.
Die übliche Methode für die Erkennug von Brute Force ist, die klassische aber unpraktische Variante des Angriffs zu adressieren: die Erkennung von einer Vielzahl fehlgeschlagener Anmeldeversuche eines einzigen Benutzers innerhalb eines kurzen Zeitraums. Viele Einsteigerübungen für das Erstellen von SIEM (Security Information and Event Management)-Korrelationsregeln konzentrieren sich auf die Erkennung von Brute-Force-Angriffen durch Identifizierung genau eines solchen Szenarios. Das ist als Übung zwar elegant und einfach, behandelt aber einen nahezu nicht existenten Angriffsvektor – und es ist viel mehr nötig, um einen Brute-Force-Angriff in der Realität zu erkennen.
Ein Faktor, der bei allen Authentifizierungs-Brute-Force-Angriffen zu beobachten ist, ist eine große Azahl fehlgeschlagener Anmeldeversuche. Allerdings kann die systematische Erkennung nicht auf dem Benutzer als Schlüsselmerkmal beruhen, sondern muss einen anderen Schlüssel verwenden, um die einzelnen Ereignisstränge, die zum Angriff gehören, miteinander in Verbindung zu bringen.
Eine Methode ist die Verfolgung von fehlgeschlagenen Authentifizierungsversuchen von einem identischen Ursprung, wozu häufig die IP-Adresse der Anfragen herangezogen wird. Da jedoch öffentliche IP-Adressen immer knapper und teurer werden, teilen sich immer mehr Benutzer eine einzige Ursprungs-IP-Adresse.
Um diesen Umstand zu berücksichtigen, kann ein Erkennungsmechanismus die normale Häufigkeit von Verbindungen und Fehlschlägen von einer Ursprungs-IP-Adresse lernen und ermitteln, welche Häufigkeit auffällig ist. Dadurch wird berücksichtigt, dass sich möglicherweise mehrere Benutzer über eine gemeinsame IP-Adresse anmelden. Der Erkennungsmechanismus kannn auch mit einem Geräte-Fingerabdruck – also eine Kombination von für ein Gerät typischen Eigenschaften beim Anmeldeereignis – arbeiten, um eine bestimmte Quelle unter allen, die dieselbe IP-Adresse verwenden, zu identifizieren. Dies kann jedoch kein primärer Faktor sein und hilft nur, Erkennungen zu verifizieren, weil die meisten Fingerabdruck-Eigenschaften der Kontrolle des Angreifers unterliegen und gefälscht werden können.
Verteilte Angriffe, die beispielsweise ein Botnet nutzen oder die Versuche durch ein Netzwerk von Datenschutz-Proxies wie TOR leiten, machen die Herausforderung noch komplizierter, weil dadurch die Ursprungsüberwachung irrelevant wird. Geräte-Fingerabdrücke können insbesondere dann zu einem gewissen Grad hilfreich sein, wenn der Angriff von einem einzigen Ursprung, aber über mehrere Verbindungen durchgeführt wird. Ein weiterer Ansatz ist die Verwendung von Bedrohungsinformationen, mit denen die Identifizierung von Zugriffen über bekannte Botnet-Knoten oder Datenschutz-Proxies erleichtert wird.
Bisher haben wir angenommen, dass die für die Analyse verwendeten Ereignisse klar abgegrenzt und aufgeräumt sind: Ein fehlgeschlagener Anmeldeversuch ist eindeutig als „Anmeldung“ gekennzeichnet, das Ergebnis ist ein eindeutiger Erfolg oder Fehlschlag, und der Benutzername wird immer im selben Feld und Format übergeben.
In der Realität muss die Verarbeitung eines Ereignisstroms zur Vorbereitung für die Analyse der Brute-Force-Erkennung als eigene Herausforderung betrachtet werden.
Nehmen wir aufgrund seiner enormen Verbreitung Windows als Beispiel. Die Windows-Ereignisse Erfolgreiche Anmeldung (Ereignis-ID 4624) und Fehlgeschlagene Anmeldung (Ereignis-ID 4625) werden lokal auf jedem Computer protokolliert. Dadurch wird es viel schwieriger (aber nicht unmöglich) sie zu sammeln. Außerdem kann deshalb der Angreifer – der den Computer möglicherweise besitzt – verhindern, dass sie überhaupt übergeben werden. Der Domain-Controller registriert ein Authentifizierungsereignis, das als Stellvertreter für ein Anmeldungsereignis verwendet werden kann. Dieses erfolgt bei Windows 2008 und darüber als Kerberos (Ereignis-ID 4768) und NTLM (Ereignis-ID 4776)-Variante und als anderer Satz von Ereignis-IDs bei vorherigen Windows-Versionen.
Sobald wir wissen, welche Ereignisse zu verfolgen sind, müssen wir immer noch herausfinden, wie wir Erfolg und Fehlschlag richtig erkennen. Erfolgreiche und fehlgeschlagene lokale Anmeldungen sind separate Ereignisse, während bei den Authetifizierungsereignisse des Domämen-Controllers der Erfolg oder Fehlschlag innerhalb des Ereignisses ausgewiesen wird.
Die folgende Splunk-Suche (aus dem GoSplunk-Suchrepositorium), mit der ich fehlgeschlagene Windows-Anmeldungen im Vergleich zu erfolgreichen identifiziert habe, zeigt, wieviel Wissen vorhanden sein muss, um derartige Informationen aus den Ereignissen zu extrahieren – und sie unterstützt noch nicht einmal die Alternative mit der Authentifizierung des Domain-Controllers.
source="WinEventLog:security" (Logon_Type=2 OR Logon_Type=7 OR Logon_Type=10) (EventCode=528 OR EventCode=540 OR EventCode=4624 OR EventCode=4625 OR EventCode=529 OR EventCode=530 OR EventCode=531 OR EventCode=532 OR EventCode=533 OR EventCode=534 OR EventCode=535 OR EventCode=536 OR EventCode=537 OR EventCode=539) | eval status=case(EventCode=528, "Successful Logon", EventCode=540, "Successful Logon", EventCode=4624, "Successful Logon", EventCode=4625, "Failed Logon", EventCode=529, "Failed Logon", EventCode=530, "Failed Logon", EventCode=531, "Failed Logon", EventCode=532, "Failed Logon", EventCode=533, "Failed Logon", EventCode=534, "Failed Logon", EventCode=535, "Failed Logon", EventCode=536, "Failed Logon", EventCode=537, "Failed Logon", EventCode=539, "Failed Logon") | stats count by status | sort - count
Das Brute-Force-Beispiel verdeutlicht, dass die Erkennung von Angriffen keine triviale Aufgabe ist. Keine der oben beschriebenen Methoden ist narrensicher, und Angreifer verbessern kontinuierlich ihre Methoden, um der Erkennung zu entgehen.
Zum Erkennen werden sowohl Kenntnisse der Angriffstechniken als auch der Verhaltensweisen des überwachten System benötigt. Außerdem sind laufende Aktualisierungen und Erweiterungen erforderlich. Es ist also entscheidend, das jedes System zur Erkennung von Brute-Force-Angriffen sowohl sofort einsatzbereite Algorithmen als auch Aktualisierungen für diese Erkennungs-Algorithmen vorsehen muss. Es genügt nicht, einfach die Mittel zur Sammlung der Ereignisse bereitzustellen und die Regeln oder Algorithmen zu schreiben, was dem Benutzer die Aufgabe überlässt, die tatsächliche Erkennungslogik zu implementieren. Außerdem liegt nahe, dass es sich lohnen könnte, die Art und Weise zu verstehen, in der ein System Brute Force erkennt – und sich nicht nur auf das allgemeine Versprechen zu verlassen, dass Brute Force entdeckt wird. Es gehört einfach viel mehr dazu, als ein Beispiel aus dem Lehrbuch vermitteln kann.
Es ist außerdem ein hervorragendes Beispiel dafür, warum ein mehrschichtiges Erkennungssystem, das Angreifer auch hinter dem Infiltrationspunkt erfasst, so wichtig ist – und warum die Cyber-Kill-Chain ein guter Ansatzpunkt ist.