O que é Zerologon?

Zerologon é o nome dado a uma vulnerabilidade identificada em CVE-2020-1472. Vem de uma falha no processo de logon: O vetor de inicialização (IV) é definido com todos os zeros o tempo todo, enquanto um IV deve ser sempre um número aleatório.

Esta vulnerabilidade perigosa tem 10 de 10 (CVSS v3.1) para gravidade do Common Vulnerability Scoring System (CVSS). Existem explorações de prova de conceito (POC) conhecidas e é muito provável que veremos ataques no mundo real em breve.

A Agência de Segurança Cibernética e Infraestrutura (CISA) emitiu uma diretiva de emergência ordenando que agências federais civis corrigissem ou desativassem imediatamente todos os servidores Windows afetados e alertou as organizações não governamentais a fazerem o mesmo. A Microsoft lançou o primeiro de dois patches em agosto de 2020 e eles precisam ser aplicados a todos os controladores de domínio.

Esta vulnerabilidade explora uma falha criptográfica no protocolo remoto de logon de rede do Active Directory (MS-NRPC) da Microsoft. Ela permite que os usuários façam logon em servidores que estejam usando o NT LAN Manager (NTLM). 

O maior problema com essa vulnerabilidade é que o MS-NRPC também é usado para transmitir certas alterações de conta, como senhas de contas de serviço de computador. Pensando em sua origem, é possível ver a razão para adicionar esse recurso. No entanto, a falta de validação na origem da solicitação para alterar essas senhas tornou-se um problema de segurança significativo.

Fica pior a partir daqui. A criptografia que foi adicionada ao MS-NRPC não foi escolhida com sabedoria. Em 1883, o criptógrafo holandês Aguste Kerckhoff publicou 2 ensaios, intitulados La Cryptographie Militaire (Criptografia Militar), delineando os 6 princípios-chave para projetar sistemas criptográficos. 

O mais conhecido deles, o Princípio de Kerckhoff, afirma que devemos manter nossa chave criptográfica em segredo. E não devemos confiar no sigilo do algoritmo para proteger nossos dados, mas usar algoritmos bem conhecidos, testados e comprovados.

O algoritmo originalmente usado para criptografar o processo de logon no Windows NT era 2DES, que agora sabemos que tem problemas. Hoje o MS-NRPC usa o Advanced Encryption Standard (AES), considerado a referência em criptografia. 

Além de escolher um algoritmo comprovado e forte, configurações adicionais devem ser selecionadas para garantir a resistência adequada. O MS-NRPC usa uma configuração obscura conhecida como Advanced Encryption Standard - Cipher Feed Back 8bit (AES-CFB8). O AES-CFB8 é obscuro porque não é bem conhecido e não foi bem testado. 

O uso de AES-CFB8 dentro do MS-NRPC tem um problema com o IV, que deveria ser um número aleatório, mas o MS-NRPC o fixou em um valor de 16 bytes de zeros. Isso é tudo menos aleatório. É previsível. A criptografia é frequentemente quebrada onde há previsibilidade.

Esta vulnerabilidade foi anunciada em setembro de 2020 por Tom Tervoort, um pesquisador holandês que trabalha para a Secura. A vulnerabilidade foi corrigida em agosto, mas foi somente depois que o pesquisador publicou seu relatório em setembro que começamos a ver POCs e outras atividades. 

O artigo de Tervoort detalha sua descoberta e o processo que levou a ela. Durante sua pesquisa, ele percebeu uma falta significativa de informações sobre o MS-NRPC. Intrigado, Tervoort buscou mais informações. 

Enquanto Tervoort estava inicialmente procurando por um ataque de person-in-the-middle, ele descobriu outra vulnerabilidade detalhada em CVE-2020-1424. Continuando sua pesquisa, ele identificou o que agora é conhecido como Zerologon. 

A parte crítica de sua descoberta é que a Microsoft implementou uma variação exclusiva de criptografia que é diferente de todos os outros protocolos RPC. Na época do Windows NT, as contas atribuídas a um computador não eram identificadas como um principal de primeira classe. Isso significava que a Microsoft não podia usar o Kerberos ou NTLM padronizado para autenticar contas de computador ou máquina. 

Como resultado, os desenvolvedores produziram uma alternativa. É incrivelmente difícil criar código e protocolos para criptografia que não sejam quebrados. Na verdade, pode levar um tempo incrivelmente longo antes que as falhas sejam descobertas, como é o caso aqui.

Esta vulnerabilidade permite que um criminoso assuma o controle de um controlador de domínio (DC), incluindo o DC raiz. Isso é feito alterando ou removendo a senha de uma conta de serviço no controlador. O agente malicioso pode simplesmente causar uma negação de serviço ou assumir o controle e possuir toda a rede.

Para que os invasores explorem esta vulnerabilidade, eles devem ser capazes de configurar uma sessão de protocolo de controle de transmissão (TCP) com um DC. Se eles estiverem fisicamente dentro da rede, eles podem estar na mesa de um usuário ou em uma porta aberta em um local como como uma sala de conferências. 

Esses exploits se qualificam como ataques internos – os ataques mais caros para uma empresa hoje. Eles podem ser estabelecidos de fora da rede, desde que possam obter um ponto de apoio em algum lugar para estabelecer a sessão TCP com o controlador.

Usando AES-CFB8 com um IV fixo de 16 bytes de zeros, a Tervoort descobriu que existe uma probabilidade de que uma em cada 256 chaves usadas criará um texto cifrado com um valor de zeros. Este é um número excessivamente pequeno de chaves para o invasor tentar criar um texto cifrado de zeros. Isso levaria apenas 2-3 segundos, no máximo, para que o computador do agente malicioso fizesse isso. 

Então, por que isso importa?

