En el artículo anterior, dijimos que una de las formas de defenderse contra utilidades similares a mimikatz es deshabilitar el privilegio de depuración para los administradores del sistema que utilizan la política del programa de depuración. Sin embargo, recientemente resultó que sin el privilegio de depuración (es SeDebugPrivilege en Windows), un administrador del servidor local no puede instalar o actualizar Microsoft SQL Server. El asunto es que cuando se inicia, el instalador de SQL Server comprueba si existen los privilegios SeSecurity, SeBackup y SeDebug. Necesita ejecutar el proceso de SQL Server y obtener la información sobre el inicio exitoso de SQL Server. Así es como se ve.
Durante la instalación de SQL Server, el instalador realiza comprobaciones preliminares e identifica algunos problemas con Configurar privilegios de cuenta.
Si hace clic en el enlace Fallido, puede ver el siguiente mensaje:
La regla "Configurar privilegios de cuenta" falló.
La cuenta que ejecuta el programa de instalación de SQL Server no tiene uno o todos los siguientes derechos: el derecho a realizar copias de seguridad de archivos y directorios, el derecho a administrar la auditoría y el registro de seguridad y el derecho a depurar programas. Para continuar, use una cuenta con ambos derechos. Para obtener más información, consulte https://msdn.microsoft.com/en-us/library/ms813696.aspx, https://msdn.microsoft.com/en-us/library/ms813959.aspx y https: // msdn .microsoft.com / en-us / library / ms813847.aspx.
Ahora abre el SystemConfigurationCheck_Report.htm informe.
Como puede ver, al comprobar el HasSecurityBackupAndDebugPrivilegesCheck regla, el instalador ha descubierto que el proceso actual no tiene uno de los siguientes privilegios:
- SeSecurity: gestión de los registros de auditoría y seguridad
- SeBackup: los permisos para realizar copias de seguridad de archivos y carpetas
- SeDebug: el privilegio de depurar programas
Hay información detallada en el registro que muestra que el proceso de instalación no tiene el indicador SeDebug.
(09) 2017-12-12 11:15:13 Slp: Initializing rule : Setup account privileges (09) 2017-12-12 11:15:13 Slp: Rule is will be executed : True (09) 2017-12-12 11:15:13 Slp: Init rule target object: Microsoft.SqlServer.Configuration.SetupExtension.FacetPrivilegeCheck (09) 2017-12-12 11:15:13 Slp: Rule ‘HasSecurityBackupAndDebugPrivilegesCheck’ Result: Running process has SeSecurity privilege, has SeBackup privilege and does not have SeDebug privilege. (09) 2017-12-12 11:15:13 Slp: Evaluating rule : HasSecurityBackupAndDebugPrivilegesCheck (09) 2017-12-12 11:15:13 Slp: Rule running on machine: rom-sql10 (09) 2017-12-12 11:15:13 Slp: Rule evaluation done : Failed
He decidido buscar una solución alternativa para obtener SeDebugPrivilege sin cambiar o deshabilitar la política de programas de depuración. Resultó que hay una manera bastante fácil de eludir esta política si tiene privilegios de administrador local en su servidor. La secedit Nos ayudará una herramienta que permita gestionar las políticas de seguridad locales del servidor.
Verifique los privilegios actuales:
whoami /priv
Como puede ver, no hay SeDebugPrivilege en el token actual del usuario.
Exporte los derechos de usuario actuales establecidos por las políticas de grupo a un archivo de texto:
secedit /export /cfg secpolicy.inf /areas USER_RIGHTS
Con cualquier editor de texto, abra secpolicy.inf y agregue una cuerda al [Privilege Rights] sección que habilita los privilegios de los programas de depuración al grupo de administradores locales.
SeDebugPrivilege = *S-1-5-32-544
Guarda el archivo. Ahora aplique los nuevos derechos de usuario:
secedit /configure /db secedit.sdb /cfg secpolicy.inf /overwrite /areas USER_RIGHTS
Nota. Debe confirmar la sobrescritura de la configuración actual.
Cierre la sesión y vuelva a iniciarla y, utilizando secpol.msc, asegúrese de que los privilegios del programa de depuración estén asignados al grupo de administradores locales. Lo mismo se muestra en los resultados del comando whoami / priv:
SeDebugPrivilege Debug programs Enabled
Ahora puede ejecutar la instalación o actualizar su servidor SQL. Pero tenga en cuenta que SeDebugPrivilege se asigna temporalmente y se restablecerá en el próximo ciclo de actualización de GPO (después de que el usuario haya cerrado la sesión).
Debe comprender que si habilita la política de programas de depuración, no lo protegerá completamente de obtener SeDebugPrivilege por parte de software malicioso que ya ha penetrado en su servidor con derechos de administrador local, y puede comprometer todas las cuentas de usuario / administrador que trabajan en el servidor.