Finalmente, um ataque massivo de Ransomware – Entenda o que está acontecendo!

O que diversos hospitais públicos da Inglaterra, a Telefônica, a seguradora Mapfre e o Banco Santander na Espanha e uma universidade na Itália tem em comum?

Por Fernando Fonseca

Todos foram alvo de uma série de ciberataques em larga escala que afetaram seus sistemas de informação, computadores e telefonia nesta sexta-feira, 12 de maio de 2017. Esta data talvez entre para a história dos malwares assim como os fatídicos dias 25 de janeiro (SQL Slammer) e 11 de agosto (Blaster) de 2003.

Para entendermos as causas destes ataques, vamos começar com a definição de fatídico segundo o Google:

1. Que revela o que o destino decidiu; que prediz, que profetiza.
2. Que leva à desgraça, ao infortúnio; fatal, sinistro, trágico.

Mas quem previu e profetizou um ataque como este? Eu e boa parte dos profissionais de Segurança da Informação ou de História contemporânea, que já esperavam por um ataque como este. A história se repete sempre, desde que mantidas as mesmas condições para isso. E porque as condições foram mantidas? Não existe risco zero, mas muitas empresas foram comprometidas à memória volátil de alguns gestores, que se esquecem da desgraça, infortúnio, fatalidade e tragédia dos outros ataques e ao elevado apetite de risco da gestão.

Vetor de ataque x Payload

 

O código dos malwares podem ser divididos em 2 partes:

• Vetor de ataque é o método que o agente ameaçador utiliza para atacar um sistema Ex: trojam, phising, etc.
• Payload é uma atividade mal-intencionada exercida pelo malware. O payload é uma ação separada da instalação e da propagação que o malware realiza. Ex: spyware, rootkit, bomba lógica, RANSOMWARE, etc.

Esta situação me lembra muito o vírus FunLove, que combati no início de 2001. Ele estava espalhado em todo o Brasil na organização para a qual eu fui contratado e eles já haviam gastado uma pequena fortuna em mutirão de limpeza de computadores e troca de software antivírus. Minha solução foi prática e objetiva: fiz com que todos os usuários passassem seus arquivos e sistemas em Cobol, Clipper e Access para os File servers de cada uma das 84 regionais e fechei todos os compartilhamentos de estações através de políticas. Essa ação nos protegeram contra outros vírus que se espalhavam de forma semelhante mas tinham um Payload muito mais agressivo, como o Nimda e o Sircam. Paramos de combater o Payload do FunLove para combater o vetor de ataque do vírus, assim como devemos combater o Aedes Aegypti, e não a Dengue, Zika, Chikungunya ou Febre Amarela

O Ransomware não é apenas mais um payload, é o tipo de ataque que mais cresceu nos últimos anos e disparado o mais lucrativo da história (Cresceu 16.700% só em 2016). Os criminosos só estavam esperando por um vetor de ataque/infecção que pudesse passar pelas barreiras que temos hoje, mais consistentes do que as de 15 anos atrás, mas não impenetráveis. Ironicamente, tudo indica que quem involuntariamente forneceu este vetor foi a NSA (Agência Nacional de Segurança norte americana), que aparentemente teve uma ferramenta de invasão roubada por uma equipe de hackers chamada “Shadow Brokers”

A ferramenta em questão explora uma vulnerabilidade do Microsoft Windows chamado EternalBlue, que agora está sendo usado como um dos métodos para espalhar rapidamente um ransomware chamado WannaCry em todo o mundo. Essa poderia ser a deixa para aliviar a consciência e o currículo de alguns gestores, afinal, se o malware explora uma vulnerabilidade, a culpa mais uma vez é da Microsoft!

A falha neste raciocínio é que a Microsoft corrigiu essa falha no Boletim de segurança MS17-010 – Critical – Security Update for Microsoft Windows SMB Server (4013389), publicado em 14 de março, ou seja, há 60 (SESSENTA!) dias. O Que ocorreu nas empresas para que elas não atualizassem seus servidores e suas estações Windows? Provavelmente a mesma coisa que no SQL Slammer e no Blaster, que infectaram o mundo inteiro respectivamente 180 e 28 Dias depois do patch.

Atualizações de Segurança

Nos meus cursos e no livro em que escrevi um capítulo sobre atualizações de segurança (Trilhas na segurança da informação), insisto em uma boa prática que muitas vezes é negligenciada: A aplicação de correções de segurança no menor tempo possível.

O Problema das organizações é que uma vez que a correção é publicada, inicia-se um longo período de homologação por parte da equipe de TI, que pode levar de horas a dias. Os últimos estudos mostram que os vírus baseados em zero-days ou em correções recém lançadas tem tido uma penetração maior em empresas do que em usuários domésticos, porque estes contam com um serviço de atualização automática.

 

Com as tecnologias de virtualização e Cloud Computing, torna-se ainda mais fácil fazer uma homologação rápida e eficiente. As organizações precisam ser mais eficientes em seu processo de homologação, que apesar de importante não pode retardar muito a aplicação de correções, e deve ser tratado com prioridade para que essa não fique exposta a ameaças durante muito tempo.

Ai fica a pergunta: se as empresas conseguem milagres utilizando Agile e DevOps para colocar seus aplicativos rapidamente no mercado, porque a homologação de correções de segurança é tão lenta?

* Fernando Fonseca

PCI DSS – Instructor – Education Director of Cloud Security Alliance BR