Microsoft Exchange Hack: Como foi possível e como evitá-lo.
O hack do Microsoft Exchange foi um dos piores hacks da história, mas certamente não foi o último.
hack do Microsoft Exchange
Sobre o que foi o hack do Microsoft Exchange?
Em janeiro de 2021 várias explorações de dia zero foram relatadas à Microsoft, o que permitiu que atacantes maliciosos acessassem remotamente os servidores Microsoft Exchange. Em 2 de março, a Microsoft publicou um patch para fechar essas vulnerabilidades. No entanto, até hoje nem todos os servidores Exchange estão corrigidos, por isso os ataques continuam.
Como foi possível o hack do Microsoft Exchange?
As vulnerabilidades de dia zero são vulnerabilidades de software de computador que são desconhecidas do fornecedor de um software. No caso do Microsoft Exchange, as vulnerabilidades muito provavelmente existem desde 2010. Os servidores Exchange usados por dezenas de milhares de empresas, autoridades públicas e outras organizações estavam rodando software afetado em seus servidores Exchange hospedados localmente.
A enorme quantidade de servidores Exchange em uso, bem como o tempo necessário para cada organização corrigir seus servidores, abriu a porta para que atacantes maliciosos abusassem dessas vulnerabilidades - mesmo depois que o patch estivesse disponível.
Só nos EUA, pelo menos 30.000 organizações foram atacadas.
Linha do tempo
Janeiro
A vulnerabilidade do Microsoft Exchange que permite a um atacante contornar a autenticação e fazer-se passar por um administrador desse servidor foi primeiramente reportada por um pesquisador de segurança principal da empresa de testes de segurança DEVCORE, que passa pelo handle ‘Orange Tsai’.
Just report a pre-auth RCE chain to the vendor. This might be the most serious RCE I have ever reported! Hope there is no bug collision or duplicate😝
— Orange Tsai 🍊 (@orange_8361) January 5, 2021
Mais tarde nesse mês, a empresa de segurança Dubex alerta a Microsoft sobre ataques a uma nova falha do Exchange.
Fevereiro
A partir de fevereiro, a empresa de segurança Volexity avisa a Microsoft sobre ataques ativos a vulnerabilidades de Exchange anteriormente desconhecidas.
Em 8 de Fevereiro, a Microsoft diz à Dubex que “escalou” o seu relatório internamente.
Março
Em 2 de março, a Microsoft lança atualizações para corrigir quatro falhas de dia zero em Exchange.
No entanto, a exploração em massa orientada das vulnerabilidades já começou em 28 de fevereiro.
Em 12 de março, a Microsoft diz que ainda há 82.000 servidores não corrigidos expostos.
Até hoje, muitos servidores Microsoft Exchange hospedados localmente permanecem sem patch e ainda são vulneráveis a essas explorações.
Os atacantes
A Microsoft disse que o ataque foi inicialmente cometido pelo HAFNIUM, um grupo de hacking chinês patrocinado pelo estado. A Microsoft identificou o HAFNIUM como “um ator altamente qualificado e sofisticado”. Os sistemas de correio electrónico da empresa foram direccionados para exfiltrar “informações de vários sectores industriais, incluindo investigadores de doenças infecciosas, firmas de advogados, instituições de ensino superior, empresas de defesa, grupos de reflexão política e ONGs”. Segundo a Microsoft, esta foi “a oitava vez nos últimos 12 meses que a Microsoft divulgou publicamente grupos de estados-nação dirigidos a instituições críticas para a sociedade civil”.
O que podemos fazer para proteger os nossos dados
Primeiro, temos de reconhecer que alcançar a segurança online é uma tarefa difícil. Enquanto a maioria dos provedores de hospedagem são muito bons em corrigir vulnerabilidades imediatamente, a segurança para muitas empresas também é uma questão de confiança.
A confiança é a principal razão pela qual as empresas, particularmente na Alemanha, ainda preferem hospedar seus dados internamente. Isto é completamente compreensível: Se você sabe onde o servidor está, se você sabe quem tem acesso aos servidores, você confia que os dados nesses servidores estão sendo mantidos em segurança.
A alternativa - hospedar os dados da sua empresa na nuvem, ou seja, nos servidores de outras pessoas - parece muito mais arriscada e não confiável. E a verdade é que estas empresas têm razão: se você hospeda seus dados na nuvem, você deve confiar que o provedor de hospedagem mantém os dados seguros por todos os meios. Isso também inclui que o provedor deve manter os dados seguros dos seus próprios funcionários, o que é quase impossível. Uma recente investigação da Bellingcat mostrou como pode ser fácil obter dados pessoais sensíveis dos funcionários.
A encriptação é inevitável
A confiança, porém, pode ser construída adicionando outro nível de segurança: criptografia de ponta a ponta.
Qualquer dado criptografado de ponta a ponta permanece inacessível para o provedor de serviços. Tutanota, por exemplo, é um desses serviços que criptografa o máximo de dados possível de ponta a ponta.
Como consequência, a Tutanota e todos os seus empregados têm acesso zero aos dados criptografados dos clientes. Além disso, se um atacante malicioso pudesse ter acesso aos servidores, eles também só teriam acesso aos dados criptografados, o que torna os dados inutilizáveis para espionagem industrial por atores estatais estrangeiros.
Os provedores de serviços em nuvem geralmente têm um foco claro na segurança. Afinal de contas, é a sua capacidade de resposta para corrigir vulnerabilidades rapidamente. Isso libera as empresas que hospedam seus dados com um provedor da nuvem da tarefa de atualizar manualmente seus servidores. O que é necessário, além disso, é que o provedor da nuvem também aplique criptografia de ponta a ponta aos dados dos clientes.
Fazendo o direito de segurança
Os hacks do Microsoft Exchange demonstram que fazer bem a segurança é difícil.
É particularmente difícil para as pequenas e médias empresas, o que é sublinhado pelo facto de até hoje milhares de servidores Exchange permanecerem sem patch.
Com a criptografia de ponta a ponta se tornando disponível em cada vez mais serviços como o Tutanota, é hora de reconhecer que hospedar os dados na nuvem criptografada pode ser uma alternativa confiável para muitas empresas.