NT4/2000/XP: Login zusätzlich absichern

#1 Die Benutzer der im Titel genannten Betriebssysteme kennen die Anmeldeprozedur beim Starten bereits:
Name & Passwort müssen zwingend angegeben werden, ein gleichlautendes Benutzerkonto muss existent sein,
ansonsten ist ein erfolgreicher Login ins System nicht möglich.
Das Problem:
3'rd Party Tools wie CIA- und ERD-Commander erlauben das Rücksetzen jedes
beliebigen Kennwortes.
Unter anderem kann auch das Administrator Passwort neu gesetzt werden.
Diese an sich nützlichen Utils könnten somit natürlich problemlos dazu genutzt werden, sich als Administrator
unberechtigterweise Zugang zum System zu verschaffen.

Die nachfolgend aufgeführte Lösung (oder besser: Verbesserung) eignet sich bestens für folgende Szenarien:
a) Auf einem Host haben ausschliesslich User bestimmter Gruppen Zugriff, bspw. Administratoren auf einem
DC oder Server.
b) Der Computer wird nur von einem(!) User benutzt, welcher verhindern möchte,
dass sein Account durch
die o.g. Tools manipuliert wird.

Ungeeignet ist dieser Tipp für Hosts, auf denen sich mehrere User mit verschiedenen Rechten
einloggen dürfen.

Falls a) oder b) zutrifft:
Abhilfe schafft ab Win NT4 (SP 3) das Windows eigene Programm "Syskey", welches in einer Shell
aufgerufen werden kann. Primär dafür verantwortlich, die SAM zu kodieren und das Brute-Forcen oder Auslesen der
Passwörter zu erschweren, besteht aber noch ein sehr angenehmer Nebeneffekt: Das System kann mit
einem zusätzlichen Start-Passwort versehen werden!
Besagtes Kennwort wird VOR(!) dem eigentlichen Login abgefragt, erst nach der erfolgreichen Eingabe des
Syskey Passwortes wird der eigentliche Windows Anmeldescreen geladen.

Ein so geschütztes System ist immun gegen Änderungen, die mit den o.g. Programmen durch Rücksetzung
eines Konto Passwortes vorgenommen wurden, denn wird das Start Kennwort nicht oder falsch eingegeben,
weigert sich Windows den Bootvorgang fortzusetzen und führt nach dreimaligen inkorrekten Versuchen einen
Warmstart aus!

Konfiguration Syskey:
Mittels "cmd" eine Konsole öffnen, "Syskey" eintippen.
Windows 2000/XP User klicken nun den Button "Aktualisieren" an, NT4 (ab SP3) Besitzer müssen u.U.
erst die Option "Verschlüsselung aktiviert" markieren und aktivieren.
Im Menü "Kontendatenbankschlüssel" können wir nun zwischen 2 Optionen wählen:
1.: Kennwort für den Systemstart
Markieren wir diese Option, verlangt Windows von uns die Eingabe eines Start Kennwortes. In den Feldern
unterhalb wird dieses definiert.

2.: Schlüssel für den Systemstart auf Diskette...
Die Hardcore Variante. Windows generiert einen Key, speichert diesen auf eine Diskette ab. Bei jedem
Booten des Computer muss die Disk eingelegt werden, ansonsten wird der Startvorgang abgebrochen.

Diese Sicherheitskonfigurationen greifen auch im abgesicherten Modus und beim Starten der
Wiederherstellungskonsole!

Bye

#2 Aus der FAQ vom NT Password Changer:

What happens when syskey is installed, and how to get rid of it
---------------------------------------------------------------

Background:
-----------

Syskey was added to NT with Service Pack 3 as a way to prevent easy
access to the actual password hashes in the SAM (Security Accounts Manager)
The original methods of making and storing the hashes makes it
rather easy to bruteforce or dictionary-attack it to find the plaintext
passwords. (mostly caused by a somewhat flawed implementation & use
of the cryptoalgorithms involved, but that's discussed elsewhere)
Enabling syskey is optional, the administrator must run syskey.exe and
answer some dialog-boxes to turn it on. On Windows 2000 it's not optional
anymore, it's enabled by default at installation time.

When syskey is active, the hashes are encrypted/obfuscated yet
another time before being stored in the SAM registry.
However, they're stored in the old form in memory after boot
(pwdump2 demonstrates this),
since the old form is needed for NTLM authentication on the network etc.

The key that obfuscates the hashes, or rather it looks like something
that decrypts the key, can be stored on floppy, generated from a
passphrase to be entered at boot, or stored (obfuscated again) in
the registry.

There's no official supported method to switch off syskey
once activated, except restoring the registry from a rescuefloppy
made before activation of syskey.

So.. what's this got to do with my utility?
-------------------------------------------

My utility doesn't try to crack passwords, it puts new hashes into
the SAM, thus changing a users password. And it does this offline.
Syskey was a showstopper for this.
As far as I can see, there's 2 ways to solve this:

1) Find the key in registry, get user to enter it, or get hold of floppy
then use the syskey on the new password too. However, it's not documented
and I haven't found any reverse engineering of it anyplace.

