Das Sicherheitsloch in der Mittagspause

#1 Ich habe gerade unter http://www.heysoft.de/nt/mpl.htm einen sehr interessanten Artikel zu einem recht abstrusen Sicherheitsloch in Windows 2000 gefunden:

Schwerpunkt:
Diese Dokument behandelt verschiedene Sicherheitsprobleme im Zusammenhang mit dem Entsperren gesperrter Windows NT Computer. Dabei ist es unerheblich, ob der Computer manuell (mit <STRG+ALT+ENTF> + <ENTER> oder über einen kennwortgeschützten Bildschirmschoner gesperrt wurde.
Stellen Sie sich vor:
Sie sind Administrator eines Windows 2000 Netzwerks. Ihre Sicherheitsrichtlinien legen fest, dass ein Konto gesperrt wird, wenn 5 Anmeldeversuche fehlschlagen. Sie haben alle Service Packs und Hotfixe installiert. HfNetCheck findet keinen Grund, Ihre Konfiguration zu kritisieren. Sie denken, Ihre Rechner sind sicher...
Sie sperren Ihren Computer und machen Mittagspause. Als Sie zurückkommen, ist der Computer (noch oder wieder?) gesperrt, und Sie entsperren ihn problemlos. Routinemäßig schauen Sie in das Ereignisprotokoll und stellen fest, dass es in Ihrer Abwesenheit 5 Sicherheitsereignisse 529 (fehlgeschlagene Anmeldung wegen falschem Kennwort) und 3 Sicherheitsereignisse 539 (fehlgeschlagene Anmeldung wegen gesperrtem Konto) gab, aber kein Ereignis 528 (erfolgreiche Anmeldung). Da hat schon wieder jemand versucht, Ihr Kennwort zu knacken, aber geschafft hat er es nicht - denken Sie.

Das Loch:
Es kann ohne weiteres sein, dass der Unbekannte Ihr Kennwort schon kennt und sich nur eine Sicherheitslücke von Windows 2000 zu nutze macht, um sich an Ihrem Rechner anzumelden, ohne Spuren der erfolgreichen Anmeldung und späteren Sperrung im Sicherheitsprotokoll zu hinterlassen. Alle Versionen von Windows NT protokollieren nämlich unter bestimmten Voraussetzungen erfolgreiche Anmeldungen, die eigentlich als Sicherheitsereignis 528 protokolliert werden, als fehlgeschlagene Anmeldungen (Sicherheitsereignis 539)!
Da auch das Sperren des Rechners "by design" nicht protokolliert wird, hat ein lokaler Angreifer somit die Möglichkeit, sich am gesperrten Rechner anzumelden und diesen nach getaner "Arbeit" wieder zu sperren, ohne Spuren über die Anmeldung im Sicherheitsprotokoll zu hinterlassen.

Die Voraussetzungen für einen erfolgreichen Angriff ohne Protokollierung:

Die Sicherheitsrichtlinien legen fest, dass ein Konto gesperrt wird, wenn zu viele Anmeldeversuche fehlschlagen.
Der Computer ist gesperrt.
Das Konto ist durch genügend Fehlversuche (Bedingung 1) ebenfalls "gesperrt".
Die Standardkonfiguration, die das Entsperren des Computers selbst mit gesperrtem Konto erlaubt, wurde nicht verändert.
Das Kennwort ist bekannt oder kann schnell erraten werden.
Workaround:
Nehmen Sie die in KB-Artikel Q188700 empfohlene Änderung an der Registrierung vor. Die Änderung besteht im Hinzufügen folgenden Wertes: Key: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon
Wert: ForceUnlockLogon
Typ: DWORD
Inhalt: 1 (ein) oder 0 (aus)
Microsoft gibt an, dass der Rechner nach dieser Änderung neu zu starten wäre. In allen hier durchgeführten Versuchen funktionierte die Änderung aber sofort ohne Neustart.
Bei ForceUnlockLogon = 1 kann man mit einem gesperrten Benutzerkonto einen gesperrten Computer nicht mehr entsperren. Somit kann ein Angreifer dann auch den Fehler im Sicherheitsprotokoll nicht mehr ausnutzen.
Hersteller:
Microsoft wurde im Dezember 2001 über das Problem informiert. Laut Auskunft vom 18. Januar 2002 soll der Fehler in der Ereignisprotokollierung "im nächsten Service-Pack" behoben werden. Auf Nachfrage wurde dann aber mitgeteilt, dass es ein SP 7 für NT 4 definitiv nicht geben wird.

Fragen und Antworten:

Hat WXP weitere Probleme mit dem "Entsperren" des Desktops?
XP kann nicht richtig zählen und sperrt das Konto einen Versuch zeitiger als vorgegeben. Wenn Sie also zum Beispiel eingestellt haben, dass das Konto nach 3 fehlgeschlagenen Anmeldeversuchen zu sperren ist, geschieht das bereits nach dem 2. Versuch. Während die Programmierer der Vorgängerversionen noch bis 3 zählen konnten, haben die Nachfolger damit offensichtlich Schwierigkeiten ;-)

Ein anderes Problem betrifft nur XP-Rechner, die noch nie einer Domäne angehört haben. Es wirkt sich negativ auf den Supportaufwand aus und kann den Benutzer zur Verzweiflung treiben. Angenommen, jemand (das muss ja nicht der Benutzer sein) gibt so oft ein falsches Kennwort ein, bis das Konto gesperrt ist. Dann kommt der Benutzer zurück an seinen Arbeitsplatz und will den Rechner entsperren. Er erhält die Meldung "Haben Sie Ihr Kennwort vergessen?" auch wenn er sofort das richtige Kennwort eingegeben hat. Es wäre netter, wenn XP mitteilen würde, dass das Konto gesperrt ist, statt den Benutzer frustriert wieder und wieder sein richtiges Kennwort eingeben zu lassen und mit der wiederholten Frage "Haben Sie Ihr Kennwort vergessen?" in den Wahnsinn zu treiben.
Dieser Fehler (gleiche Meldung an den Benutzer, unabhängig davon, ob das Kennwort falsch eingegeben wurde oder das Konto gesperrt ist) tritt übrigens auch bei Windows 2000 auf, wenn ForceUnlockLogon auf 1 gesetzt ist.
Windows NT 4 informiert den Benutzer dagegen immer mit einer exakten Fehlermeldung.

Kann ein Angreifer feststellen, ob der Registrierungswert ForceUnlockLogon auf 1 gesetzt wurde?
In W2K sieht er das, sobald er ein Kennwort falsch eingegeben hat. Es erscheint dann eine andere Fehlermeldung als an Rechnern, an denen die Änderung nicht vorgenommen wurde. Bei Domänenmitgliedern mit NT 4 und WXP ändert sich die Fehlermeldung dagegen nicht.
__________
powered by http://different-thinking.de - Netze, Protokolle, Sicherheit, ...