В предыдущей статье мы рассказывали, что одной из техник защиты от извлечения паролей из памяти Windows mimikatz-like утилитами является запрет получения debug-привилегии для администраторов системы с помощью групповой политики Debug Program. Однако недавно обнаружилось, что без прав отладки (в Windows это привилегия SeDebugPrivilege), локальный администратор сервера не может установить или обновлять Microsoft SQL Server. Дело в том, что установщик SQL Server при запуске проверяет наличие привилегий SeSecurity. SeBackup и SeDebug, которые нужны ему для запуска процесса SQL Server и получения информации об успешном запуске SQL Server. Вот как это выглядит.
Во время установки SQL Server при выполнении предварительных проверок установщик спотыкается на проверке Setup account privileges.
Щелкнув по ссылке “Failed”, можно увидеть такое сообщение:
The account that is running SQL Server Setup does not have one or all of the following rights: the right to back up files and directories, the right to manage auditing and the security log and the right to debug programs. To continue, use an account with both of these rights. For more information, see https://msdn.microsoft.com/en-us/library/ms813696.aspx, https://msdn.microsoft.com/en-us/library/ms813959.aspx and https://msdn.microsoft.com/en-us/library/ms813847.aspx.
Откроем теперь отчет установки SystemConfigurationCheck_Report.htm.
Как вы видите, установщик при проверке правила HasSecurityBackupAndDebugPrivilegesCheck установил, что у текущего процесса отсутствует одна из следующих привилегий:
- SeSecurity – управление журналами аудита и безопасности
- SeBackup – права на резервное копирование файлов и каталогов
- SeDebug — право отладки программ
В логе есть более детальная информация, указывающая, что у процесса установки отсутствует флаг SeDebug:
(09) 2017-09-12 14:25:13 Slp: Initializing rule : Setup account privileges
(09) 2017-09-12 14:25:13 Slp: Rule is will be executed : True
(09) 2017-09-12 14:25:13 Slp: Init rule target object: Microsoft.SqlServer.Configuration.SetupExtension.FacetPrivilegeCheck
(09) 2017-09-12 14:25:13 Slp: Rule ‘HasSecurityBackupAndDebugPrivilegesCheck’ Result: Running process has SeSecurity privilege, has SeBackup privilege and does not have SeDebug privilege.
(09) 2017-09-12 14:25:13 Slp: Evaluating rule : HasSecurityBackupAndDebugPrivilegesCheck
(09) 2017-09-12 14:25:13 Slp: Rule running on machine: msk-sql10
(09) 2017-09-12 14:25:13 Slp: Rule evaluation done : Failed
Я решил поискать обходной путь получения прав SeDebugPrivilege без изменения или отключения политики Debug programs. И как оказалось, имеется довольно простой способ обхода этой политики при наличии прав локального администратора на сервере. В этом нам поможет утилита secedit, позволяющая управлять локальными политиками безопасности сервера.
Проверяем текущие привилегии:
whoami /priv
Как вы видите, сейчас в текущем токене пользователя отсутствует привилегия SeDebugPrivilege .
Экспортируем текущие права пользователей, настроенные групповыми политиками в текстовый файл:
secedit /export /cfg secpolicy.inf /areas USER_RIGHTS
Теперь с помощью любого тестового редактора нужно открыть на редактирование файл secpolicy.inf и в секцию [Privilege Rights] добавить строку, предоставляющую права Debug Programs группе локальных администраторов.
SeDebugPrivilege = *S-1-5-32-544
Сохраните файл. Теперь нужно применить новые пользовательские права:
secedit /configure /db secedit.sdb /cfg secpolicy.inf /overwrite /areas USER_RIGHTS
Теперь нужно выполнить логофф/логон и с помощью secpol.msc убедиться, что для группы локальных администраторов назначены права Debug Program. Это же подтверждает команда whoami /priv:
SeDebugPrivilege Debug programs Enabled
Теперь можно запускать установку/обновлений SQL Server. Но стоит иметь в виду, что привилегия SeDebugPrivilege в данном случается назначается лишь временно и они будут сброшены при следующем обновлении групповых политик (но уже после logoff пользователя).
Как вы понимаете, включение запретительной политики Debug programs не является панацей от получения права SeDebugPrivilege вредоносными программами, которые уже проникли на сервер с правами локального администратора, что может скомпрометировать все учетные записи пользователей/администраторов, работящих на сервере.
Спасибо за статью!
Есть еще один способ получения SeDebugPrivilege: нужна утилита ntrights из Windows Server 2003 Resource Kit Tools. Привелегия пользователю назначается всего одной командой:
ntrights.exe +r SeDebugPrivilege -u contoso\username
…Что лишний раз доказывает, что если скомпрометирована учётка с админскими правами, то дальнейшее сопротивление бессмысленно. Поэтому кстати MS и не фиксит уязвимости для эксплуатации которых нужны администраторские привилегии — не считает это за уязвимости.
Спасибо за статью!
Помогли разобраться, 2 дня мучился, как обойти!
От души целую вашу SeDebugPrivilege = *S-1-5-32-544!
А теперь расскажи, как доменным администраторам управлять пользователями и подключениями без этих прав.
А в чём собственно проблема? Не сталкивался с проблемами управления пользователями без этих прав.
Работает ли способ? Пробовал на нескольких компах с win10 — после logoff\logon права не появляются..