SQL Server – Entendendo os riscos da propriedade TRUSTWORTHY habilitada em um database

Visualizações: 459
Tempo de Leitura: 6 minutos

Fala pessoal!
Em mais um artigo sobre segurança, que é o tema da minha palestra no MVPConf LATAM 2019, vou compartilhar com vocês os riscos da propriedade TRUSTWORTHY de um database no SQL Server, que é muito utilizado em ambientes que utilizam bibliotecas SQLCLR com nível de permissão EXTERNAL_ACCESS ou UNRESTRICTED.

Se você tem uma biblioteca SQLCLR e habilitou a propriedade Trustworthy por causa disso, saiba que existem outras formas de se conseguir utilizar suas bibliotecas CLR sem precisar ativar essa propriedade, que é com uso de certificados e assinatura do Assembly no SQL Server. Em breve vou escrever um artigo sobre isso.

Para identificar os databases da sua instância que possuem essa propriedade habilitada, utilize a query abaixo:

Resultado:

E numa consulta um pouco mais elaborada, já podemos fazer a associação com assemblies SQLCLR e com os usuários que são db_owner nesses databases:

Resultado:

Para que serve e qual o perigo do TRUSTWORTHY = ON?

A propriedade TRUSTWORTHY tem sim, seus benefícios, como a possibilidade de executar Stored Procedures com acesso externo em bibliotecas SQLCLR, mas vai além disso. Como o Luan Moreno explicou detalhadamente no seu artigo Porque Utilizar a Opção TRUSTWORTHY, essa propriedade, quando habilitada, permite que um objeto criado utilizando EXECUTE AS (ou até mesmo um comando ad-hoc) em um determinado database acesse dados de outro database.

Como a operação EXECUTE AS exige um nível de confiabilidade muito grande (saiba sobre os riscos do EXECUTE AS clicando aqui neste link), o SQL Server bloqueia esse tipo de execução, que só é permitida retirando a cláusula EXECUTE AS desse objeto ou habilitando a propriedade TRUSTWORTHY no database onde o objeto está criado.

Mas qual é o risco de ter a propriedade TRUSTWORTHY habilitada em um database ? É justamente essa confiabilidade entre os databases.. rs

Meu ambiente tem o seguinte cenário: O usuário dirceu Dirceu_User faz parte dos membros da database role db_owner no banco CLR, que possui a propriedade Trustworthy habilitada. Esse usuário não está nem criado em outros databases e não possui nenhuma permissão a nível de instância.

Vamos ver o que dá pra fazer nesse cenário.

Tentativa 1: Quero ser sysadmin!

Logo de cara no primeiro teste, vou tentar me aproveitar do banco ter a propriedade Trustworthy habilitada para me transformar em um usuário sysadmin. Isso será feito utilizando o usuário padrão dbo, para executar os comandos que eu preciso:

Resultado da execução: Agora sou sysadmin!

Já de cara deu pra entender o risco que essa propriedade traz pra gente né ? Imaginem um database com essa propriedade habilitada e o usuário de alguma aplicação esteja na role db_owner. Um SQL Injection simples pode fazer com o que invasor obtenha privilégio de sysadmin na instância, mesmo que o usuário da aplicação não seja sysadmin. Para saber mais sobre SQL Injection, dê uma lida no meu artigo SQL Server – Como evitar SQL Injection? Pare de utilizar Query Dinâmica como EXEC(@Query). Agora..

Tentativa 2: Quero ser db_owner de outros databases!

Nessa segunda tentativa, vou tentar criar meu usuário em outro database e me colocar como db_owner desse database também. Desta forma, um atacante consegue acesso a outros databases que existem na instância, não só no banco que ele conseguiu invadir.

Vamos tentar acessar o database “dirceuresende”, pois quero ler os dados que estão lá:

É, meu usuário não existe lá. Bom, vamos invadir então:

Vamos agora acessar o database “dirceuresende” através do EXECUTE AS:

Agora vou listar quem são os db_owners nesse database:

Começando a minha “invasão”, estou utilizando o contexto de execução do usuário dbo e com isso, posso criar meu usuário nesse database me adicionar na database role db_owner:

Agora meu usuário é db_owner do database “dirceuresende” :). Não acredita? Vou provar.

Resultado final do meu ataque:

Bom pessoal, com esses 2 tipos de ataques demonstrados acima, acho que consegui expor alguns riscos de segurança ao se utilizar essa propriedade em ambientes de produção, especialmente em databases que são utilizados por aplicações e são suscetíveis a ataques como SQL Injection e o atacante terá bem mais ferramentas para utilizar com essa propriedade habilitada no banco que ele está atacando.

Vale ressaltar que essa propriedade tem seus benefícios sim, conforme comentei no início da postagem, mas deve ter ativada com muito cuidado e consciência no ambiente. Esses exemplos que demonstrei são apenas alguns deles, mas podem ser feito N tipos de ataques diferentes explorando a brecha de segurança causada pela propriedade Trustworthy.

Se você tem uma biblioteca SQLCLR e habilitou a propriedade Trustworthy por causa disso, saiba que existem outras formas de se conseguir utilizar suas bibliotecas CLR sem precisar ativar essa propriedade, que é com uso de certificados e assinatura do Assembly no SQL Server. Em breve vou escrever um artigo sobre isso. Aguardem..

E para tranquilizar vocês, saibam que apenas usuários que estão na role sysadmin podem alterar a propriedade TRUSTWORTHY de um database. Nem mesmo o owner do DB ou os usuários que estão na role db_owner, podem alterar essa propriedade.

Referências:

É isso aí, pessoal!
Espero que tenham gostado desse artigo e vocês comecem a levar a segurança do seu ambiente mais a sério. Se você está preocupado com a segurança do seu ambiente e quer a opinião de um especialista no assunto, solicite agora mesmo o Check-up GRATUITO do seu banco de dados + análise de segurança: Será que você precisa ?.

Forte Abraço e até a próxima!