ZeroLogon – Patch não é suficiente

Diretrizes e ferramentas para proteger seu ambiente
de CVE-2020-1472

By Yaron Kassner, CTO e cofundador, Silverfort

A Secura publicou recentemente um whitepaper sobre uma das piores vulnerabilidades que já vi há algum tempo. Chama-se ZeroLogon, também conhecido como CVE-2020-1472. O DHS também publicou um diretiva de emergência para corrigir os servidores Windows afetados. E eles não estão exagerando – a vulnerabilidade permite que um invasor crie uma conta de administrador de domínio, apenas enviando pacotes não autenticados para um controlador de domínio. Isso significa que qualquer pessoa na rede pode assumir o controle de todo o domínio.

Para aqueles interessados ​​nos bits e bytes técnicos – recomendo fortemente a leitura do white paper. O ataque descrito é elegante e tira vantagem de uma vulnerabilidade inerente ao protocolo NRPC. Acontece que algumas pessoas estavam tão interessadas neste ataque, que desenvolveram uma exploração de trabalho completa e publicou no GitHub. Então, se você ainda não implantou a atualização, pare de ler este artigo e faça isso agora. Volte depois de fazer isso.

Tal como acontece com a maioria das vulnerabilidades, a Microsoft publicou um consultivo, junto com uma atualização de segurança. Embora alguns possam ficar tentados a instalar a atualização e esquecê-la, o leitor atento notará este comentário: “A Microsoft está abordando esta vulnerabilidade em uma implementação faseada.”

Sim - não é uma coisa boa. Uma implementação em fases significa que durante a primeira fase da implementação o seu sistema ainda estará vulnerável. Foi necessária uma abordagem faseada neste caso porque a vulnerabilidade é inerente ao protocolo NRPC. O patch evita o ataque ao impor uma camada adicional de segurança sobre o protocolo – que é o Secure RPC. Infelizmente, não basta atualizar o lado do servidor, ou seja, o DC – porque os clientes também precisam ser atualizados para que o protocolo funcione. A Microsoft cuidou dos dispositivos Windows, mas não forneceu uma solução para sistemas operacionais legados que não são mais suportados ou produtos de terceiros. Isso significa que a aplicação do Secure RPC quebrará esses sistemas incompatíveis.

Durante a primeira fase, o AD impõe RPC seguro para dispositivos Windows, o que significa que a pior forma de ataque pode ser evitada. Mas outros clientes ainda podem estar vulneráveis.

Nós desenvolvemos um ferramenta simples que itera nos controladores de domínio em seu domínio e verifica se todos eles estão corrigidos. A ferramenta é baseada na ferramenta de teste original publicada pela Secura, mas em vez de ser executada em um DC por vez, ela encontrará automaticamente os DCs e será executada em todos eles. Recomendamos que você execute esta ferramenta para garantir que nenhum dos DCs em seu ambiente tenha sido perdido – um DC sem patch é suficiente para comprometer todo o domínio.

Baixe a ferramenta de teste do Github aqui

Passando para a Fase Dois

Na segunda fase, o AD impõe RPC seguro para todos os computadores, incluindo dispositivos que não sejam Windows. A segunda fase será feita automaticamente no dia 2 de fevereiro, mas você pode iniciá-la mais cedo, e recomendamos que o faça. Para fazer isso, primeiro você deve certificar-se de que não possui nenhum cliente na rede que dependa de RPC não seguro. A Microsoft fornece logs de auditoria para descobrir esses clientes e Silverfort também pode ajudar: você pode aproveitar Silverfort para preparar um relatório que liste clientes que usam RPC não seguro. Se você não tem Silverfort, você pode começar auditando os logs de eventos da Microsoft.

O que fazer com clientes RPC não seguros?

Aqui está minha recomendação. Em primeiro lugar, coloque-os em “Controlador de domínio: Permitir conexões de canal seguro Netlogon vulneráveis” política de grupo. Isso não protege esses clientes, mas permitirá que você mova o restante dos dispositivos para o modo de aplicação agora, em vez de esperar até fevereiro de 2021.

Depois de mover o restante dos dispositivos para o modo de imposição, você deverá cuidar dos clientes RPC não seguros. Não os deixe como estão! Eles são vulneráveis!

Se esses dispositivos forem de terceiros, você deverá entrar em contato com o fornecedor e solicitar uma solução para fazê-los funcionar com o Secure RPC.
Se por algum motivo você não conseguir fazer o cliente funcionar com Secure RPC, Silverfort pode ajudar a protegê-lo – veja mais abaixo.

Como é possível Silverfort Ajudar até que todos os clientes RPC não seguros sejam cobertos?

Silverfort monitora e controla o tráfego Netlogon na rede. Isso permite Silverfort para detectar todos os computadores que usam RPC não seguro. Para esses dispositivos, Silverfort pode aumentar o risco e fornecer camadas adicionais de segurança, como intensificar o autenticação requisitos de ou para esses dispositivos.

Resumindo as etapas recomendadas:

1. Atualize seus controladores de domínio
2. Usar Silverfortferramenta de código aberto para ver se há algum DC sem patch
3. Usar Silverfort ou Microsoft para auditoria de clientes que usam RPC não seguro
4. Coloque clientes RPC não seguros na lista de permissões
5. Mova o domínio para o modo de aplicação o mais rápido possível
6. Inicie um processo para corrigir clientes RPC não seguros ou removê-los da sua rede
7. Enquanto isso, use Silverfort para proteger clientes vulneráveis ​​da exploração e restringir seu uso.

Yaron Kassner, CTO e cofundador, Silverfort

SilverfortCTO e cofundador da Yaron Kassner é especialista em segurança cibernética e tecnologia de big data. Antes de co-fundar Silverfort, Yaron atuou como consultor especialista em big data para a Cisco. Ele também desenvolveu novos recursos envolvendo análise de big data e algoritmos de aprendizado de máquina na Microsoft. Antes disso, Yaron serviu na unidade cibernética de elite 8200 das Forças de Defesa de Israel, onde liderou uma respeitável equipe de P&D, foi elevado ao posto de Capitão e recebeu um prestigiado prêmio de excelência. Yaron possui um B.Sc. em Matemática, Summa Cum Laude, um M.Sc. e Ph.D. em Ciência da Computação pelo Technion – Instituto de Tecnologia de Israel.