SQL Server - Cómo Usar EXECUTE AS para Ejecutar Comandos como Otro Usuario (Impersonar) y Cómo Prevenirlo

¡Hola, chicos!
En este artículo me gustaría compartir con ustedes una característica disponible desde SQL Server 2005, que le permite ejecutar código T-SQL en nombre de otro usuario. Estoy hablando del comando EJECUTAR COMO.

Con esta gran demanda de seguridad que buscan las empresas, impulsadas por las exigencias de adaptación al GDPR, las organizaciones muchas veces aprovechan para revisar todos los aspectos de seguridad, auditoría y monitoreo y este fue uno de los motivos que me motivó a escribir este artículo.

Si desea profundizar en más artículos sobre seguridad, asegúrese de haga clic en este enlace aquí para visitar mis otros artículos sobre este tema.

Si estás experimentando algún problema de seguridad o quieres consultoría especializada para analizar, probar y aplicar las mejores prácticas de seguridad en tu empresa, no dudes en contactarme. en este enlace aquí.

Para obtener más información sobre cómo utilizar EXECUTE AS para realizar un ataque de elevación de privilegios, lea el artículo SQL Server: ¡tenga cuidado con la función del servidor securityadmin! Usar la elevación de privilegios para convertirse en administrador de sistemas.

Introducción

De forma predeterminada, todas las operaciones durante una sesión están sujetas a comprobaciones de permisos para ese usuario. Cuando se ejecuta una instrucción EXECUTE AS, el contexto de ejecución de la sesión cambia al nombre de usuario o inicio de sesión específico. Después del cambio de contexto, los permisos se verifican en los tokens de seguridad y de inicio de sesión del usuario para la cuenta, en lugar de en la persona que llama a la instrucción EXECUTE AS.

Demostraré cómo funciona esto creando un usuario llamado “test”, con permiso db_datareader en la base de datos AdventureWorks, pero con lectura denegada en la tabla Person.Person:

USE [master]
GO

CREATE LOGIN [teste] WITH PASSWORD=N'aaa', DEFAULT_DATABASE=[master], CHECK_EXPIRATION=OFF, CHECK_POLICY=OFF
GO

USE [AdventureWorks]
GO

CREATE USER [teste] FOR LOGIN [teste]
GO

ALTER ROLE [db_datareader] ADD MEMBER [teste]
GO

DENY SELECT ON Person.Person TO [teste]
GO

Después de ejecutar el script anterior, comprobaré qué usuario se encuentra actualmente en el contexto de mi sesión:

SELECT
    ORIGINAL_LOGIN() AS [ORIGINAL_LOGIN],
    USER_NAME() AS [USER_NAME],
    SUSER_NAME() AS [SUSER_NAME],
    SUSER_SNAME() AS [SUSER_SNAME],
    SYSTEM_USER AS [SYSTEM_USER],
    IS_SRVROLEMEMBER('sysadmin') AS [isSysAdmin]

Resultado:

Ahora, usaré la instrucción EXECUTE AS para cambiar el usuario actual en mi sesión:

EXECUTE AS USER = 'teste'
GO

SELECT
    ORIGINAL_LOGIN() AS [ORIGINAL_LOGIN],
    USER_NAME() AS [USER_NAME],
    SUSER_NAME() AS [SUSER_NAME],
    SUSER_SNAME() AS [SUSER_SNAME],
    SYSTEM_USER AS [SYSTEM_USER],
    IS_SRVROLEMEMBER('sysadmin') AS [isSysAdmin]
GO

Resultado:

Como este usuario tiene el rol de base de datos “db_datareader”, no debería tener ningún problema al intentar consultar datos de la tabla de direcciones, por ejemplo:

Pero si intentamos consultar datos de la tabla Persona, a la que le apliqué DENY SELECT a este usuario, no podrá ejecutar el comando. Vale recordar que mi usuario original es sysadmin, es decir, no tiene restricciones de acceso.

Con esto pude demostrar una forma muy interesante de uno de los propósitos de EXECUTE AS, que es validar si un usuario determinado puede realizar una actividad después de que el DBA conceda el permiso, Por ejemplo.

Tipos de personificaciones

Ver contenido

Hay algunas formas de ejecutar el comando EXECUTE AS, donde puede elegir los usuarios o inicios de sesión que serán suplantados por la instrucción. Describiré estos tipos a continuación en los 2 escenarios en los que se utiliza EXECUTE AS.

EJECUTAR COMO en consultas/declaraciones Ad-Hoc

