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.
