Kontosperrung bei Kennwortfehleingabe - Vorteile, Nachteile, Angriffe

Das hier untersuchte Problem ist anwendbar in allen Windowsdomänen, deren Domänenauthentifizierung allein über Kennwörter läuft.
Es ist seit vielen Jahren bekannt und doch habe ich noch keine Untersuchung gesehen, die auch ausführlich auf Gegenmaßnahmen eingeht.
Worum es geht: jeder, der schon einmal eine Domäne härten wollte, stößt früher oder später auf das Thema Kennwortrichtlinien und ebenso Kontosperrungsrichtlinien (automatische Sperrung bei wiederholter Kennwortfehleingabe).

Beispielsweise empfiehlt das BSI im IT-Grundschutz-Kompendium 2020:

Und was fehlt hierbei? Eine Beschreibung des „wie sicher muss es denn sein?“.
Aber gut, man darf davon ausgehen, dass wenn das BSI „Kontensperrung“ schon aufführt, es zumindest nicht empfehlen würde, diese in den Grundeinstellungen zu betreiben, denn das würde bedeuten, es würde gar nicht automatisch gesperrt, Kennwörter könnten beliebig häufig falsch eingegeben werden.

Und tatsächlich, man findet weiter in den Umsetzungshinweisen https://www.bsi.bund.de/DE/Themen/ITGrundschutz/ITGrundschutzKompendium/ ...

Der folgende Text soll bei der Suche nach dem besten Weg helfen.
 
Worin besteht nun das Problem?

Wenn ich als Admin ein Konto bei Fehleingabe automatisch sperre, ja dieses sogar gesperrt lasse, bis der Admin die Sperrung aufhebt, dann ist es möglich, dass der Gesperrte ein wenig sauer wird. Ja es ist sogar möglich, dass er sich über den Admin beschwert, denn er hat sich zum Beispiel am Wochenende extra in die Firma bewegt, knüppelt Überstunden, und hat in seinem Tran lediglich 3x das Kennwort falsch eingegeben und konnte nun nicht arbeiten und das trifft seine Arbeitsplanung hart. Naja…wenn Wochenendarbeit anberaumt ist, dann muss wohl auch ein Admin verfügbar sein für solche Fälle, aber egal, sagen wir mal, die Einstellung kann zu Unmut führen.

Das eigentliche Problem mit der Kontensperrung ist aber ein ganz anderes: ich gehe nun mal zu einem gesperrten PC, da sitzt gerade niemand, der blöde Herr Müller ist wohl eine rauchen. Nun gebe ich dreimal den Buchstaben a als Kennwort ein und schon ist Herrn Müllers Konto gesperrt. Der wird sich ärgern, ach ist das schön, das mache ich morgen gleich noch einmal! Mobbing für Arme.

Der Admin wird dann früher oder später gefragt werden, ob man da nicht was tun kann, zum Beispiel die automatische Sperrung für den Herrn Müller zumindest temporär abschalten könnte. Klar, das geht, wenn man PSOs und nicht GPOs verwendet, dann könnte man Ausnahmen definieren (mit GPOs wäre diese Einstellung zwingend global gültig, mit PSOs nicht).

Wird der Admin nun dieser Bitte nachkommen? Darf er der Bitte nachkommen? Das wird der IT-Sicherheitsbeauftragte entscheiden müssen, nicht der Admin.

Welches Risiko ist denn überhaupt da, wenn man nun eine automatische Sperrung ganz abschaltet? Nun, dann könnte jemand versuchen, Kennwörter per Brute-Force zu knacken. Ist das realistisch? Kommt da jemand anspaziert, startet sein Tool/Skript und versucht nun Müllers Kennwort zu knacken? Wie läuft das ab?

Ich spiele mal Angreifer. Zunächst einmal stelle ich fest, ob es eine Kontosperrungsrichtlinie gibt – die gibt es nicht, gut!
Dann schaue ich mir den Anzugreifenden an, wo kann der sich anmelden? Überall. Sehr, sehr gut!
Dann schaue ich mal, wie lange sein Kennwort noch gültig ist: 6 Monate, passt!
Nun mal sehen, wie lang sein Kennwort sein könnte… Minimum 8 Zeichen…hm, weniger gut. Komplex muss es auch sein… auch nicht so gut. (all diese Infos kann man per Default als jedermann auf der Kommandozeile auslesen).

