Guter Brute-Force-Schutz ist nicht trivial

12. Mai 2017

Ein schlecht implementierter Brute-Force-Schutz kann schnell zur Falle werden. Vor allem dann, wenn einem Angreifer bekannt ist, wie Benutzernamen aufgebaut sind. In diesem Artikel beschreibe ich bessere Methoden zum Schutz von Login-Mechanismen.

Gerade in Zeiten von Erpressungen mittels Trojanern und DDoS-Attacken sollte man es einem Angreifer nicht allzu leicht machen, den eigenen Dienst für legitime Benutzer unzugänglich zu machen. Leider passieren oft Fehler im Design von Login-Schutzmechanismen. Zugegeben: Die Lehrmeinung ist sich uneinig wie der perfekte Brute-Force Schutz aussieht. In diesem Artikel möchte ich kurz beschreiben, welche Probleme ein schlecht geplanter Schutz vor Brute-Force Angriffen mit sich bringt, welche grundsätzlichen Überlegungen man treffen sollte und wie ein besserer Brute-Force Schutz aussehen könnte.

Brute-Forcing – der Holzhammer

Zunächst, was ist Brute-Force(ing) überhaupt? Als Brute-Force (engl. “rohe Gewalt”) bezeichnet man eine Angriffsmethode, bei der sämtliche mögliche Schlüssel oder Passwörter durchprobiert werden, bis der passende Schlüssel/das korrekte Passwort gefunden wurden. Die Methode ist sehr zeitaufwendig, führt aber ohne passende Schutzmaßnahmen immer zum Erfolg. Der kritische Faktor ist hier lediglich die Zeit. Dieser Angriff kann sowohl auf verschlüsselte Daten als auch auf Login-Funktionen von Websiten bzw. Applikationen durchgeführt werden. In diesem Beitrag gehe ich ausschließlich auf den Schutz von Login-Funktionen ein, speziell auf die von Web-Applikationen. (Anm.: Das Prinzip ist aber beliebig auf andere Applikationen übertragbar).

Der Angriffspunkt

Der Angriffspunkt bei Brute-Force Angriffen ist die Login-Funktion bzw. der Login-Vorgang. Bricht man den Login-Vorgang auf seine elementaren Schritte herunter, sieht dieser so aus:

Der Client wird aufgefordert sich zu identifizieren (eigentlich authentifizieren), z.B. mittels einer Login-Form.
Der Benutzer gibt seine Login-Daten (z.B. Benutzername und Passwort) ein.
Der Client sendet die Daten zum Server.
Der Server überprüft die Login Daten und gibt
- “korrekt” oder
- “inkorrekt” (also z.B. “bitte erneut versuchen”) zurück.

Dieser Vorgang wird bei einem Brute-Force Angriff solange mit unterschiedlichen Passwörtern durchgeführt, bis ein korrektes Passwort gefunden wird. Dabei kann ein Angreifer auf eine Fülle von mehr oder weniger guten Werkzeugen zurückgreifen, die den Vorgang automatisieren. Die besseren Werkzeuge bieten komplexere und schneller zum Ziel führende Mechanismen zur Erstellung bzw. Auswahl von Passwörtern. So wird grundsätzlich unterschieden zwischen:

Alle Kombinationen (echtes “Brute-Force”): Der Angreifer versucht sämtliche Kombinationen, beginnend von “0” über “abc012345” bis “ZZZZZZ….Z”. Dabei wird jeweils eine Stelle verändert. Die Mindest- und Maximallänge, sowie der verwendete Zeichensatz können hierbei eingestellt werden.
Wörterbuch (“Dictionary”): Der Angreifer verwendet eine vorbereitete Liste mit Wörtern oder beliebten Passwörtern. Dies ist eine sehr erfolgsversprechende Methode.
Hybrid: Dies ist eine Kombination aus Wörterbuch und Brute-Force.

Benutzername – Frei wählen lassen oder vorgeben?

Zunächst benötigt der Angreifer aber ein Ziel: Für welchen Benutzernamen also versucht der Angreifer das Passwort zu erraten? Grundsätzlich muss davon ausgegangen werden, dass ein Angreifer einen oder mehrere (im schlimmsten Fall: alle) Benutzernamen kennt. Aus meiner Erfahrung kann ich sagen: Lässt man den Benutzer seinen Login-Namen frei wählen, wird dieser in 98% der Fälle über alle anderen Anwendungen und Websiten, welche diese Person nutzt, gleich sein. Wird andererseits ein Benutzername vorgegeben, so kommt meist ein einfach nachvollziehbares Schema (E-Mail-Adresse, “vorname.nachname”, “123456 – 999999”,…) zum Einsatz.

Viele Webapplikationen helfen einem Angreifer und verraten auch direkt oder indirekt, ob eine bestimmte Benutzerkennung existiert. Zum Beispiel bei der Registrierung:

Somit kann ein Angreifer eine Liste mit Namen testen oder generieren und sich sicher sein, dass diese Namen gültige Login-Namen sind. Wird der Benutzername nach einem einfachen Schema vorgegeben, so kann der Angreifer aus bereits bekannten Logins eine Liste generieren.

Das Gegenteil von Gut ist…

… gut gemeint. Ich habe bereits einige Seiten gesehen, die den Benutzernamen einfach nach 3, 5 oder 10 falschen Versuchen sperren. Der Benutzer muss sich dann an eine Hotline wenden um seinen Account wieder freizuschalten. Bei manchen “kritischen” Anwendungen wie e-Banking verlangen manche Anbieter nach einer Sperrung eine Unterschrift und/oder persönliches Erscheinen des jeweiligen Benutzers. Dies ist kein Problem, wenn es nur um eine Handvoll Benutzer geht, die ihren Account selbst durch falsche Eingabe sperren. Problematisch wird es dann, wenn ein Angreifer durch einfache Iteration alle Kunden einer Anwendung sperren kann. Der Angreifer geht also wie folgt vor:

Generieren einer Liste mit gültigen Logins
Austesten des Sperrverhaltens
Aussperren aller Benutzer durch Auslösen des gefundenen Sperr-Schemas

Dies ist für den Angreifer sehr günstig, im besten Fall benötigt er drei Requests um einen Kunden dauerhaft (bis zur Entsperrung durch den Kundendienst) zu sperren.

Was hat der Angreifer davon? Er kann Lösegeld von Unternehmen erpressen und dessen Kunden verärgern.

Bessere Schutzmöglichkeiten

Wie ich eingangs erwähnt habe: Es gibt keinen perfekten Schutz – man kann es einem Angreifer aber sehr schwer machen. Im Folgenden beschreibe ich drei Schutzmöglichkeiten.

CAPTCHA

Mittels Captcha wird überprüft, ob ein Client tatsächlich durch einen menschlichen Benutzer gesteuert wird, oder ob es sich um automatisierte Aufrufe handelt. Das Captcha soll eine Aufgabe darstellen, die ein Programm nicht lösen kann, ein Mensch jedoch schon. Die bekanntesten Captcha Methoden sind das Darstellen von schwer leserlichen Zahlen, die nicht mittels Texterkennung erkannt werden können und sollen. Weiters gibt es Re- oder No-Captcha von Google, bei welchem der Nutzer Bilder erkennen muss, bzw. im Hintergrund anhand der Daten die Google über den Client gesammelt hat (Surf-Verhalten, Suchhistorie, etc.) festgestellt wird, ob es sich wirklich um einen menschlichen Betrachter handelt. Obwohl Captchas durchaus effektiv sein können, können Sie auch legitimen Benutzern Probleme bereiten. So funktioniert zum Beispiel Re- und No-Captcha nicht immer perfekt. Die Buchstaben oder Zeichen sind oft auch für Menschen nur schwer leserlich und mehrere Studien 1,2 stellen die Effektivität von Captchas überhaupt in Frage.

Beschäftige den Client

Derzeit erforschen wir bei der Sec-Research GmbH eine Methode, die den Client Rechenleistung kostet. Der Client muss, bevor er eine Aktion durchführen darf, eine Aufgabe lösen. Mit Client meinen wir tatsächlich den technischen Teil des Clients und nicht den Benutzer. Ähnlich wie beim Tar-Pitting (siehe unten) wird die Aufgabe schwieriger, je mehr Aktionen der Client nicht erfolgreich ausführt (also z.B. fehlerhafte Anmeldeversuche). Die “Aufgaben”, die der Client lösen muss sind für den Client schwer (rechenintensiv), für den Server hingegen aber leicht zu lösen. In diese Kategorie fallen z.B. die Zerlegung in Primfaktoren, das Ziehen des diskrete Logarithmus oder aber das Finden einer Hash-Kollision. Dabei wählen wir die anfängliche Schwierigkeit so, dass auch ein technisch veralteter Client deutlich unter 1 Sekunde benötigt, wenn er zuvor keine fehlerhaften Aktionen ausgeführt hat, also z.B. beim Initial-Login.

Der Nachteil bei dieser Methode ist, dass viele veraltete Clients die hierfür benötigte Methoden in der Client-Skriptsprache (in der Regel JavaScript) oft nicht beherrschen. Clients, die JavaScript deaktiviert haben werden überhaupt ausgeschlossen.

Ich werde die Ergebnisse unserer Forschung in einem eigenen Beitrag veröffentlichen.

Tar-Pitting

Beim Tar-Pitting (engl. für Teergrube) wird die Zeit, die ein Client nach einer fehlerhaften Aktion warten muss, bei jedem Versuch erhöht. Da es sich nur um eine zeitliche Sperre handeln kann, kann ein Angreifer mit Zugriff auf ein Botnetz diese einfach umgehen.