SQL Server – Como evitar e se proteger de ataques de Ransomware, como WannaCry, no seu servidor de banco de dados

De acordo com a Cartilha de Segurança para Internet, Ransomware é um tipo de código malicioso que torna inacessíveis os dados armazenados em um equipamento, geralmente usando criptografia, e que exige pagamento de resgate (ransom) para restabelecer o acesso ao usuário, onde pagamento do resgate geralmente é feito via bitcoins ou outra cryptomoeda.

O Ransomware mais conhecido até o momento é o WannaCry, que foi considerado o maior ataque deste tipo já registrado até o momento, tendo início no dia 12/05/2017, atacando cerca de 150 países e infectando mais de 230 mil sistemas, embora existam vários outros rodando pela rede.

O comportamento dos Ransomwares costuma ser bem parecido:

• Tentativas de ataque de força bruta em conexões RDP, SSH e outras, de modo a obter controle da máquina hospedeira. Também pode ser infectado das formas tradicionais: Anexos em e-mails e links de internet
• Uma vez executado, o programa vai começar a criptografar arquivos de determinadas extensões nos discos, unidades removíveis e unidades de redes acessíveis (SMB). Durante os meus testes em uma máquina virtual (VM), deixei um disco da máquina física compartilhado com a VM e vários arquivos desse disco foram criptografados.
• O Ransomware vai silecionsamente criptografar os arquivos em background
• Após o processo ter sido concluído, ele vai trocar o papel de parede da área de trabalho, ficando evidente que a máquina foi comprometida e geralmente exige uma tela para informar que a máquina foi atacada e instruções para realizar o pagamento

Falando especificamente sobre o WannaCry, podemos fazer algumas observações interessantes sobre ele:

• Esse Ransomware explora uma vulnerabilidade do Windows que foi corrigida 2 meses antes (março de 2017 – MS-17-010) do ataque em massa realizado, ou seja, se todos mantessem o sistema operacional atualizado, esse ataque não teria ocorrido
• Ele determina quais arquivos vai criptografar de acordo com a extensão desses arquivos. Embora seja completamente possível tecnicamente analisar os arquivos de acordo com seu Mimetype, essa verificação nos arquivos iria ficar muito mais demorada e consumir bastante recurso da máquina, facilitando a identificação de que está ocorrendo um ataque e facilitando que o usuário interrompa a ação do cracker
• Apesar de ficar mostrando a janela de pagamento o tempo inteiro, o sistema operacional fica totalmente funcional, uma vez que se não estivesse, não seria possível realizar o pagamento
• Caso essa praga virtual seja removida, seja manualmente ou por ferramentas de proteção (como anti-vírus), o token gerado pelo WannaCry durante a inicialização será alterado, não permitindo que o pagamento seja realizado mais
• Analisando os processos em execução, o que mais consome CPU durante a criptografia é o diskpart.exe

  

• Se o arquivo estiver bloqueado para leitura, o Ransomware não consegue criptografá-lo. Ex: Arquivo de banco do SQL Server, onde você não consegue nem copiar o arquivo MDF com o banco online. Mas se você estiver com uma foto aberta no Paint, por exemplo, como ele não aplica um lock no arquivo, o WannaCry consegue criptografar a foto normalmente
• O Wannacry faz elevação de privilégios e executa o vírus com todas as sessões RDP que ele encontrar no sistema operacional
• Durante os meus testes, mesmo com o serviço do SQL Server parado, o WannaCry não conseguiu criptogragar os arquivos MDF, uma vez que para acessar a pasta DATA do SQL Server (diretório padrão), o Windows me pede confirmação (mesmo meu usuário sendo Administrador). Ele só conseguiu criptografar os arquivos quando os movi para um outro diretório sem polícitas de segurança NTFS (C:\Dados). Depois fui descobrir que isso ocorre porque ele ignora os arquivos que estão no diretório “C:\Arquivos de programas\”.

  

• O WannaCry corrompe o Volume Shadow Copy Service (VSS) para dificultar a recuperação dos arquivos criptografados
• O ataque em massa só foi interrompido quando um especialista em segurança analisou o código do ransomware e descobriu que se ele registrasse o domínio www.iuqerfsodp9ifjaposdfjhgosurijfaewrwergwea.com, o vírus abortava novas infecções nas máquinas em que era executado.