Würde ein Angreifer nun sein angedachtes Bruteforcing angehen, oder nicht? Das ist nicht mit Sicherheit zu beantworten. Stattdessen möchte ich mir vorstellen, dass ich den Müller bei der Kennworteingabe beobachte. Ich sehe zwar nicht genau, was der da eintippt, aber immerhin sehe und höre ich, dass Müllers Kennwort 8 Zeichen hat und dass der Müller da zweimal Shift gedrückt hat und zwar am Anfang (großes G war das, glaube ich) und am Ende (das war wohl ein „!“). Und zwischendrin hat der Müller auf jeden Fall noch ein x und ein u getippt, das habe ich auch gesehen aber ich bin bei der Position der beiden unsicher, vielleicht war das x der vierte und u der fünfte, vielleicht aber auch der fünfte und der sechste Buchstabe… Somit bleiben noch vier Zeichen zu erraten, alles waren Kleinbuchstaben, und ebenso ist die Position der beiden bekannten mittleren Buchstaben nicht ganz klar, was den Kennwortraum noch einmal verdoppelt.

Um die Rechnung abzukürzen, ich komme bei ca. 900.000 möglichen Kennwörtern raus(/1,4 Mio, wenn auch ä,ö,ü mitgezählt werden).
Ich habe bekanntlich bis zu 6 Monate Zeit, um diese durchzuprobieren, das macht rund 5000 (/8000) Kennwörter am Tag, das ist lachhaft wenig und somit leichte Beute für einen Bruteforce-Angriff – dieser wird mit Sicherheit gelingen. Ohne auf die Art und Weise des Bruteforcings näher eingehen zu wollen, hier nur eine Hausnummer: selbst auf schwachen PCs und mit rechenschwachen Domänencontrollern sollte es möglich sein, etwa 20 Kennwörter pro Sekunde zu testen, somit kann ich an einem einzigen Arbeitstag von 8 Stunden schon mehr als eine halbe Million Kennwörter testen, spätestens nach 2(/3) Tagen hätte ich also Müllers Kennwort! Wer nun sagt "das wird aber auffallen, denn DCs loggen ja Fehlversuche", der hat Recht. Aber findet diese Auswertung regelmäßig statt? Evtl. ist das Kind da schon längst in den Brunnen gefallen.

Dass dieses Gedankenspiel nicht nur einen böswilligen Angreifer voraussetzt, sondern auch ein erfolgreiches vorangegangenes „Shouldersurfing“ (der Angreifer kann Teile des Kennwortes bei der Eingabe mitlesen) sowie eine nicht sonderlich harte Kennwortrichtlinie, ist mir klar. Dennoch halte ich das für ein sehr reales Beispiel.

Wie kann ich nun einem Angreifer dieses Bruteforcing erschweren ohne gleichzeitig eine überaus harte Kennwortrichtlinie einführen zu müssen? Na, ich setze eine automatische Sperrung bei Fehleingabe! Was ich da als Anzahl eintrage, ist ziemlich Banane, lass mich Euch mal vorrechnen, was passiert, wenn ich den Höchstwert von 999 erlaubten Versuchen bis zur Sperrung nutze. Ich stelle als Admin also ein, dass für 30 Minuten gesperrt wird, sobald das Kennwort 999 Mal falsch eingegeben wurde.

Der Bruteforcer muss also ständig Zwangspausen einlegen um nicht an diese Schwelle zu stoßen. Wie lang ist diese Pause? Auch das ist konfigurierbar. Lass uns dort mal ein einstellen: Kontosperrungszähler zurücksetzen nach: 1440 Minuten (=1 Tag).
Das bedeutet für den Bruteforcer, dass er nur ca. 1000 Kennwörter (genauer: maximal 998) pro Tag testen kann, womit er also für die 900.000 (/1.4 Mio) Möglichkeiten 900 (/1400) Tage zu tun hätte – bis dahin ist das Kennwort längst mehrfach geändert worden.

