Windows cached logons
Mar. 8th, 2012 09:29 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
leo_sosnineПо-умолчанию практически любая винда (от NT4 до 2008) кэширует 10 последних логонов/паролей.
Несмотря на зашкаливающую в других аспектах паранойю по безопасности, в этом случае Майкрософт угождает пользователям: если домен недоступен, то юзер тем не менее может залогониться, если этот юзер за этой машиной хотя бы раз логонился, и после этого события логонилось не более 9 других юзеров, то система юзера впустит.
Хэши логон неймов/паролей хранятся в файлике %windir%\system32\config\security, который подгружается, ктстаи, как ветка реестра, но доступен только для NT Authority\SYSTEM, он же COMPUTERNAME$.
И, соответственно, обладая правами локального админа на этой машинке, эти хэши нетрудно слить, а дома, в спокойной обстановке, подобрать их на видюхе, ну или зааутсорсить подбор.
Чем это плохо для админа: как правило любая машинка в домене имеет в своём кэше логон юзера, который за ней сидит постоянно, и логоны админов и суппортов, которые логонились на этой машинке для решения задач по поддержке.
Таким образом, задача получения шпиёном пароля доменного админа сводится к следующему нехитрому алгоритму:
1) Устроиться на работу к конкуренту, получить в управление комп;
2) Пароль доменного админа в кэше наверняка уже есть, но если нужно обеспечить его гарантированное наличие, то всё что нужно это создать ситуацию, которая потребует от админа залогониться за выданным компом;
3) Сбросить пароль локального админа, загрузиться под ним (для этого потребуется загрузиться с сидюка или флэшки);
4) Утянуть MSCache соотв. утилитками;
5) Дома спокойно подобрать админский пароль.
А дальше заходи кто хочешь и бери что хочешь. Например, если в конторе есть терминальные серверы, светящие наружу для удалённых сотрудников, то заходим туда и спокойно утягиваем всё что нужно с административными правами. Ну или делаем формат цэ, включая сервер бэкапов, хыхы.
Теперь как с этим бороться.
1) Создаём отдельную группу с учётками, для которых требуются административные права на локальных машинах. Как правило это служба хэлпдеска. Через рестриктед гроупс заносим только что созданную группу в локальные администраторы и подписываем у шефа служебку, обязующую всех сотрудников службы ИТ ходить по локальным машинам только по учёткам из этой группы, которые не имеют админских прав на домен. По-крайней мере, так мы спасём доменного админа.
2) Групповыми политиками ограничиваем количество кэшируемых логонов на машинках домена единичкой. Это приведёт к тому, что после логона на локальной машине админа для выполнения административных задач, залогонится юзер и его кэш затрёт админский кэш, поэтому максимум, что юзер сможет унести, так это свой собственный кэш, хехе. Тут важно соблюдать процедуру -- всегда после административной работы заставлять юзера залогониться.
Ну и полные параноики могут вообще установить количество кэшируемых логонов в 0.
Несмотря на зашкаливающую в других аспектах паранойю по безопасности, в этом случае Майкрософт угождает пользователям: если домен недоступен, то юзер тем не менее может залогониться, если этот юзер за этой машиной хотя бы раз логонился, и после этого события логонилось не более 9 других юзеров, то система юзера впустит.
Хэши логон неймов/паролей хранятся в файлике %windir%\system32\config\security, который подгружается, ктстаи, как ветка реестра, но доступен только для NT Authority\SYSTEM, он же COMPUTERNAME$.
И, соответственно, обладая правами локального админа на этой машинке, эти хэши нетрудно слить, а дома, в спокойной обстановке, подобрать их на видюхе, ну или зааутсорсить подбор.
Чем это плохо для админа: как правило любая машинка в домене имеет в своём кэше логон юзера, который за ней сидит постоянно, и логоны админов и суппортов, которые логонились на этой машинке для решения задач по поддержке.
Таким образом, задача получения шпиёном пароля доменного админа сводится к следующему нехитрому алгоритму:
1) Устроиться на работу к конкуренту, получить в управление комп;
2) Пароль доменного админа в кэше наверняка уже есть, но если нужно обеспечить его гарантированное наличие, то всё что нужно это создать ситуацию, которая потребует от админа залогониться за выданным компом;
3) Сбросить пароль локального админа, загрузиться под ним (для этого потребуется загрузиться с сидюка или флэшки);
4) Утянуть MSCache соотв. утилитками;
5) Дома спокойно подобрать админский пароль.
А дальше заходи кто хочешь и бери что хочешь. Например, если в конторе есть терминальные серверы, светящие наружу для удалённых сотрудников, то заходим туда и спокойно утягиваем всё что нужно с административными правами. Ну или делаем формат цэ, включая сервер бэкапов, хыхы.
Теперь как с этим бороться.
1) Создаём отдельную группу с учётками, для которых требуются административные права на локальных машинах. Как правило это служба хэлпдеска. Через рестриктед гроупс заносим только что созданную группу в локальные администраторы и подписываем у шефа служебку, обязующую всех сотрудников службы ИТ ходить по локальным машинам только по учёткам из этой группы, которые не имеют админских прав на домен. По-крайней мере, так мы спасём доменного админа.
2) Групповыми политиками ограничиваем количество кэшируемых логонов на машинках домена единичкой. Это приведёт к тому, что после логона на локальной машине админа для выполнения административных задач, залогонится юзер и его кэш затрёт админский кэш, поэтому максимум, что юзер сможет унести, так это свой собственный кэш, хехе. Тут важно соблюдать процедуру -- всегда после административной работы заставлять юзера залогониться.
Ну и полные параноики могут вообще установить количество кэшируемых логонов в 0.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2012-03-08 05:56 pm (UTC)no subject
Date: 2012-03-08 06:55 pm (UTC)Это не решение, т.к. для юзеров будет непримемлемо иметь два профиля -- они будут в них путаться и так далее, придётся иметь две копии настроек для всего софта, для ИЕ и т.п.
Если же им всё время работать в локальном профиле и в домен не логониться -- то возникнет проблема отсутствия SSO, придётся для доступа к каждому доменному ресурсу вводить логин/пасс. Также с т.з. безопасности это решение будет дурацким, т.к. логин/пасс для аутентификации на ресурсах будет слаться в лучшем случае как NTLMv2, а не Керберос, а это, считай, то же самое, что открытым текстом пароль слать.
no subject
Date: 2012-03-08 07:12 pm (UTC)Это само по себе дырища в безопасности -- при утере ноута уйдет и кеш паролей. Даже устраиваться на работу к конкуренту не нужно - достаточно на подземной парковке (как вариант) стукнуть по голове любого сотрудника с ноутом.
Только локальные логины спасут сеть от утери ноутов. Или шифрование диска, но там возникают другие вопросы (пользователь должен помнить пароль и пароль должен быть стойким, что в случае с уходом ноута усложняет пароль до неудобоваримых длин).
no subject
Date: 2012-03-09 02:34 pm (UTC)Не совсем понял вопроса. Любой комп с виндой, обратившись, например, на к-л SMB-ресурс получит приглашение вести логин/пароль. Если ввести их правильно (или воспользоваться тулзами pass-the-hash) то на сервере, предоставляющем этот SMB-ресурс, Вы успешно аутентифицируетесь. Вне зависимости от того, введён в домен или нет комп с виндой, с которого делается попытка входа.
Можете прям щас просканировать сеть на открытые SMB-ресурсы и убедитесь, что их дохрена и больше. Ткнётесь -- запросит пароль. А некоторые так и вообще открыты всем без пароля. Иногда попадаются всякие папки с документами, базы 1С и так далее. :)
no subject
Date: 2012-03-09 03:17 pm (UTC)Но сама эта ситуация (ноут в поле с закешированными credentials) уже является небезопасной - до кеша добраться достаточно легко украв ноутбук (или позаимствовав его на небольшое время). Таким образом, кеш пароля всегда является "источником повышенной опасности" и его правильно вообще отключать.
no subject
Date: 2012-03-09 03:42 pm (UTC)no subject
Date: 2012-03-09 04:10 pm (UTC)no subject
Date: 2012-03-09 05:13 pm (UTC)Что делать с ноутбучниками, которые частично работают в офисе, частично дома (через ВПН), частично вообще в оффлайнах? Для них нужен кэш.
no subject
Date: 2012-03-09 05:31 pm (UTC)