Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
|
Почти по теме: а разве SysKey можно отключить? 04.11.02 21:45 Число просмотров: 2028
Автор: HandleX <Александр М.> Статус: The Elderman
|
|
|
|
<hacking>
|
Структура V-блока 04.11.02 14:42
Автор: amirul <Serge> Статус: The Elderman
|
Если убить syskey (не отключить, а убить сам ключ). В реестре он хранится в HKEY_LOCAL_MACHINE\SAM\SAM\Domains\Account\F, то на вход пользователей с пустыми паролями это не влияет (а на остальных еще как).
В связи с этим вопрос: как отключить пароль админу не снимая сискей, если есть доступ на запись в sam.
Известно, в V-блоке HKEY_LOCAL_MACHINE\SAM\SAM\Domains\Account\Users\000001F4 по смещению 9c хранится смещение (относительно конца заголовка V-блока, то бишь 0xcc от начала) хешей паролей (сначала LM, потом NT), зашифрованные DES-ом ключами получаемыми из RID-а (1F4 для админа). Но это без syskey.
У кого есть инфа о структуре HKLM\SAM\SAM\Domains\Account\F или/и V-блока для аккаунта в SAM или/и вообще по работе syskey - пишите
|
|
Почти по теме: а разве SysKey можно отключить? 04.11.02 21:45
Автор: HandleX <Александр М.> Статус: The Elderman
|
|
|
| |
Кратий ответ: нельзя. Но если очень хочется... 05.11.02 16:01
Автор: amirul <Serge> Статус: The Elderman
|
http://uinc.ru/articles/29/index.shtml :
===== Начало цитаты =====
Вообще считается (так и сообщается переходом на ее использование, а также по официальным заявлениям Microsoft), что отменить использование утилиты syskey нельзя. На самом деле отключить ее можно (правда не совсем корректно), изменив следующие ключи реестра:
HKLM\SAM\Domains\Account\F
необходимо обнулить содержимое этого ключа. Эта структура хранит SID компьютера, а также другую системную информацию. Здесь же хранится копия статуса ключа SecureBoot.
HKLM\System\CurrentControlSet\Control\Lsa\SecureBoot
необходимо также присвоить значение 0. Этот ключ хранит режим syskey:
1 - ключ в реестре
2 - ключ вводится пользователем
3 - ключ на дискете
Обнуление этих двух ключей отключает syskey для системы Windows NT 4.0. Для Windows 2000 нужно поправить еще один ключ:
HKLM\security\Policy\PolSecretEncryptionKey\
здесь хранится еще одна копия режима работы syskey.
===== Конец цитаты =====
Хотя, надо признаться, прогнал я. Я менял ключ прямо в винде. И сделал контрольный логин. А lsass взял да и восстановил ключик.
Кроме того. Если пытаться отключить syskey с линуховской дискеты (http://home.eunet.no/~pnordahl/ntpasswd/bootdisk.html), то XP-ха восстанавливает один из ключей при загрузке (а может и все - не проверял), что приводит к тому, что измененный хэш пароля оказывается инвалидным. Еще вопрос: где еще она хранит состояние syskey-я?
|
| | |
Если дело только в реестре, то можно попробовать включить SysKey на NT4 с включенным RegMon ;-) 06.11.02 05:46
Автор: HandleX <Александр М.> Статус: The Elderman
|
|
|
| | | |
Я уже понял, что это безыдейно, но просто интересно 06.11.02 15:42
Автор: amirul <Serge> Статус: The Elderman
|
Самое интересное, что если консоль получена без логина, то даже SYSTEM не может ничего сделать с юзерами на компе.
Например так:
HKEY_USERS\.DEFAULT\Control Panel\Desktop\SCRNSAVE.EXE -> cmd.exe
Logoff и дождаться консоли, после этого на
net user administrator password
следует
System error 5: Access denied
Причем с разрешениями это не связано: если получить SYSTEM с помощью debploit или getad, то все прокатывает. Также это не связано с restricted desktop-ами, т.к. если на том же desktop-е создать консоль другого пользователя, он может все делать:
runas /user:administrator cmd.exe
и из новой консоли
net user что_угодно
Какое то время я пытался с этим всем раздуплиться. Но щас бросил
|
|
|
подробно о проекте
Анализ криптографических сетевых...
