Что происходит при установке syskey и как от него избавиться

Посетите сайт Петтера, чтобы найти исходную версию и обновления: The Offline NT Password Editor.

(c) 1997-2001 Петтер Нордаль-Хаген
 Обновление: 01 апреля 2000 г.
 Что происходит при установке syskey и как от него избавиться
 —————————————————————
 Фон:
 ————
 Syskey был добавлен в NT вместе с Service Pack 3, чтобы предотвратить легкое
 доступ к фактическим хэшам паролей в SAM (менеджер учетных записей безопасности)
 Оригинальные методы создания и хранения хэшей делают его
 довольно легко взломать или атаковать по словарю, чтобы найти открытый текст
 пароли. (в основном вызвано несколько ошибочной реализацией и использованием
 задействованных криптоалгоритмов, но это обсуждается в другом месте)
 Включение syskey необязательно, администратор должен запустить syskey.exe и
 ответьте на некоторые диалоговые окна, чтобы включить его. В Windows 2000 это необязательно
 больше, он включен по умолчанию во время установки.
 Когда системный ключ активен, хэши еще зашифрованы/обфусцированы.
 в другой раз перед сохранением в реестре SAM.
 Однако после загрузки они сохраняются в памяти в старом виде.
 (pwdump2 демонстрирует это),
 так как старая форма нужна для аутентификации NTLM в сети и т.д.
 Ключ который обфусцирует хэши, точнее на что то похоже
 который расшифровывает ключ, может храниться на гибком диске, сгенерированном из
 парольная фраза, которая будет введена при загрузке или сохранена (снова запутанная) в
 реестр.
 Нет официального поддерживаемого метода отключения системного ключа.
 после активации, за исключением восстановления реестра с аварийной дискеты
 сделано до активации syskey.
 Итак... какое отношение это имеет к моей утилите?
 ———————————————
 Моя утилита не пытается взломать пароли, она закладывает новые хэши в
 SAM, тем самым изменив пароль пользователя. И делает это офлайн.
 Syskey был лучшим примером для этого.
 Насколько я вижу, есть 2 способа решить эту проблему:
 1) Найдите ключ в реестре, попросите пользователя ввести его или получите дискету
 затем используйте системный ключ и для нового пароля. Однако это не задокументировано
 и я нигде не нашел реверс-инжиниринга.
 2) Попробуйте отключить. У этого есть один недостаток и одна хорошая сторона:
 Плохо: все пароли необходимо сбросить, так как старые хэши будут недействительны.
 VeryBAD: ВЫКЛЮЧЕНИЕ В WINDOWS 2000 НЕ ИДЕАЛЬНО,
 ВЫЗЫВАЕТ ПРОБЛЕМЫ, но вы можете получить доступ к компьютеру
 после. Отношения домена и системный ключ могут быть
 невозможно изменить после этого, требуется переустановка
 (или, возможно, только обновление)
 Хорошо: ключ не нужен (можно потерять).
 3) (NEW 2000-04-01, нет, не шутка) Вставить старые стили паролей-хешей
 в SAM, будут преобразованы в системные хэши при следующей загрузке.
 Вот как syskey включается на NT4, хэши не трогаются
 до первой перезагрузки после включения syskey.
 Я узнал, как сделать # 2 и # 3.
 Что происходит при включении syskey и как его снова выключить:
 ——————————————————————
 – 1 –
 Несколько новых ключей добавлены в HKLMSystemCurrentControlSetControlLsa,
 кажется, что большая часть ключей/значений используется для обфускации ключа
 они меняются при обновлении системного ключа.
 Однако значение с именем «SecureBoot» содержит режим системного ключа:
 1 – Ключ в реестре
 2 — введите парольную фразу
 3 – ключ на дискете
 Но удаления этого ключа (или установки его на 0) недостаточно, чтобы отключить
 системный ключ. Есть больше..
 – 2 –
 HKLMSAMDomainsAccountF — это двоичная структура, обычно содержащая имя компьютера.
 SID и некоторые другие вещи, связанные с этим.
 Когда syskey установлен, он расширяется (примерно в два раза больше) чем-то
 Я предполагаю, что ключ сильно зашифрован + некоторые флаги и другие значения.
 Один из этих других флагов/значений также содержит тот же режим, что и SecureBoot выше.
 Итак... сброс этого флага режима и SecureBoot до 0 - это все, что нужно
 отключить системный ключ в NT4 (до SP6 на момент написания). Изменение только одного из них
 приводит к предупреждению о несоответствии между SAM и системными настройками
 после завершения загрузки и повторно вызывается syskey.
 – 3 –
 В Windows 2000 есть еще одно место, где хранится информация о системном ключе:
 HKLMsecurityPolicyPolSecretEncryptionKey
 который тоже является бинарной структурой, но и там хранится режим.
 Сбросьте это значение до 0, и системный ключ исчезнет на win2k.
 (если есть несоответствие между тремя, он молча сбрасывает их
 до наиболее вероятного значения при загрузке)
 – 4 –
 Тогда есть хэши паролей.
 Обычная (старая) длина хеша составляет 16 байт, но все хэши расширяются до 20 байт.
 с syskey первые 4 байта выглядят как какой-то счетчик. (может быть
 счетчик истории?).
 Странно, они не обновляются сразу при включении syskey,
 обновление хэшей происходит во время следующей перезагрузки после включения системного ключа.
 А при последующем обновлении ключа хэши тоже обновляются?
 НЕТ!! Странно, КАЖЕТСЯ, что хэши паролей ОСТАЮТСЯ ТАКИМИ ЖЕ!
 (однако двоичные файлы в 3 ключах, отмеченных выше, меняются..)
 Я постараюсь копнуть больше в этом. Требуется помощь ?
 Когда syskey отключен, все пароли должны быть сброшены.
 Моя утилита будет записывать и корректировать длины хэшей пользователей (обычно
 администратор), для которого вы сбросили пароль.
 NT сама исправит остальные хеши при установке новых паролей
 из НТ.
 И да, можно снова включить syskey после его отключения.
 (пока не на win2k!)
 Итак, кто-нибудь реверс-инжиниринг всей системы syskeystuff?
 (да, я знаю, что-то в пути..)