Clique no banner para conhecer e adquirir o meu treinamento de Bancos de Dados no Azure

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

Visualizações: 862 views
Esse post é a parte 17 de 21 da série Segurança e Auditoria
Tempo de Leitura: 6 minutos

Fala pessoal!

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.

Introdução

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:

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:

Resultado:

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

Resultado:

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?

Resultado:

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

Resultado:

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

Vamos conferir as permissões atuais:

Resultado:

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”:

Resultado:

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:

Resultado:

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?

Resultado:

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

Resultado:

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.