Was aber wäre, wenn ein Programm, das Müller nutzt, sein Kennwort gespeichert hat und dieser Müller ändert sein Kennwort? Dann wird der Automatismus im Programm eventuell so oft versuchen, das alte Kennwort einzugeben, bis das Konto gesperrt ist (Automatismen können sehr dumm sein…)! Er wäre dann auf einen Admin angewiesen, um ihn zu entsperren, da er nicht 24 Stunden warten möchte, um diese wichtige Wochenendarbeit zu erledigen. Hm, vielleicht setzen wir diese Sperrdauer doch eher so, wie das BSI vorschlägt auf 30 Minuten. Auch bei „Kontosperrungszähler zurücksetzen nach…“ folgen wir dem BSI und setzen es ebenso auf 30 Minuten. Wie viele Kennwörter kann der Bruteforcer nun täglich in 8 Stunden durchdaddeln? Nun, alle 30 Minuten 1000 Kennwörter, das macht (8:00/8:30/9:00/…15:30/16:00) rund 17.000 pro Tag. Bekomme ich damit die 900.000 Möglichkeiten in 6 Monaten durchgetestet? Leicht und lässig schaffe ich das in 2-3 Monaten (3-4 Monate bei 1,4 Mio).

Doch Moment, hat das BSI nicht vorgeschlagen, bereits nach 3 (!) Fehlversuchen zu sperren? Dann hätte ich also pro Tag nur 3, nein 2x17=34 Versuche und würde die 900.000 Kombinationen selbst in 50 Jahren Dienstzeit nicht schaffen .

Na sauber, das ist doch was. Also hilft die automatische Sperrung gegen Bruteforcing unter Umständen sehr effektiv!
Die beiden Stellschrauben "Lockout Observation Window" (beeinflusst die Dauer der Zwangspause) und die Anzahl der zugelassenen Fehlversuche ("Lockout Threshold") spielen also zusammen und müssen nur passend austariert werden, damit es unwahrscheinlich wird, dass sich selbst bei arg verkleinertem Kennwortraum noch ein Bruteforcing lohnt. Ohne auf Vorschriften zu achten sagt mir mein Bauchgefühl, dass 100 Fehlversuche kombiniert mit einem Observation Window von einem Tag passen sollte - dann dauert das Bruteforcing von 1 Mio Kennwörtern nämlich fast satte 30 Jahre, niemand ist genervt durch zu schnelles Sperren und ein manuelles "Mobbingsperren" wird auch sehr erschwert.

Fazit: ich denke nicht, dass Angreifer so vorgehen, nein. Das ist hier Theorie und die Theorie ist zwar denkbar, aber Angreifer werden wohl eher andere Wege versuchen, um Identitäten anderer Nutzer zu kapern. Dennoch ist eine automatische Kontensperrung definitiv eine Überlegung wert und evtl. sogar vorgeschrieben!
Ok, das war bis hierher tatsächlich alles Vorrede und Vorüberlegung!

Ich gehe des Weiteren von einer Firma aus, die den BSI-Empfehlungen folgt und eine automatische Sperrung nach 3 Fehlversuchen eingestellt hat und den Zähler nach 30 Minuten zurücksetzt und dann sogar dauerhaft sperrt, bis der Admin die Sperre aufhebt.
Ich wechsele jetzt die Rolle von einem Bruteforcer hin zu einem ganz tollen Spaßvogel. Einem Spaßvogel, der ein wenig skripten kann und sich ein wenig mit dem Active Directory auskennt, also zumindest weiß, wie man die Einstellungen die da herrschen, ausliest. Ich schreibe also ein Skript (oder kopiere mir eins aus dem Internet), was Folgendes macht:

1 es liest alle Nutzerkontennamen der Domäne aus, die aktive Konten haben und sich überall anmelden dürfen
2 es gibt für all diese Konten 3x das falsche Kennwort „a“ ein.

Das Skript parke ich auf einem USB-Stick und gehe mit diesem zum nächstbesten PC, den ich ungesperrt vorfinde und starte es.
Was passiert dann? Bei einer Firma mit sagen wir mal 200 aktiven AD-Nutzern sind diese in ca. 30 Sekunden (!) allesamt gesperrt. Das umfasst auch alle Dienstekonten und alle Admins, die diese Sperrung wieder aufheben könnten. Moment, alle Gallier Admins? Nein, zum Glück gibt es noch den eingebauten Domänenadmin „Administrator“, der nicht gesperrt werden kann! Kurz geprüft, lässt das BSI überhaupt zu, dass wir diesen aktiviert belassen? Ja, tut es, puh… sonst sähe es nun finster aus.

