Предпочтения групповых политик (GPP — Group Policy Preferences) – мощное расширение технологии групповых политик Windows, упрощающая работу по настройке и управлению парком компьютеров, и являющаяся своего рода заменой скриптам в GPO. Одной из возможностей GPP – возможность управления паролями локальных и сервисных учетных записей, широко используемая многими администраторами, которые даже не подозревают о небезопасности этой технологии. В этой статье мы поговорим, почему не стоит использовать возможности Group Policy Preferences по управлению паролями.
В Group Policy Preferences существуют 5 различных политик, позволяющих задать пароль пользователя/администратора.
- Локальные учетные записи (Local Users and Group) – с помощью GPP администратор может создать/изменить локальную учетную запись и задать ее пароль (достаточно часто эта политика используется для смены пароля локального администратора на всех ПК организации)
- Сетевые диски (Drive Maps) – GPP позволяют подключить (смапить) пользователю сетевой диск с определенным именем пользователя и паролем
- Источники данных (Data Sources) – при создании источника данных можно задать имя пользователя и пароль учетной записи, под которой будет выполняться подключение.
- Задания планировщика Windows (Scheduled Tasks) – задания планировщика можно запускать из-под определенного пользователя
- Службы (Services) – GPP позволяют указать учетную запись и ее пароль, из под которой будет запускаться конкретная служба (вместо ученой записи Local System)
После того, как администратор сохраняет пароль в любой из перечисленных выше политик GPP, он сохраняется в каталоге соответствующей GPO в специальном XML файле и дальнейшем храня на контроллерах домена в папке SYSVOL. Пароль в XML файле хранится в зашифрованном виде, однако для шифрования/расшифровки пароля используется крайне нестойкий симметричный алгоритм AES 32 (это отмечает даже сама Microsoft).
Допустим, администратор с помощью GPP настроил политику, меняющую пароль локального администратора на всех ПК. Система в этом случае сохранит зашифрованный пароль в каталоге GPO в файле groups.xml. Посмотрим на содержимое этого файла (файл в нашем примере хранится в каталоге \remontka.comSYSVOLremontka.comPolicies{POLICY_ID}MachinePreferencesGroups):
Важно . Доступ к файлам, хранящимся в GPO, имеют все авторизованные пользователи домена. Это означает, что в зашифрованном виде просмотреть пароль сможет любой пользователь.
Зашифрованный пароль содержится в значении поля CPASSWORD. Самое интересное заключается в том, что Microsoft сама на MSDN выложила в паблик 32 битный AES ключ, используемый для шифрования пароля (http://msdn.microsoft.com/en-us/library/2c15cbf0-f086-4c74-8b70-1f2fa45dd4be.aspx#endNote2 )
Соответственно, специалисту ничего не мешает написать скрипт, позволяющий расшифровать значение пароля, хранящегося в XML файле (алгоритм AES симметричный и при наличии ключа шифрования без труда позволяет получить исходный текст).
Примечание . Скрипт, позволяющий расшифровать пароль, хранящийся в GPP можно получить тут: Get-GPPPassword . Естественно, мы выкладываем этот скрипт в ознакомительными целями и не в коем случае не стоит его использовать в корыстных целях.
В Windows Server 2012 / Windows Server 2012 R2 разработчики Microsft добавили предупреждение о небезопасности хранения паролей в таком виде. При попытке указать пароль через GPP появляется предупреждающее окно:
This password is stored as part of the GPO in SYSOL and is discoverable, although obscured.
Также важно отметить тот файкт, что в MetaSploit-е модуль получения и расшифровки паролей, хранящихся в GPP присутствует еще с 2012 года. Это означает, что злоумышленники практически в автоматическом режиме могут реализовать это вектор атаки.
Ну что, вы и в дальнейшем планируете использовать Group Policy Preferences для управления паролями?
Совет . В качестве решения по управления паролями локальных администраторов Microsoft предлагает LAPS. Подробнее о нем в статье MS LAPS – управление паролями локальных администраторов в домене