Algum tempo após o Boom do WannaCry, foi disponibilizada uma possível solução que promete descriptografar os arquivos criptografados pelo WannaCry em alguns sistemas operacionais, desde que a máquina não pode ter sido desligada/reiniciada desde a infecção e o segmento de memória de uma informação específica não pode ter sido realocado para outro processo na máquina.

Quem se lembra dessa época, foi realmente um CAOS nas empresas. Nos grupos de Whatsapp circulavam várias imagens e prints de grandes empresas sendo atacadas por essa praga virtual e causando ataques devastadores. Muitas acabaram até pagando o resgate para não perder dados importantes.

As extensões que o WannaCry buscava criptografar eram:
.doc, .docx, .xls, .xlsx, .ppt, .pptx, .pst, .ost, .msg, .eml, .vsd, .vsdx, .txt, .csv, .rtf, .123, .wks, .wk1, .pdf, .dwg, .onetoc2, .snt, .jpeg, .jpg, .docb, .docm, .dot, .dotm, .dotx, .xlsm, .xlsb, .xlw, .xlt, .xlm, .xlc, .xltx, .xltm, .pptm, .pot, .pps, .ppsm, .ppsx, .ppam, .potx, .potm, .edb, .hwp, .602, .sxi, .sti, .sldx, .sldm, .sldm, .vdi, .vmdk, .vmx, .gpg, .aes, .ARC, .PAQ, .bz2, .tbk, .bak, .tar, .tgz, .gz, .7z, .rar, .zip, .backup, .iso, .vcd, .bmp, .png, .gif, .raw, .cgm, .tif, .tiff, .nef, .psd, .ai, .svg, .djvu, .m4u, .m3u, .mid, .wma, .flv, .3g2, .mkv, .3gp, .mp4, .mov, .avi, .asf, .mpeg, .vob, .mpg, .wmv, .fla, .swf, .wav, .mp3, .sh, .class, .jar, .java, .rb, .asp, .php, .jsp, .brd, .sch, .dch, .dip, .pl, .vb, .vbs, .ps1, .bat, .cmd, .js, .asm, .h, .pas, .cpp, .c, .cs, .suo, .sln, .ldf, .mdf, .ibd, .myi, .myd, .frm, .odb, .dbf, .db, .mdb, .accdb, .sql, .sqlitedb, .sqlite3, .asc, .lay6, .lay, .mml, .sxm, .otg, .odg, .uop, .std, .sxd, .otp, .odp, .wb2, .slk, .dif, .stc, .sxc, .ots, .ods, .3dm, .max, .3ds, .uot, .stw, .sxw, .ott, .odt, .pem, .p12, .csr, .crt, .key, .pfx, .der

E ele tinha um mecanismo para NÃO criptografar os seguintes diretórios (mantendo assim, o sistema operacional funcionando):

• “Content.IE5”
• “Temporary Internet Files”
• ” This folder protects against ransomware. Modifying it will reduce protection”
• “\Local Settings\Temp”
• “\AppData\Local\Temp”
• “\Program Files (x86)”
• “\Program Files”
• “\WINDOWS”
• “\ProgramData”
• “\Intel”
• “$”

Exemplos de diretórios atacados pelo WannaCry:

Diagrama de atuação do WannaCry:

Caso você queira se especializar na forma de atuação desse Ransomware, entender tecnicamente como ele opera, quais as chamadas ele faz no SO, veja os arquivos que coloquei como referência, pois ele são bem ricos nesses detalhes mais técnicos que não são o foco desse artigo.

Depois de toda essa explicação técnica sobre a forma de atuação do Ransomware, você deve estar se perguntando como o DBA e a empresa podem se proteger contra esse tipo de ataque tão sofisticado e complexo, mas existem várias soluções que vão tornar muito mais difícil que esse ataque tenha sucesso:

• Evite que os servidores fiquem expostos e publicados para a Internet. Em casos onde o servidor de aplicação deve ficar disponível para acesso a partir de qualquer IP, garanta que pelo menos o banco de dados fique em um outro servidor, isolado, inacessível pela Internet, apenas acessado pela rede interna ou VPN.
• Gerencia bem as regras de Firewall dos servidores de banco de dados. Garanta que apenas os servidores de aplicação e máquinas específicas tenham acesso à esses servidores
• Mantenha o Windows e o SQL Server sempre atualizados com as últimas atualizações disponíveis, especialmente quando a atualização informar que está corrigindo uma falha de segurança. O próprio caso do WannaCry poderia ter sido evitado se o sistema operacional dessas máquinas estivesse atualizado.
• Servidor Windows deve utilizar Windows Server. Jamais cogite a possibilidade de utilizar versões do Windows que não sejam a versão Server, como o Windows Starter, Professional, Home Premium, etc..
• Mantenha sempre o sistema operacional e o SQL Server com as versões mais atuais possíveis. O SQL Server 2008, por exemplo, perderá o suporte agora em Junho/2019 e não recerá mais atualizações nem de Segurança. A mesma coisa ocorre com o Windows Server.
• Proteja seu banco de dados contra ataques de força bruta. Como eu já comentei, o WannaCry não consegue criptografar arquivos em uso pelo banco de dados, mas se o invasor conseguir acessar o seu banco de dados, ele pode parar o serviço do SQL ou colocar os bancos offline e depois iniciar o ataque, criptografando assim, seus dados
• Como eu falei mais acima, os Ransomwares costumam visar extensões específicas ao invés de analisar todos os arquivos pelo MIMETYPE. Ele faz isso para otimizar o tempo de busca e criptografia dos arquivos. Por causa disso, é uma boa prática utilizar extensões não tradicionais nos arquivos de dados, log e backup. Evite MDF, LDF e BAK. Use sua imaginação.
  

  Arquivo MDF e LDF em USO não foram criptografados.. Arquivos MDF e LDF que NÃO estavam em uso foram criptografados. Arquivos com extensões que eu inventei na hora, o WannaCry não criptografou
• Por falar em backup, onde você salva os backups da sua empresa? Não é na rede ou no mesmo servidor não né ? Um passo MUITO importante para garantir que você consiga recuperar com segurança os dados originais, mesmo que esse ataque chegue na sua empresa e criptografe seus dados, o BACKUP na nuvem é fundamental para isso.

  Não precisa ser necessariamente para nuvem, embora seja uma opção muito prática, segura e bem barata. O seu backup pode sim, ser backup em fita, disco blu-ray, etc.. Mas o backup precisa ser armazenado físicamente fora do mesmo servidor de origem. Isso é muito importante para garantir que num cenário de invasão total da rede, seus backups não sejam comprometidos também.

  Lembre-se: Se você perde os dados da sua empresa e o backup, acabou a empresa.

• Garanta que exista uma política de teste de backup regularmente na sua empresa. Se você não sabe como fazer isso, dê uma lida nos artigos Automatizando Teste de Restore – Implementação, SQL Server: Automatizando restore de cópias de segurança e no artigo Automatizando Restauração de Banco de Dados.

  Não existe nada pior que o DBA ter a segurança que ele consegue recuperar qualquer problema de corrupção de dados no seu ambiente, e, quando ele tenta restaurar um backup anterior ao problema, descobre que os backups estão corrompidos.

  Backup sem teste de restauração não é garantia de nada!

• Desative o login e renomeie usuários que são padrão em todas as intâncias do SQL Server, como o sa (que ainda por cima é sysadmin), sysdba e outros. Esses são os usuários mais utilizados por ataques de força bruta, pois o atacante já conhece o nome do usuário, só falta a senha.
• Garanta que nenhum usuário com permissão de administrador local do servidor tenha acesso ao banco de dados, nem de leitura. E garanta também que o usuário local que tenha acesso ao banco tenha o mínimo de permissões disponíveis no servidor.

  Se você tem dois usuários no servidor por causa disso (1 para administrar o servidor e outro para o banco), utilize senhas diferentes!! Isso vai dificultar bastante o sucesso de ataques utilizando o seu usuário em ataques.

• Mantenha sempre uma política rígida para controlar e auditar os usuários administradores locais. Mantenha esses usuários o mais restrito possível.
• Assim como fiz no artigo SQL Server – Como evitar ataques de força bruta no seu banco de dados, onde monitoro o log do SQL Server em busca de falhas de conexão, implemente esse mesmo controle no log de segurança e aplicação do Windows em busca de tentativas de conexão utilizando protocolos RDP, SSH e outros
• Bloqueie ou desabilite o protocolo SMB onde for possível – Portas 137 e 138 UDP e TCP 139 e 445.