ACCESO: Le permite suplantar un inicio de sesión de SQL Server, obteniendo todos los permisos a nivel de instancia, heredando permisos como CONTROL SERVER y roles de servidor como sysadmin y securityadmin, por ejemplo.
USUARIO: Permite hacerse pasar por un usuario de SQL Server, obteniendo todos los permisos a nivel de base de datos, heredando permisos como SELECT sobre una tabla y roles de base de datos, como db_datareader, por ejemplo.

Recordando que, incluso si te estás haciendo pasar por un usuario sysadmin a través de una base de datos que eres db_owner, por ejemplo, usando EXECUTE AS USER, no tendrás los “poderes” de sysadmin de ese usuario, ya que EXECUTE AS USER solo hereda permisos a nivel de base de datos. Como ya eres db_owner, no heredarás ningún permiso nuevo que no tengas ya, solo podrás ejecutar comandos como otro usuario (lo cual sigue siendo un riesgo). Si puede usar EJECUTAR COMO INICIAR SESIÓN de un usuario administrador de sistemas, entonces tendrá todos los "poderes" en el nivel de instancia que él tiene (es decir, puede hacer TODO).

EJECUTAR COMO en objetos de base de datos

LLAMADOR: Ejecutar como LLAMADOR es el valor predeterminado; Si no se especifican otras opciones, el procedimiento se ejecuta en el contexto de seguridad de la persona que llama.
DUEÑO: Ejecutar como PROPIETARIO ejecuta el procedimiento en el contexto del propietario del objeto. Si el objeto se crea en un esquema propiedad de dbo o del propietario de la base de datos, el procedimiento se ejecuta con permisos ilimitados.
SER: Ejecutar como SELF se ejecuta en el contexto de seguridad del creador del objeto. Esto equivale a ejecutar como usuario especificado, donde el usuario especificado es la persona que crea o cambia el objeto.
INICIO DE SESIÓN/USUARIO: Como ya se describió anteriormente, también puede usar un usuario específico o iniciar sesión en el encabezado del objeto, lo que permite que todos los que tengan permiso de EJECUCIÓN sobre este objeto, como un procedimiento almacenado, ejecuten este objeto con el contexto de ese usuario/inicio de sesión especificado automáticamente.

Más adelante hay un tema específico sobre EJECUTAR COMO en Objetos de Base de Datos, donde daré más detalles sobre este uso.

Revertir el EXECUTE AS y regresar al usuario original

Ver contenido

Después de ejecutar la instrucción EXECUTE AS para ejecutar comandos como otro usuario, a menudo desea volver a cambiar el contexto de seguridad de la sesión al usuario original. Una de las formas de hacerlo es crear una nueva sesión al volver a conectarse al banco.

El comando REVERTIR

La otra forma de hacerlo es utilizando el comando REVERT, que devolverá el contexto de seguridad al usuario anterior:

USE [dirceuresende]
GO

SELECT
    ORIGINAL_LOGIN() AS [ORIGINAL_LOGIN],
    USER_NAME() AS [USER_NAME],
    SUSER_NAME() AS [SUSER_NAME],
    SUSER_SNAME() AS [SUSER_SNAME],
    SYSTEM_USER AS [SYSTEM_USER],
    IS_SRVROLEMEMBER('sysadmin') AS [isSysAdmin]
    
EXECUTE AS USER = 'teste_sysadmin'
GO

SELECT
    ORIGINAL_LOGIN() AS [ORIGINAL_LOGIN],
    USER_NAME() AS [USER_NAME],
    SUSER_NAME() AS [SUSER_NAME],
    SUSER_SNAME() AS [SUSER_SNAME],
    SYSTEM_USER AS [SYSTEM_USER],
    IS_SRVROLEMEMBER('sysadmin') AS [isSysAdmin]
GO

REVERT
GO

SELECT
    ORIGINAL_LOGIN() AS [ORIGINAL_LOGIN],
    USER_NAME() AS [USER_NAME],
    SUSER_NAME() AS [SUSER_NAME],
    SUSER_SNAME() AS [SUSER_SNAME],
    SYSTEM_USER AS [SYSTEM_USER],
    IS_SRVROLEMEMBER('sysadmin') AS [isSysAdmin]
GO

Resultado:

Vale la pena recordar que el comando EXECUTE AS se puede anidar, es decir, se puede crear un árbol de contextos de seguridad, como se muestra a continuación:

USE [master]
GO

