Fala, pessoal!
Neste artigo eu gostaria de compartilhar com vocês a minha experiência durante diversos testes que eu fiz sobre Ransomwares em servidores de bancos de dados SQL Server, como o WannaCry, que baixei e “infectei” minha VM apenas para realizar esses testes, entender como ele age e como podemos nos proteger contra esse tipo de ataque, que por incrível que pareça, ainda é comum no dia a dia dos DBAs que trabalham em empresas de consultoria.
Para a criação deste artigo, contei com dicas valiosas do MVP André Ruschel, que me ajudaram a entender melhor a forma de atuação desse Ransomware de forma geral, lembrando que o próprio WannaCry possui diversas variações, então existe a possibilidade de outra variante dele apresentar uma atuação diferente das que vou explicar aqui.
O que é Ransomware?
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 criptomoeda.
O Ransomware mais conhecido até o momento é o WannaCry, que foi considerado o maior ataque desse 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 silenciosamente 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.
Como o WannaCry atua no meu computador?
Falando especificamente sobre o WannaCry, podemos fazer algumas observações interessantes sobre ele:
- Esse Ransomware explora uma vulnerabilidade do Windows que foi corrigida dois meses antes (março de 2017 – MS-17-010) do ataque em massa realizado. Ou seja, se todos mantivessem 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 antiví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. Por exemplo: 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íticas 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 abortaria 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 possa ter sido desligada/reiniciada desde a infecção e o segmento de memória de uma informação específica não possa ter sido realocada 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 e quais chamadas ele faz no SO, veja os arquivos que eu coloquei como referência, pois eles são bem ricos nesses detalhes mais técnicos que não são o foco desse artigo.
Como o DBA pode se proteger contra ataques de Ransomware?
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 na 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.
- Gerencie 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 a 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 receberá 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.
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 fundamental 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. Não precisa ser necessariamente para nuvem, embora seja uma opção muito prática, segura e bem barata.
Seu backup pode, sim, ser backup em fita, disco Blu-Ray, etc. Mas o backup precisa ser armazenado fisicamente 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 testes 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 do que o DBA ter a segurança de 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 instâ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 que o usuário local que tem 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 (um 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 tão restritos quanto 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.
E você? Já passou por alguma situação de ataque de Ransomware na sua empresa? Compartilhe comigo a sua experiência nos comentários e dê um feedback se você gostou do artigo. Aceito dúvidas, sugestões e críticas também.
Espero realmente que tenham gostado. Um grande abraço e até o próximo artigo!
Referências
De 0 a 10, o quanto você recomendaria este artigo para um amigo?