Implicações de segurança de restaurar um backup de uma fonte desconhecida?

31

Cenário : Você recebe um backup do banco de dados e é instruído a restaurá-lo em um servidor (que já hospeda outros bancos de dados), mas não recebe informações úteis sobre o que o backup contém ou se a fonte deve ser confiável.

Pergunta 1 : Quais são as implicações potenciais da restauração de um backup que podem muito bem ser maliciosos?

Pergunta 2 : O que você pode fazer para proteger seu servidor / dados em outros bancos de dados do impacto de restaurar um backup potencialmente malicioso? RESTORE VERIFYONLYparece ser um bom primeiro passo. A resposta final é provavelmente 'restaurar o banco de dados em uma VM sandbox sem acesso ao mundo externo', mas vamos supor que essa opção esteja fora de questão. O que mais deve ser feito nessa situação?

Simon Righarts
fonte
1
Mesmo assumindo que a restauração seja apenas de dados (sem procedimentos armazenados ou algo parecido), há muita malícia que pode acontecer. Suponha que o backup seja para um aplicativo Web que contenha uma tabela de usuários, com seus respectivos níveis de permissão, um backup mal-intencionado possa conceder acesso a usuários que não deveriam tê-los e quem sabe o que eles poderiam fazer com isso.
Lie Ryan
Muito estranho, ninguém mencionou o risco potencial de procedimentos ou funções de CLR. (não está mais desativado por padrão)
ALZDBA 24/09

Respostas:

21

Um banco de dados pode conter código malicioso, possivelmente um procedimento que alterará uma senha para o logon "sa" ou descartará todos os bancos de dados. No entanto, a única maneira que vejo que causa um problema é que um indivíduo restaure o banco de dados e execute manualmente qualquer código nesse banco de dados. Não seria executado de maneira automatizada.

Não há nenhuma configuração que possa ser aplicada em um banco de dados para que o SQL Server execute automaticamente algum bit de código no banco de dados ao restaurá-lo em um servidor. Se o fizesse, esperaria que a Microsoft perdesse a certificação Common Criteria para o produto. Isso é ótimo para um bug ter permitido em um DBMS para mim.

Shawn Melton
fonte
Se o Service Broker for reativado como parte da restauração (usando WITH ENABLE_BROKERet al), o código poderá ser executado "automaticamente". Obviamente, o restaurador não gostaria de usar nenhuma dessas opções se a segurança fosse uma preocupação, mas poderia ser enterrada em um aplicativo de fornecedor de terceiros em que o usuário talvez não a visse.
21416 Jon Seigel
Que tipo de código pode ser executado através do Service Broker? Eu nunca o uso ou configuro.
21814 Shawn Melton
Procedimentos armazenados de ativação. technet.microsoft.com/en-us/library/…
Jon Seigel
2
Talvez também faça um RESTORE HEADERONLY para ver se o banco de dados tem a restrição ativada. Nesse caso, e a contenção está ativada no servidor, os usuários poderão acessá-lo sem que você lhes dê acesso ao servidor. Isso é para o SQL 2012 ou mais recente, é claro. se a contenção não estiver ativada no servidor e o banco de dados no backup estiver ativado, a restauração falhará; portanto, apenas uma preocupação se estiver ativada no servidor.
Robert L Davis
1
@ JonSeigel Eu acho que não serão disparados automaticamente. ALGO tem que colocar uma mensagem em uma fila enviando-a para um serviço, para que haja alguma interação nesse banco de dados para inserir um registro ou disparar um procedimento ou algo assim. As filas do corretor não apenas continuam disparando seus procedimentos de ativação sem nenhuma interação, elas observam as mensagens para serem exibidas na fila.
JNK
11

Existem algumas etapas de prevenção que você pode executar.

  1. Certifique-se de que ninguém, exceto um administrador de sistema, tenha acesso ao banco de dados restaurado.
  2. Coloque o banco de dados no modo de usuário único após a conclusão da restauração.
  3. Verifique o código dentro de todos os procedimentos e funções armazenados e gatilhos dentro deste banco de dados.
  4. Execute um dbcc checkdb para garantir que não haja problemas de integridade.
  5. Verifique os usuários que costumavam ter acesso ao banco de dados e remova todos eles.
  6. Comece a permitir o acesso, muito restrito a objetos específicos verificados por você.

Como Shawn disse, o código não será executado por si só, a menos que algum procedimento armazenado que pareça vbalid possua um executor de outro código malicioso. Esta é a razão de verificar o código dentro de cada um deles antes de colocá-lo no modo multiusuário.

yrushka
fonte
10

Estou chegando aqui, mas posso pensar em pelo menos um cenário perigoso: se você restaurar um banco de dados com uma tabela de arquivos, esses arquivos estarão agora na sua rede por padrão (e especificamente no SQL Server). Você pode restaurar um vírus.

Isso, por si só, não fará nada, é claro - o vírus não se torna repentino - mas se os usuários tentarem acessar o arquivo, eles poderão estar infectados. (Ei, eu disse que estava chegando.) Estou imaginando um cenário em que um hacker externo deseja obter malware na porta e ele envia um e-mail para Bob na contabilidade dizendo: "Aqui está o arquivo: \ sqlserver \ filetableshare \ myvirus.exe "- nesse ponto, ele ultrapassa os firewalls sem detecção, e agora estamos com suas ferramentas internas de antivírus e anti-malware.

