Почему не стоит задавать пароли через Group Policy Preferences

Предпочтения групповых политик (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):

Зашифрованный пароль содержится в значении поля CPASSWORD. Самое интересное заключается в том, что Microsoft сама на MSDN выложила в паблик 32 битный AES ключ, используемый для шифрования пароля (http://msdn.microsoft.com/en-us/library/2c15cbf0-f086-4c74-8b70-1f2fa45dd4be.aspx#endNote2 )

Соответственно, специалисту ничего не мешает написать скрипт, позволяющий расшифровать значение пароля, хранящегося в XML файле (алгоритм AES симметричный и при наличии ключа шифрования без труда позволяет получить исходный текст).

В Windows Server 2012 / Windows Server 2012 R2 разработчики Microsft добавили предупреждение о небезопасности хранения паролей в таком виде. При попытке указать пароль через GPP появляется предупреждающее окно:

Также важно отметить тот файкт, что в MetaSploit-е модуль получения и расшифровки паролей, хранящихся в GPP присутствует еще с 2012 года. Это означает, что злоумышленники практически в автоматическом режиме могут реализовать это вектор атаки.

Ну что, вы и в дальнейшем планируете использовать Group Policy Preferences для управления паролями?