Взлом паролей, сохранённых в Group Policy Preferences.
Понедельник, 02 - Сентябрь - 2013 4 комментария
Много раз уже писалось, что задавать пароли через Group Policy Preferences небезопасно, так как они хоть и сохраняются в зашифрованном виде, но ключ шифрования всем известен. Интересно, что в Windows Server 2012 редактор групповых политик даже предупреждение выдаёт соответствующее:
Но так ли просто достать пароль из политик? Думаю, лучше один раз увидеть, чем сто раз услышать.
Процедура исполняется в четыре простых шага:
1. Получение доступа любого уровня к одной из рабочих станций;
2. Получение xml-файла групповой политики;
3. Получение значения cpassword из xml-файла;
4. Расшифровка пароля.
Шаг первый обычно либо уже исполнен, либо исполнить его совершенно несложно. Возможные сценарии:
1. Рабочая станция сконфигурирована на автоматический вход с некоей учётной записью. В этом случае, злоумышленник получает неидентифицируемый доступ к системе без каких-либо усилий вообще, достаточно просто подойти к компьютеру. Кстати, узнать имя и пароль автоматического пользователя также несложно, они записаны открытым текстом в ключе реестра HKLM\Software\Microsoft\Windows NT\CurrentVersion\WinLogon, значения DefaultUserName и DefaultPassword;
2. Злоумышленник может воспользоваться незаблокированной сессией другого пользователя. Ненадолго оставляющие своё рабочее место сотрудники обычно его не блокируют: «это же быстро», «тут все свои», «у меня ничего ценного нет».
2. Неограниченный физический доступ позволяет стороннему лицу выключить компьютер, загрузить свою операционную систему с компакт-диска или flash-носителя, чтобы затем скопировать или подменить нужные файлы. Как я убедился, подобными умениями обладает едва ли не каждый второй;
3. Злоумышленником является один из уже допущенных к системе пользователей. Многие люди не понимают, что инсайдер — явление настолько типичное, что встречается практически везде. Это вполне может быть человек, который сидит рядом с тобой и улыбается тебе по утрам. Но он же не расскажет тебе суть своих делишек, он в этом не заинтересован.
4. Удалённый доступ через различного рода троянские и шпионские программы. Это может быть исполнение кода через дыры в Java/Flash, заражения при скачивании «полезных и нужных» утилит, либо даже социальная инженерия.
Шаг второй также исполняется довольно быстро:
1. Чтобы найти нужный файл на контроллере домена, достаточно открыть путь \\%UserDNSDomain%\SysVol и выполнить поиск xml-файла, содержащего строку «cpassword=». Следует отметить, что поиск по содержимому файла в Windows 7 практически неработоспособен (например, http://answers.microsoft.com/en-us/windows/forum/windows_7-files/in-windows-7-i-want-to-search-for-all-files/aadfe1f1-4a33-406b-8e72-bb920efa4f30), поэтому можно либо воспользоваться альтернативным файл-менеджером, если таковой установлен на компьютере, либо забрать все потенциально интересные xml-файлы;
2. Если контроллер домена недоступен (например, в сценарии с загрузкой с flash-диска), можно поискать xml-файлы в локальном кэше политик, который находится в папке %AllUsersProfile%\Microsoft\GroupPolicy\History.
Шаг третий — значение cpassword. Именно в нём хранится зашифрованный заведомо известным симметричным ключом пароль. Значение можно скопировать как просто текст, кавычки не нужны. Пароли могут задаваться в разных файлах, предназначенных для разных сценариев:
- Groups.xml — создание локальных учётных записей и управление ими. Например, замена пароля администратора;
- Services.xml — создание и конфигурация служб. Например, запуск службы от лица отдельной учётной записи (как правило, администратора);
- ScheduledTasks.xml — создание и конфигурация задач планировщика. Например, исполнение скрипта от лица отдельной учётной записи (как правило, администратора);
- Drives.xml — подключение сетевых дисков с альтернативными реквизитами (зачастую, от лица администратора);
- DataSources.xml — управление источниками данных ODBC.
Шаг четвёртый — расшифровка. Чтобы не мучаться с калькулятором в руках, можно применить готовый PowerShell-скрипт. Хороший пример можно найти здесь — http://obscuresecurity.blogspot.com/2012/05/gpp-password-retrieval-with-powershell.html, функция GetPwd в комментариях. Время расшифровки — менее секунды.
На практике у меня все четыре шага получилось реализовать примерно за пять минут, после чего из рядового пользователя я стал доменным администратором. Стоит ли бояться применять пароли в Group Policy Preferences? Наверное, стоит обдумать внимательнее, всегда ли нужно реализовывать управление именно таким путём.
А как вы предлагаете централизованно менять пароли в крупных компаниях ? Если пароль локал администратора был скомпрометирован. Или просто отключаете локал админов ?
Dear Vasiliy,
А нет у меня предложений, ощем-то. Дело в том, что методов компрометации локального администратора — масса, а через с помощью, например, mimikatz добыть доменного админа — минутное дело.. Отключаем локальных, короче.
Есть ряд способов смены паролей. Оба описаны Microsoftом
Сказав «А», надо бы сказать и «Б». Какие способы?