2) Try to turn it off. This has one drawback, and one good side:
Bad: all passwords must be reset, since the old hashes will be invalid.
VeryBAD: SWITHCHING OFF IN WINDOWS 2000 AND XP NOT PERFECT,
WILL CAUSE TROUBLE, but you can access the computer
afterwards. Domain relationships & syskey may be
impossible to change after this, requiring a reinstall
(or possibly only an upgrade)
Good: There's no need for the key (which may be lost).

3) (NEW 2000-04-01, no, not a joke) Insert old styles password-hashes
into the SAM, will be converted to syskey-hashes on next boot.
This is how syskey is enabled on NT4, the hashes won't be touched
until the first reboot after turning on syskey.

I've found out how to do #2 and #3.

What happens when syskey is turned on, and how to turn it off again:
--------------------------------------------------------------------

- 1 -
Serveral new keys are added to HKLM\System\CurrentControlSet\Control\Lsa,
it seems that most of the keys/values is used for the obfuscation of the key
they change when syskey is updated.
However the value named 'SecureBoot' holds the mode of syskey:
1 - Key in registry
2 - Enter passphrase
3 - Key on floppy

But removing this key (or setting it to 0) isn't enough to disable
syskey. There's more..

- 2 -
HKLM\SAM\Domains\Account\F is a binary structure usually containing the computer
SID and some other stuff related to that.
When syskey is installed it's expanded (about twice the size), with something
I guess is the key heavily encrypted + some flags and other values.
One of these other flag/values also contains the same mode as SecureBoot above.

So.. resetting this mode flag and SecureBoot to 0 is all that's needed
to switch off syskey in NT4 (up to SP6 at time of writing). Changing only one of them
results in a warning about inconsistencies between the SAM and system settings
on completed boot, and syskey is re-invoked.

- 3 -
On Windows 2000 there's yet another place info about syskey is stored:

HKLM\security\Policy\PolSecretEncryptionKey\<default>
which also is a binary structure, but also there the mode is stored.
Reset this to 0, and syskey is gone on win2k.
(if there's a mismatch between the three, it silently resets them
to the most likely value on boot)

- 4 -
Then there's the password hashes.
The usual (old) hashlength is 16 bytes, but all hashes are expanded to 20 bytes
with syskey, the first 4 bytes looks like some kind of counter. (maybe
history-counter?).
Strangely, they're not updated at once when syskey is turned on,
update of the hashes happens during next reboot after syskey has been turned on.
And when the key is later updated, the hashes are also updated?
NO!! Strangely it SEEMS like the password hashes REMAINS THE SAME!
(however, the binaries in the 3 keys noted above changes..)
I'll try to dig more into this. Help wanted

When syskey has been switched off, all passwords must be reset.
My utility will write and adjust hash-lengths of the users (usually
administrator) that you reset the password for.
NT itself will fix the rest of the hashes when you set new passwords
from NT.

And yes, it's possible to re-enable syskey after turning it off.
(not on win2k, yet!)

So, anybody reverse engineered the whole syskeystuff?
(yes, I know something's on it's way..)
-------------------------------------------------------------

Hab´s allerdings noch nie ausprobiert und gerade kein Testsystem da.
__________
Bitte keine Anfragen per PM, diese werden nicht beantwortet.

#3 Hi asdrubael,

erstmal thx für die Info! Ich werde mal ein Image von meinem 2000 SP4 ziehen und danach versuchen, Syskey anhand
der Beschreibung zu deaktivieren oder zu manipulieren.

Mir ist schon bewusst, dass Syskey mit dem Startkennwort nicht die ultimative Lösung und unknackbar ist,
jedoch schrieb ich ja auch nur von "zusätzlich absichern". Sofern sich Syskey mit besagtem Start-
kennwort meldet, ist es ja unerheblich ob vorher bei div. Konten eine Passwortrücksetzung
vorgenommen wurde (welche sich nach wie vor realisieren lässt). Trotzdem hast du & der Autor
vom NT Password Changer natürlich recht: Gelingt es, Syskey zu deaktivieren fällt auch das Start-
Passwort flach!