Se a máquina que se comunica com um controlador de domínio pertence a um usuário que está apenas trabalhando como de costume, não há problema real. Este texto criptografado mal construído ocorre, mas o processo de autenticação de rede funcionará. O problema só aparece quando um atacante tenta explorar o sistema.

No ataque comprovado por Tervoort, o agente malicioso primeiro teria que falsificar a credencial, ou senha, de um cliente na rede. Devido à má implementação do IV no MS-NRPC, são necessárias apenas 256 tentativas para acertar. 

Normalmente, a conta de um usuário seria bloqueada após três tentativas de adivinhar uma senha, mas o mesmo não se aplica a uma conta de computador ou máquina. Quando um computador está se conectando, não há limite definido para tentativas de senha incorreta, o que permite uma explosão contínua de tentativas em um curto espaço de tempo para os atacantes entrarem. Eles têm que encontrar uma das chaves que produza um texto cifrado totalmente zerado.

O que os atacantes podem fazer depois de falsificar a identidade de um computador na rede? Concluída a primeira etapa de falsificação de identidade, o invasor não saberia a chave de criptografia real da sessão. Os invasores só conseguiram falsificar sua identidade ao finalmente acertar uma das 256 chaves que produz um texto cifrado totalmente zerado. A próxima etapa é desativar a “assinatura e selagem”.

A assinatura e selagem RPC é o mecanismo usado para criptografia de transporte dentro do MS-NRPC. Este parece ser um processo lógico, pois devemos criptografar mais dados em trânsito. No MS-NRPC, no entanto, esse é um recurso opcional que é desativado simplesmente por não definir um sinalizador no cabeçalho de uma mensagem. 

Depois que a assinatura e a selagem são desativadas, as mensagens são enviadas em claro. Os criminosos poderiam realizar qualquer ação que desejassem, incluindo remover uma senha ou defini-la com outro valor. Haverá um patch da Microsoft em fevereiro de 2021 para exigir a assinatura e a selagem.

A terceira etapa é alterar a senha da conta que foi falsificada. O dispositivo mais eficaz a ser falsificado seria um servidor AD, de preferência até mesmo o servidor AD raiz. Para alterar a senha, os invasores usam a mensagem NetServerPasswordSet2 no MS-NRPC. 

É possível alterar uma senha simplesmente enviando o frame com a nova senha de preferência. A abordagem mais fácil é remover a senha ou defini-la com um valor em branco – o atacante agora pode fazer login por meio de um processo normal. 

Se o ataque tiver como alvo um computador aleatório na rede, esse computador não será capaz de fazer login. Portanto, a primeira consequência desse ataque é simplesmente um ataque de negação-de-serviço contra esse computador.

Existem agora vários exploits públicos de POC disponíveis. Se os servidores AD não forem corrigidos, grandes danos podem ser causados às empresas, pois o ataque pode ser usado para injetar ransomware em uma rede. 

Existem ferramentas para verificar se seus servidores são suscetíveis. Tom Tervoort e a Secura lançaram uma ferramenta no GitHub para verificar se seus controladores de domínio foram corrigidos ou descobrir se eles estão vulneráveis.

Em agosto de 2020, a Microsoft lançou um patch para CVE-2020-1472 (Zerologon). Todos os servidores AD (2008 R2 e superior) devem ser corrigidos o mais rápido possível. Mas o tempo médio entre o lançamento do patch e a implantação ainda é muito longo. 

Os pesquisadores afirmam que, em uma organização média, leva de 60 a 150 dias (cerca de 5 meses) após o lançamento de um patch para finalmente ser instalado. Isso é conhecido como Mean Time to Patch (MTTP). 

Infelizmente, o patch recém-lançado não é a solução universal para o problema. A Microsoft está planejando lançar uma segunda fase do patch, que incluirá os recursos de aplicação, no início de fevereiro de 2021.

Nesse momento, todos os dispositivos deverão usar o modo de canal seguro. Se não o fizerem, o acesso será negado. Se houver dispositivos não compatíveis mais antigos, eles terão que ser adicionados manualmente a uma política de grupo que permita explicitamente o acesso a dispositivos não compatíveis.

Virtual patching

Medidas de segurança tradicionais sempre devem ser aplicadas para observar contas e redes comprometidas, tráfego malicioso e outros indicadores de comprometimento. Os sistemas de prevenção de intrusão (IPS) e software antimalware para a rede e dispositivos host (todos os terminais) são essenciais para monitorar ransomware, vírus e outras ameaças. 

Os logs precisam ser coletados, centralizados e analisados por um SIEM. Depois que os logs são analisados, deve haver pessoas e processos em funcionamento para responder às indicações de comprometimento (IoC). Em seguida, uma equipe de resposta a incidentes com procedimentos e conhecimentos sólidos deve assumir para decidir a extensão do comprometimento e trabalhar para uma resolução.

Mesmo com a disponibilidade de um patch do fornecedor, muitos clientes ainda precisam de tempo para implantar os patches e implementar medidas de segurança adicionais para proteger seu ambiente. O conceito de patching virtual por meio de ferramentas como IPS oferece aos administradores e profissionais de segurança uma ferramenta adicional em seu arsenal. 

Ajuda a ganhar tempo importante para proteger suas redes. A correção do fornecedor ainda é a mitigação recomendada. As soluções de virtual patching ajudam a proteger as máquinas sem patch. Em muitas circunstâncias, eles também fornecem informações valiosas sobre as tentativas de exploração pós-patch em uma rede por meio de recursos como inspeção de log.

Os clientes da Trend Micro podem descobrir mais sobre as melhores práticas para lidar com a vulnerabilidade e como podemos ajudar visitando este artigo da base de conhecimento: https://success.trendmicro.com/solution/000270328