SELECT ORIGINAL_LOGIN() AS [ORIGINAL_LOGIN], USER_NAME() AS [USER_NAME], SUSER_NAME() AS [SUSER_NAME], SUSER_SNAME() AS [SUSER_SNAME], SYSTEM_USER AS [SYSTEM_USER], IS_SRVROLEMEMBER('sysadmin') AS [isSysAdmin]
GO
    
EXECUTE AS LOGIN = 'teste_sysadmin'
GO

SELECT ORIGINAL_LOGIN() AS [ORIGINAL_LOGIN], USER_NAME() AS [USER_NAME], SUSER_NAME() AS [SUSER_NAME], SUSER_SNAME() AS [SUSER_SNAME], SYSTEM_USER AS [SYSTEM_USER], IS_SRVROLEMEMBER('sysadmin') AS [isSysAdmin]
GO

EXECUTE AS LOGIN = 'teste'
GO

SELECT ORIGINAL_LOGIN() AS [ORIGINAL_LOGIN], USER_NAME() AS [USER_NAME], SUSER_NAME() AS [SUSER_NAME], SUSER_SNAME() AS [SUSER_SNAME], SYSTEM_USER AS [SYSTEM_USER], IS_SRVROLEMEMBER('sysadmin') AS [isSysAdmin]
GO

EXECUTE AS LOGIN = 'teste2'
GO

SELECT ORIGINAL_LOGIN() AS [ORIGINAL_LOGIN], USER_NAME() AS [USER_NAME], SUSER_NAME() AS [SUSER_NAME], SUSER_SNAME() AS [SUSER_SNAME], SYSTEM_USER AS [SYSTEM_USER], IS_SRVROLEMEMBER('sysadmin') AS [isSysAdmin]
GO

Resultado:

Y ahora, deshagamos la pila para mostrar el anidamiento de este contexto:

SELECT ORIGINAL_LOGIN() AS [ORIGINAL_LOGIN], USER_NAME() AS [USER_NAME], SUSER_NAME() AS [SUSER_NAME], SUSER_SNAME() AS [SUSER_SNAME], SYSTEM_USER AS [SYSTEM_USER], IS_SRVROLEMEMBER('sysadmin') AS [isSysAdmin]
GO

REVERT
GO

SELECT ORIGINAL_LOGIN() AS [ORIGINAL_LOGIN], USER_NAME() AS [USER_NAME], SUSER_NAME() AS [SUSER_NAME], SUSER_SNAME() AS [SUSER_SNAME], SYSTEM_USER AS [SYSTEM_USER], IS_SRVROLEMEMBER('sysadmin') AS [isSysAdmin]
GO

REVERT
GO

SELECT ORIGINAL_LOGIN() AS [ORIGINAL_LOGIN], USER_NAME() AS [USER_NAME], SUSER_NAME() AS [SUSER_NAME], SUSER_SNAME() AS [SUSER_SNAME], SYSTEM_USER AS [SYSTEM_USER], IS_SRVROLEMEMBER('sysadmin') AS [isSysAdmin]
GO

REVERT
GO

SELECT ORIGINAL_LOGIN() AS [ORIGINAL_LOGIN], USER_NAME() AS [USER_NAME], SUSER_NAME() AS [SUSER_NAME], SUSER_SNAME() AS [SUSER_SNAME], SYSTEM_USER AS [SYSTEM_USER], IS_SRVROLEMEMBER('sysadmin') AS [isSysAdmin]
GO

Resultado:

CORRE COMO… CON COOKIES

Este parámetro especifica que el contexto de ejecución solo se puede revertir al contexto anterior si la instrucción REVERT FROM COOKIE que llama contiene el valor @varbinary_variable correcto. Esta es una medida de seguridad, utilizada especialmente en grupos de conexiones, para garantizar que solo aquellos que conocen el hash de la cookie puedan revertir el contexto de seguridad.

Ejemplo (eliminé los comandos GO para evitar perder información variable):

USE [master]
GO

-- Exibe as informações do usuário original
SELECT ORIGINAL_LOGIN() AS [ORIGINAL_LOGIN], USER_NAME() AS [USER_NAME], SUSER_NAME() AS [SUSER_NAME], SUSER_SNAME() AS [SUSER_SNAME], SYSTEM_USER AS [SYSTEM_USER], IS_SRVROLEMEMBER('sysadmin') AS [isSysAdmin];

-- Cria a variável do cookie e armazena o hash gerado
DECLARE @cookie VARBINARY(8000);
EXECUTE AS LOGIN = 'teste_sysadmin' WITH COOKIE INTO @cookie;