Auf jeden Fall wird nach kurzer Zeit ein kollektiver Aufschrei durch die Firma gehen, soviel ist mal sicher. Den wird der Admin nicht überhören.
Wenn der diensthabende Admin auf Draht ist, hat er sogar das Kennwort dieses eingebauten Kontos am Start (Umschlag im Safe), meldet sich damit an, erzeugt eine Userliste und lässt ebenso gegen diese ein Skript zur Entsperrung laufen und nach weniger als 10 Sekunden Laufzeit ist der Spuk vorbei. Wenn der Admin auf Draht ist, kann er nun sogar sehen, dass der „Angriff“ von IP-Adresse x.x.x.x ausging und wird sich mal ansehen welcher Rechner das ist, wo der steht und wer da sitzt… mittlerweile ist der Angreifer natürlich pfeifend von dannen und der arme Kerl, der seinen Rechner ungesperrt hinterlassen hat, wird sich ein paar ernste Fragen anhören müssen.

Welcher Schaden ist entstanden?

Alles stand eine Weile still, evtl. sind sogar Dienste, deren Konten gesperrt wurden abgestürzt und müssen nun erst einmal gesucht und wieder neu gestartet werden.
Zudem hat die Belegschaft nicht unbedingt laut gelacht über diese Zwangspause und wird natürlich auch die Skills des Admins in Frage stellen.
Was wäre denn gewesen, wenn jemand das Skript gestartet hätte, wenn der Admin krank ist und ohne Vertretung (Vertreter existiert auf dem Papier, ist aber gerade zur Mittagspause, oder er ist da, weiß aber nicht, was zu tun ist)? Dann würden satte 30 Minuten vergehen, bis sich die Konten automatisch wieder entsperren. Wenn der Angreifer besonders lustig sein will, sperrt er natürlich am Schluss auch das Konto des Nutzers, der das Skript startet und danach (per Kommando) noch dessen Bildschirm, fügt dem Skript einen Timeout von 30 Minuten hinzu und lässt es dann wiederholt als Schleife laufen. Autsch, der Ausfall wird dauern!
Es wäre sogar denkbar, diesen Angriff als Nebelkerze nebenher zu einem Angriff gegen die Fileserver zu starten - ein bißchen Verwirrung stiften und vom eigentlichen ablenken!

Ok, soweit zum Angriff, kommen wir nun zur Gegenwehr.

Was ist hier schiefgelaufen, abgesehen von dem eher menschlichen Umstand, dass ein Rechner mal nicht gesperrt war?

1. Der Rechner war nicht nur ungesperrt, sondern der Angreifer war sich sicher, dass er ein wenig Zeit für den Angriff hat, da er die Gewohnheiten der missbrauchten Nutzer kennt!
Abhilfe: wenn die PCs von einigen wirklich regelmäßig nicht gesperrt werden, so muss das angesprochen werden! Betriebsvereinbarungen inklusive Sanktionen könnten helfen!

2. Die Parameter, wann sich Konten sperren und wann der Counter zurückgesetzt wird, waren zu hart eingestellt.
Abhilfe: diese „Härtungen“ sollten überdacht werden (siehe Vorüberlegungen und Beispiele weiter oben). MUSS der Betrieb hier wirklich den Vorschlägen des BSIs folgen?

3. Eine Softwarekomponente (wie auch immer gearteter Wächter oder Appliance) hätte die massenhaften Fehlanmeldungen erkennen können und hätte je nach Einstellung den Netzwerkverkehr zwischen diesem Gerät und den DCs frühzeitig kappen können.
Abhilfe: Es gibt ja Intrusion-Detection-Systeme, die so konfiguriert werden können, dass sie dieses oder jenes Blocken. Testet doch mal aus, ob Eure ggf. vorhandenen Systeme diese Art Angriff erkennen, indem Ihr einfach mal so viele Testkonten erzeugt wie ihr Nutzer habt und diese dann automatisiert „angreift“. Erkennen Sie das nicht, prüft, ob man das schärfer einstellen kann, falls es überhaupt geht.

4. Der Angreifer war in der Lage, auf dem PC ein Skript zu starten
Abhilfe: Das zu verbieten, ist gar nicht so leicht. Klar, man kann recht einfach die Nutzung von USB-Sticks verbieten und man kann auch per Applocker die Nutzung von Skripts verbieten, aber beides führt wieder zu dauerhaft vermindertem Komfort.

5. Der Angreifer konnte dieses Skript auf einfache Weise erstellen (Kontennamen konnten ausgelesen werden)
Abhilfe: Dass es ohne weiteres möglich ist, diese Infos auszulesen, heißt im Umkehrschluss nicht, dass es auch einfach ist, diese Infos unlesbar zu machen! Da sich einige Mechanismen in Programmen hierauf verlassen, wird ein Abschalten der Lesbarkeit dieser Details zwangsläufig Nebeneffekte haben. Hier ist Vorsicht geboten.

6. Es gab viele Konten, die sich überall anmelden können (Achtung, das ist der Default!)
Abhilfe: Dieser Punkt ist sehr interessant, wie ich finde. Warum sollte sich Lieschen Müller überall anmelden können? Ja, für Großraumbüros (evtl. setzt sich jeder fast täglich an einen anderen Platz und PC) ist das sinnvoll, aber in sehr vielen Unternehmensumgebungen ist das überflüssig! Kann man die Zahl beschränken, so wird der Angriff schwerer. Kann man die Zahl auf einen festen Mitarbeiter-PC reduzieren, so wird der Angriff sogar unmöglich! Diese Einschränkung der Anmeldeberechtigungen nimmt man direkt im Userobjekt im AD vor – man verwendet dazu NICHT die GPOs „Lokale Anmeldung zulassen/verweigern“ – diese helfen nicht!
Was man in jedem Fall machen MUSS: reduziert die Workstations, wo sich die Admins und die Dienstekonten anmelden können auf ein Minimum. Man braucht keine globalen Admins, glaubt mir das (wir nutzen keine!). Auf diese Weise können diese wichtigen Konten schon mal nicht ohne Weiteres angegriffen werden, Restrisiken siehe 7.

7. Der angreifende unbekannte PC durfte mit den DCs kommunizieren
Wenn jemand sagt, „bei uns werden die PCs eher nie ungesperrt sein, da sie sich nach spätestens 2 Minuten Leerlauf von alleine sperren“, der übersieht etwas Wichtiges: man könnte den Angriff auch von seinem eigenen PC aus durchführen. Denkt mal an eine Schule, an einen Informatikraum. Da zieht jemand sowas durch und behauptet im Nachhinein, er wäre das gar nicht gewesen, irgendein anderer muss das wohl bei ihm eingetippt haben in der Zeit, wo er bei der Gruppenarbeit gerade zum Nebenmann geschaut hat. Wird der nun bestraft, oder nicht?
Oder was wäre denn, wenn ich meinen Mini-PC mitbringe, und den kurzzeitig an das Netzwerkkabel meines Büro-PCs anstecke, nur so für 30 Sekunden, langt doch. Da die Mac-Adresse gar nicht zu meinem PC passt und ich den Mini-PC schnell wieder verschwinden lassen kann, wird niemand sicher sagen können, woher der Angriff kam, oder?
Das Problem ist nämlich: der angreifende PC muss dazu gar nicht in der Domäne sein. Wenn wir eingestellt haben, dass sich alle Nutzer von überall anmelden können (nochmal: das ist der Default!), dann kann ich auch einen Nicht-Domänen-PC für den Angriff nutzen! Ebenso könnte ich meinen BYOD-PC nehmen und ihn so nennen, wie eine für das anzugreifende Konto erlaubte Workstation.
Abhilfe: Dieser Punkt ist sehr einfach abgebacken: Firewalls, die mit Authentifizierung arbeiten (zum Beispiel die Windowsfirewall, wenn man gesicherte Regeln mit Kerberos-Authentifizierung benutzt), können den Datenverkehr von unbekannten Rechnern zum DC hin von vornherein verbieten.
Siehe https://medium.com/@cryps1s/endpoint-isolation-with-the-windows-firewall ...


Fazit: Ich denke, man muss sich mit diesem Problem auseinandersetzen. Die Ausrede „das ist in den letzten 10 Jahren auch nie vorgekommen“ zieht im Fall der Fälle leider nicht. Die Keule rauszuholen und die automatische Kontensperrung ganz zu deaktivieren, halte ich persönlich für gefährlich. Die beste Gegenmaßnahme ist meiner Ansicht nach 6. – Logonworkstations beschränken und evtl. 7., die Firewall mit Authentifizierung. Auch sollte man – sofern man darf – die Anzahl der erlaubten Fehlversuche überdenken und evtl. stark erhöhen. Dies verlangsamt auch den Angriff.
PS: das ist meine Meinung und nicht etwa der Weisheit letzter Schluss. Ich habe jedoch versucht, gründlich zu argumentieren. Wenn jemand nun Fragen dazu hat, oder Sachen in Zweifel zieht, oder nur seinen Senf dazugeben will, oder, oder, oder, dann nehmt Euch bitte Zeit, zumindest vorher den Beitrag gründlich zu lesen und verzichtet auf Schnellschüsse.