Brent Ozar
fonte
2
Você também pode expressar isso como 'o banco de dados contém instruções para nossa equipe que devem ser lidas e aplicadas'. Se eles seguirem as instruções maliciosas, lançarão os foguetes em Moscou. Seria comum varchar em uma tabela ... O mesmo se você restaurar binários e convidar funcionários para executá-lo sem validar a origem, você esperava.
Remus Rusanu
@RemusRusanu lança os foguetes em Moscou, hahaha, legal!
Brent Ozar
Ame a perspectiva da engenharia social. Um e-mail direcionado com um arquivo .bak provavelmente pode ser muito atraente, dependendo do destino.
Max Vernon
7

RESTORE VERIFYONLY parece ser um bom primeiro passo. A resposta final é provavelmente 'restaurar o banco de dados em uma VM sandbox sem acesso ao mundo externo', mas vamos supor que essa opção esteja fora de questão. O que mais deve ser feito nessa situação?

A verificação de restauração verifica apenas a integridade do banco de dados. NÃO informará se o backup inclui um código malicioso ou não. RESTORE VERIFYONLY não tenta verificar a estrutura dos dados contidos nos volumes de backup. É altamente improvável que se o backup vier de dentro da empresa em que você trabalha pode ser malicioso, mas se for de terceiros, você precisa ter cuidado, como apontou Shawn.

A documentação do Microsoft Online diz que

• Por motivos de segurança, recomendamos que você não anexe ou restaure bancos de dados de fontes desconhecidas ou não confiáveis. Esses bancos de dados podem conter código malicioso que pode executar código Transact-SQL não intencional ou causar erros, modificando o esquema ou a estrutura física do banco de dados. Antes de usar um banco de dados de uma fonte desconhecida ou não confiável, execute o DBCC CHECKDB no banco de dados em um servidor que não seja de produção e examine também o código, como procedimentos armazenados ou outro código definido pelo usuário, no banco de dados.

Shanky
fonte
7

A questão se concentra principalmente em um backup que contém malware, mas também é possível obter comportamentos indesejados e potencialmente maliciosos a partir da própria operação de restauração.

Descobri acidentalmente no passado que é possível travar o SQL Server tentando restaurar um arquivo de backup corrompido que faz com que o SQL Server tente ler além do final do arquivo de backup e travar. Não tenho certeza de quais versões são suscetíveis ou exatamente o que é necessário para reproduzir o problema. Documentei alguns detalhes limitados aqui quando encontrei esse problema há alguns anos atrás.

James L
fonte
Bom ponto. Eu não pretendia necessariamente focar em "backup válido que contém malware", travar o servidor SQL por meio de um backup inválido também é uma resposta perfeitamente relevante para "o que poderia dar errado?"
Simon Righarts
5

Qual o risco de restaurar um banco de dados desconhecido de uma fonte desconhecida? Nenhum.

Qual o risco de permitir que um aplicativo desconhecido se conecte usando uma conta sysadmin para conectar-se a esse banco de dados e começar a executar o código? GRANDE QUANTIDADE! Se a conta do aplicativo tiver apenas direitos no banco de dados e nenhum acesso no nível do servidor, não haverá nada que possa realmente fazer fora do banco de dados. Basicamente, isso se resume a ter uma configuração de estrutura de segurança adequada no servidor, para começar.

Mrdenny
fonte
2

Você recebe um backup do banco de dados e é instruído a restaurá-lo em um servidor (que já hospeda outros bancos de dados), mas não recebe informações úteis sobre o que o backup contém ou se a fonte deve ser confiável.

Agradável. Você exige uma declaração escrita assinada de quem está lhe dizendo para fazer isso, que eles aceitam total responsabilidade pelas conseqüências. Se eles não estiverem dispostos a fazer isso, você deve testar a instalação em uma caixa de proteção após examinar o arquivo de backup (se possível) e examinar minuciosamente todas as tabelas, procedimentos etc. Se algo cheirar engraçado a qualquer momento, não o coloque o sistema de produção. Mesmo assim, você deve deixar claro (para seu chefe e seus superiores) que nunca confiou no backup e está fazendo isso apenas sob ordens diretas.

Se eles não assinarem tal declaração, alerte seus superiores antes de fazer qualquer coisa. Como profissional, é seu dever proteger seu sistema o máximo possível, não importa o que algum superior estúpido possa ordenar que você faça. Você pode ser demitido, mas pode manter a cabeça erguida e saber que fez a coisa certa.

Phil Perry
fonte
2

Não há muitos perigos, por exemplo, exceto alguns de longo alcance sugeridos aqui. Como foi mencionado, é difícil executar coisas de execução automática em um backup de banco de dados. Precisa de algum tipo de mecanismo de disparo externo.

Obtenha um laptop / desktop antigo e uma versão de avaliação do seu software de banco de dados (SQLExpress), se o licenciamento for um problema. Copie o arquivo de backup na máquina, desconecte a rede / sem fio e faça a restauração. Então comece a cavar. Leve o tempo que precisar, porque há muitos lugares onde as coisas podem ocultar, a maioria delas já coberta por outras postagens neste tópico.

Sua integridade do DBA e o bem-estar do seu ambiente de produção são mais importantes do que qualquer pedido dado por um superior.

Philippe
fonte