@all:
Gibt es ggf. schon eine Art von Anti-Syskey Tool, das sich mehr oder weniger ausschließlich mit
der Entfernung dieses MS Util aus der Registry beschäftigt? Hat irgendjemand
Infos darüber?

Anyways, ich poste hier mal, was meine Versuche ergeben haben sobald ich
in mein eigenes System eingedrungen bin

#4 Also so sieht's aus:

OS: Win 2K SP4
Software: RegEdit vom ERD-Commander
Syskey aktiv, Passwort muss beim Starten eingegeben werden

"- 1 -
Serveral new keys are added to HKLM\System\CurrentControlSet\Control\Lsa,
it seems that most of the keys/values is used for the obfuscation of the key
they change when syskey is updated.
However the value named 'SecureBoot' holds the mode of syskey:
1 - Key in registry
2 - Enter passphrase
3 - Key on floppy

But removing this key (or setting it to 0) isn't enough to disable
syskey."

>OK!
>Key vorhanden, konnte problemlos auf "0" gesetzt werden.

"- 2 -
HKLM\SAM\Domains\Account\F is a binary structure usually containing the computer
SID and some other stuff related to that.[...]"

>Stopp!
>Schlüssel nicht vorhanden!
>Vorhanden ist: HKLM\SAM\SAM\Domains\Account\F (2xSAM)
>Entweder ein Typo des Autors, rein NT4 spezifisch oder durch MS mittels
>irgendeinem SP geändert(??).

"[...]When syskey is installed it's expanded (about twice the size), with something
I guess is the key heavily encrypted + some flags and other values.
One of these other flag/values also contains the same mode as SecureBoot above.

So.. resetting this mode flag and SecureBoot to 0 is all that's needed
to switch off syskey in NT4 (up to SP6 at time of writing). Changing only one of them
results in a warning about inconsistencies between the SAM and system settings
on completed boot, and syskey is re-invoked."