-- Exibe o cookie
SELECT @cookie;

-- Mostra o usuário personificado (teste_sysadmin(
SELECT ORIGINAL_LOGIN() AS [ORIGINAL_LOGIN], USER_NAME() AS [USER_NAME], SUSER_NAME() AS [SUSER_NAME], SUSER_SNAME() AS [SUSER_SNAME], SYSTEM_USER AS [SYSTEM_USER], IS_SRVROLEMEMBER('sysadmin') AS [isSysAdmin];

-- Volta o contexto de segurança para o usuário original
REVERT WITH COOKIE = @cookie;

-- Exibe as informações do usuário original novamente
SELECT ORIGINAL_LOGIN() AS [ORIGINAL_LOGIN], USER_NAME() AS [USER_NAME], SUSER_NAME() AS [SUSER_NAME], SUSER_SNAME() AS [SUSER_SNAME], SYSTEM_USER AS [SYSTEM_USER], IS_SRVROLEMEMBER('sysadmin') AS [isSysAdmin];

Resultado:

Ahora intentaré aplicar el comando REVERT sin especificar el token:

Ahora intentaré intercambiar el token e intentaré aplicar el comando REVERT:

EJECUTAR COMO... SIN REVERSIÓN

Después de presentar los comandos REVERT y REVERT FROM COOKIES, hay otra cláusula que significa que la suplantación no se puede revertir al usuario original en esta sesión. Esta declaración NO TIENE REVERSIÓN. En este caso, la única forma de revertir es abrir una nueva sesión.

Cuando se especifica la cláusula CON NO REVERT COOKIE = @varbinary_variable, el motor de base de datos de SQL Server pasa el valor de la cookie a @varbinary_variable. El contexto de ejecución establecido por esta declaración solo se puede revertir al contexto anterior si la declaración de llamada REVERT FROM COOKIE = @varbinary_variable tiene el mismo valor @varbinary_variable.

Esta opción es útil en un entorno donde se utiliza la agrupación de conexiones. La agrupación de conexiones es el mantenimiento de un grupo de conexiones de bases de datos para su reutilización por aplicaciones en un servidor de aplicaciones. Debido a que el valor pasado a @varbinary_variable solo lo conoce la persona que llama a la instrucción EXECUTE AS (en este caso, la aplicación), la persona que llama puede asegurarse de que nadie más pueda cambiar el contexto de ejecución establecido.

Ejemplo:

USE [master]
GO

SELECT ORIGINAL_LOGIN() AS [ORIGINAL_LOGIN], USER_NAME() AS [USER_NAME], SUSER_NAME() AS [SUSER_NAME], SUSER_SNAME() AS [SUSER_SNAME], SYSTEM_USER AS [SYSTEM_USER], IS_SRVROLEMEMBER('sysadmin') AS [isSysAdmin]
GO
    
EXECUTE AS LOGIN = 'teste_sysadmin' WITH NO REVERT
GO

SELECT ORIGINAL_LOGIN() AS [ORIGINAL_LOGIN], USER_NAME() AS [USER_NAME], SUSER_NAME() AS [SUSER_NAME], SUSER_SNAME() AS [SUSER_SNAME], SYSTEM_USER AS [SYSTEM_USER], IS_SRVROLEMEMBER('sysadmin') AS [isSysAdmin]
GO

REVERT
GO

SELECT ORIGINAL_LOGIN() AS [ORIGINAL_LOGIN], USER_NAME() AS [USER_NAME], SUSER_NAME() AS [SUSER_NAME], SUSER_SNAME() AS [SUSER_SNAME], SYSTEM_USER AS [SYSTEM_USER], IS_SRVROLEMEMBER('sysadmin') AS [isSysAdmin]
GO

Resultado:

¿Cuáles son los permisos para utilizar EXECUTE AS?

Ver contenido

Para poder utilizar el comando EXECUTE AS en cualquier inicio de sesión anterior a SQL Server 2014, necesitaba tener permiso de SERVIDOR DE CONTROL o ser parte de las funciones del servidor sysadmin o securityadmin. A partir de SQL Server 2014, esto terminó volviéndose más objetivo con el permiso IMPERSONATE ANY LOGIN, que es exclusivo para este tipo de actividad y no requiere que la persona tenga el rol de SERVIDOR DE CONTROL ni sea un usuario administrador de sistemas.

Sin embargo, usted que es DBA debe tener en cuenta que este permiso es EXTREMADAMENTE peligroso para un usuario común, ya que puede usar EXECUTE AS para ejecutar comandos usando el inicio de sesión de un usuario sysadmin, por ejemplo, y así hacer cualquier cosa en la instancia.

Esta fue una de las razones por las que se creó el permiso IMPERSONATE ANY LOGIN en SQL Server 2014. Los usuarios con permiso CONTROL SERVER ya tenían este privilegio implícitamente y con esto podían usar EXECUTE AS para ejecutar comandos como otro usuario, incluidos los usuarios sysadmin. A partir de SQL Server 2014, el DBA ahora puede aplicar un comando DENY IMPERSONATE ANY LOGIN a los usuarios con permiso CONTROL SERVER y evitar que esto suceda.

Vale la pena mencionar que también existe el comando GRANT IMPERSONATE ON LOGIN/USER::[usuario1] TO [usuario2], que le permite otorgar acceso IMPERSONATE a usuarios específicos. Además, los miembros del rol de base de datos db_owner pueden usar EXECUTE AS en usuarios creados en estas bases de datos. Recordando que, incluso si te estás haciendo pasar por un usuario sysadmin a través de una base de datos de la que eres db_owner, por ejemplo, usando EXECUTE AS USER, no tendrás los “poderes” de sysadmin de ese usuario, ya que EXECUTE AS User solo hereda permisos a nivel de base de datos. Como ya eres db_owner, no heredarás ningún permiso nuevo que no tengas ya, solo podrás ejecutar comandos como otro usuario (lo cual sigue siendo un riesgo).

Permisos explícitos para utilizar IMPERSONATE

Como mencioné anteriormente, existen algunas condiciones para usar el comando EXECUTE AS en SQL Server.

Condición n.º 1: SUplantar cualquier inicio de sesión

Los usuarios que tienen permiso explícito IMPERSONATE ANY LOGIN pueden ejecutar comandos como cualquier inicio de sesión en la instancia de SQL Server. Recuerde que los permisos son a nivel de instancia, es decir, se aplican a todas las bases de datos de esa instancia y los comandos que requieren privilegios como sysadmin y CONTROL SERVER se pueden utilizar a través de EXECUTE AS LOGIN.

Para liberar este permiso, debe utilizar el siguiente comando:

GRANT IMPERSONATE ANY LOGIN TO [login];

Condición #2: INICIAR SESIÓN SUPERSONADA

Los usuarios que tienen el permiso IMPERSONATE LOGIN pueden ejecutar comandos como inicios de sesión específicos en la instancia de SQL Server. Este comando permite a loginA ejecutar comandos como si fuera loginB y debe liberarse para cada inicio de sesión deseado. Recuerde que los permisos son a nivel de instancia, es decir, se aplican a todas las bases de datos de esa instancia y los comandos que requieren privilegios como sysadmin y CONTROL SERVER se pueden utilizar a través de EXECUTE AS LOGIN.

Para liberar este permiso, debe utilizar el siguiente comando:

GRANT IMPERSONATE ON LOGIN::LoginB TO [LoginA];

Condición #3: USUARIO SUFICIENTE

Los usuarios que tienen el permiso USUARIO IMPERSONADO pueden ejecutar comandos como usuarios específicos en una base de datos. Este comando permite al usuario A ejecutar comandos como si fuera el usuario B en la base de datos, que tiene permiso IMPERSONATE y debe liberarse para cada inicio de sesión deseado. Los comandos que requieren permisos a nivel de instancia (por ejemplo: apagar, cambiar miembros de la función del servidor, crear un servidor vinculado, etc.) NO son ejecutados por USUARIO IMPERSONADO, solo los comandos que requieren permisos a nivel de base de datos, como INSERTAR, ACTUALIZAR, ELIMINAR, etc.

Para liberar este permiso, debe utilizar el siguiente comando:

GRANT IMPERSONATE ON USER::UsuarioB TO [UsuarioA];

Permisos implícitos para utilizar IMPERSONATE

Ahora demostraré que existen algunas condiciones implícitas en las que puede utilizar el comando EXECUTE AS en SQL Server sin tener permiso explícito para hacerlo.

Condición #1: SYSADMIN

Rol de “Administrador” de SQL Server. Los usuarios en este rol pueden hacer cualquier cosa en la base de datos y, por lo tanto, ya tienen permisos IMPERSONATE LOGIN, IMPERSONATE USER y IMPERSONATE CUALQUIER LOGIN y no se les pueden negar privilegios con DENEGAR.