У попередній статті ми розповідали, що однією з технік захисту від вилучення паролів з пам'яті 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", можна побачити таке повідомлення:
Rule "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 шкідливими програмами, які вже проникли на сервер з правами локального адміністратора, що може скомпрометувати все облікові записи користувачів / адміністраторів, працьовитих на сервері.