>Soweit so gut. Der Schlüssel HKLM\SAM\SAM\Domains\Account\F auf meinem
>System beinhaltet die erwähnten binären Werte. Ich wußte jedoch nicht,
>welchen Wert (mode flag) ich ändern sollte.
>Hier wären genauere Details seitens des Autors (oder eines RCE's) hilfreich.
>U.U. bezieht sich aber der gesamte Punkt 2 der FAQ nur auf NT 4. K.A
>Ergo: Nichts geändert

"-3-
On Windows 2000 there's yet another place info about syskey is stored:

HKLM\security\Policy\PolSecretEncryptionKey\<default> [...]"

>OK!
>Schlüssel vorhanden

"[...]which also is a binary structure, but also there the mode is stored.
Reset this to 0, and syskey is gone on win2k."

>No way! Entweder verstehe ich hier irgendwas nicht oder mittlerweile hat
>MS dem einen Riegel vorgeschoben:
>Ich konnte keinen Wert für den <Default> Eintrag ändern, da war nämlich
>keiner! Der Schlüssel ist existent, ein Wert kann jedoch weder hinzugefügt
>noch geändert werden. Der gesamte Key ist de facto ohne einen Wert
>vorhanden.
>Ebenfalls möglich, dass dies durch ein Service Pack geändert wurde(?).

Bis auf Punkt -1- war also Leerlauf angesagt. Das System bootete trotz Änderung von Punkt -1-
völlig normal, Syskey war aktiv und fragte nach dem Start-Passwort. Das hat jedoch auch der
Verfasser der FAQ vorher schon erwähnt:
"But removing this key (or setting it to 0) isn't enough to disable
syskey. There's more.."

Also nochmals: Bestimmt lässt sich dieser Schutz umgehen und echte Reverser
können ihn aushebeln,
vielleicht gibt es auch ein spezielles Tool dafür, aber ich denke, dass man die
Sicherheit eines Hosts
doch etwas erhöhen kann. Zumindest diesen (manchmal) skeptisch zu beurteilenden Anfragen von
"Hab-mein-Admin-Passwort-vergessen" Postern, die dann das Kennwort mittels den 'üblichen Verdächtigen'
zurücksetzen um (manchmal) unberechtigterweise Vollzugriff zu erlangen, kann das Leben erschwert werden
Und um genau diese Zielgruppe geht's Ich frage mich aber dennoch, wie man sein Passwort vergessen
kann. Wenn sich einer auf NTFS Basis ausperren würde, könnte ich das eher nachvollziehen als ein vergessenes
Passwort für den Admin Account.

Bye

#5 und was ist mit dem viel besprochenen direkt-zugang zum system, was das booten von anderem medien impliziert?

aber dazu gab´s ja schon genügend threads...

greez

#6 Also der NT-Password Changer sollte Syskey auch von sich aus deaktivieren können. Das beschriebene Vorgehen sollte eigentlich nicht manuell nötig sein und ist wahrscheinlich auch veraltet.

Hab´s bisher noch nicht ausprobiert weil es mir wie gesagt zu riskant war aber den Menüpunkt gibt es definitiv.

Naja das mit dem Direktzugang ist so eine Sache. Ich glaube hier in dem Fall geht es mehr um die Situation das ein User an seinem Arbeitsplatzrechner nicht mit 2-3 Handgriffen sein Admin-Pass reseten kann um damit irgendwelchen Unsinn anzustellen.
__________
Bitte keine Anfragen per PM, diese werden nicht beantwortet.

#7 >asdrubael:
>Das beschriebene Vorgehen sollte eigentlich nicht manuell nötig sein und ist >wahrscheinlich auch veraltet.

Stimmt! Automatisch is' echt besser als manuell...

Also, ich habe mir die Freeware vorhin besorgt (bd030426.bin) und angetestet. Da ich ja noch ein aktuelles
Image hatte, konnte es auch sofort losgehen: NT-PW Changer gebootet,Syskey disabled und der Aufforderung nachgekommen,
zumindest dem Admin Account danach ein neues Kennwort zu verpassen. Klappte auch alles problemlos.
Die Warnungen des Autors, ein im Nachhinein deaktiviertes Syskey könne verschiedenartige Probleme nach
sich ziehen, wurde logischerweise ignoriert.

Erster Warmstart:
Artig wartend auf den ersten Crash verfolgte ich den Bootvorgang. Zu meiner Überraschung verlief alles glatt
und zu meiner noch grösseren Überraschung meldete sich Syskey und verlangte die Eingabe des Start-Passworts!
Ungläubig tippte ich dieses ein und wurde zum Login Screen weitergeleitet. Dort konnte ich mich ebenfalls
ohne Probleme anmelden und fand mich dann auf dem Desktop wieder. Bis hierhin gab's also keine Probs.
CMD ausgeführt, Syskey eingegeben und...zack! Meldung von 2000 erschien, die mir mitteilte, dass irgendwelche
Einstellungen geändert wurden und das nun eine Aktualisierung stattfindet! Ich habe leider den genaue Wortlaut
dieses Hinweises nicht mehr im Kopf und hatte ihn leider auch nicht notiert oder einen Shot des Fensters
vollzogen
Egal, was mir außerdem sofort ins Auge sprang, war die markierte Option "Verschlüsselung deaktiviert"
innerhalb von Syskey! Also hat der NT-Passwort Changer ganze Arbeit geleistet. Da mir Windows gerade berichtete,
"eine Aktualisierung sei vorgenommen worden", dachte ich mir, dass nach einem weiteren Boot die
Abfrage nach dem Start-Passwort nicht mehr erscheinen sollte...

Zweiter Warmstart:
Treffer...Versenkt! Bootvorgang rödelte nonstop durch bis zum bekannten W2K Login!

Danach wollte ich sofort dieses Posting ins Board schreiben, konnte mich aber nicht ins Internet verbinden!
"Gespeichertes Kennwort kann nicht gelöscht werden. Fehler 1305: Die Revisionsstufe ist nicht bekannt"
erschien beim Aufruf der DFÜ-Verbindung (RAS PPPoE). Tatsächlich war das Kennwort für den DSL-Zugang
im entsprechenden Feld nicht mehr vorhanden. Aber auch durch Eingabe des richtigen Kennwortes war ich
nicht in der Lage, mich ins WAN zu verbinden (Fehler: s.o.). Jetzt wußte ich, was der Autor mit "unvorhersehbaren
Problemen" meint. Also wieder das Image zurückkopiert und den Ursprungszustand wiederhergestellt.

Das Programm kann also definitiv Syskey disablen. Allerdings zahlt man auch einen Preis dafür. Welche Früh- oder
Spätfolgen ein so manipuliertes OS noch an den Tag legt, bliebe abzuwarten.

Egal, das war's auf jeden Fall wert. Das Programm ist mindestens(!) eine Alternative zu den bereits er-
wähnten "Commandern"! Dazu noch Freeware.

@Emba:
Klar, dagegen ist Syskey machtlos. Aber wie gesagt, es ging eigentlich nur um eine zusätzliche Sicherung des
Systems mit Windows Boardmitteln.

Anm.:
Irgendwie ist der Threat "komisch verlaufen". Da propagiere ich Syskey um später detailiert zu beschreiben,
wie ich es mit asdrubael's Tipp entfernen kann. *rofl*
Glücklicherweise ist die Entfernung ja mit einem zumindest leicht korruptem System verbunden *eg*

Bye