Взлом паролей, сохранённых в Group Policy Preferences.

Много раз уже писалось, что задавать пароли через Group Policy Preferences небезопасно, так как они хоть и сохраняются в зашифрованном виде, но ключ шифрования всем известен. Интересно, что в Windows Server 2012 редактор групповых политик даже предупреждение выдаёт соответствующее:

GPP-Warning

Но так ли просто достать пароль из политик? Думаю, лучше один раз увидеть, чем сто раз услышать.

Процедура исполняется в четыре простых шага:
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-файлы;

XML

2. Если контроллер домена недоступен (например, в сценарии с загрузкой с flash-диска), можно поискать xml-файлы в локальном кэше политик, который находится в папке %AllUsersProfile%\Microsoft\GroupPolicy\History.

PolicyCache

Шаг третий — значение 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 в комментариях. Время расшифровки — менее секунды.

GetPWD

На практике у меня все четыре шага получилось реализовать примерно за пять минут, после чего из рядового пользователя я стал доменным администратором. Стоит ли бояться применять пароли в Group Policy Preferences? Наверное, стоит обдумать внимательнее, всегда ли нужно реализовывать управление именно таким путём.

Advertisements

4 Responses to Взлом паролей, сохранённых в Group Policy Preferences.

  1. Vasiliy says:

    А как вы предлагаете централизованно менять пароли в крупных компаниях ? Если пароль локал администратора был скомпрометирован. Или просто отключаете локал админов ?

    • Dear Vasiliy,
      А нет у меня предложений, ощем-то. Дело в том, что методов компрометации локального администратора — масса, а через с помощью, например, mimikatz добыть доменного админа — минутное дело.. Отключаем локальных, короче.

  2. a says:

    Есть ряд способов смены паролей. Оба описаны Microsoftом

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s

%d такие блоггеры, как: