Alerta aos Domain Controllers! Vulnerabilidade concede acesso de domain admin

Uma vulnerabilidade crítica do Active Directory (CVE-2020-1472) tem sido manchete por ser um bug de elevação de privilégio mais notório, pois pode afetar todos os computadores e controladores de domínio em uma organização.  

Esta vulnerabilidade de alto risco, apelidada de Zerologon, oferece aos agentes de ameaças acesso fácil e instantâneo aos controladores de domínio sem exigir nenhum privilégio adicional. Esse ataque nem mesmo exige que o usuário seja autenticado; o usuário só precisa estar conectado à rede interna.

Qual é a vulnerabilidade do Zerologon?

É uma vulnerabilidade no Netlogon, o protocolo de autenticação que valida a identidade de um computador associado a um domínio para o controlador de domínio. É classificado como de alto risco (pontuação CVSS de 10) porque aproveitar essa vulnerabilidade significa que a conta do usuário comprometida nem precisa ser autenticada no domínio – ela apenas precisa estar conectada à rede interna.

Avaliando a vulnerabilidade

Antes de descrevermos como essa vulnerabilidade pode ser explorada, é importante que você entenda o Netlogon. Este protocolo não usa o mesmo esquema de autenticação que outros serviços RPC.

Em vez disso, ele usa um protocolo criptográfico personalizado para permitir que um cliente (um computador associado a um domínio) e um servidor (o controlador de domínio) provem um ao outro que conhecem um segredo compartilhado e, portanto, autenticam-se mutuamente.

Fonte: https://www.secura.com/

As etapas envolvidas no processo de autenticação são as seguintes:

  1. Um desafio do cliente (oito bytes aleatórios) é enviado do cliente.
  2. Um desafio de servidor (oito bytes aleatórios) é enviado do servidor.
  3. Uma chave de sessão é criada a partir do segredo da sessão (um hash da senha da conta do computador do cliente) e dos desafios.
  4. Tanto o cliente quanto o servidor utilizam a chave de sessão criada anteriormente e os desafios para criar credenciais de cliente e servidor.
  5. As credenciais junto com a chave de sessão são usadas para autenticar o usuário.

Onde ocorre a vulnerabilidade?

A vulnerabilidade é causada por um defeito no algoritmo de criptografia AES.

 Tanto o cliente quanto o servidor usam o método de criptografia AES-CFB8 para gerar valores de credencial, conforme mencionado na Etapa 4 acima. Tudo isso é implementado em uma função ComputeNetlogonCredential .

Esta criptografia AES-CFB8 foi implementada de forma insegura, criando esta vulnerabilidade.

  • A função ComputeNetlogonCredential aceita o desafio de 8 bytes (como nas etapas 1 e 2 acima) e executa uma transformação nele com a chave de sessão secreta para produzir a credencial do cliente (como na etapa 4).
  • O desafio de 8 bytes é anexado a 16 bytes aleatórios chamados de  vetor de inicialização (IV).
  • A criptografia AES é aplicada ao referido vetor. A condição XOR é usada para vincular o primeiro byte do valor do resultado ao primeiro byte da expressão de 8 bytes na qual o protocolo é usado. Essas etapas são repetidas até que a frase esteja totalmente codificada.

Onde está o problema?

A segurança AES-CFB8 depende do IV para ser escolhido aleatoriamente. Infelizmente, função ComputeNetlogonCredential define que este IV é fixo e deve sempre consistir em 16 bytes zero.

O que pode dar errado com um IV totalmente zero? Para uma em 256 chaves, a aplicação da criptografia AES-CFB8 a um texto simples totalmente zero resultará em um texto cifrado totalmente zero.

Fonte: https://www.secura.com/

O ataque de logon “zero”

  • Depois de trocar desafios com uma chamada NetrServerReqChallenge, o cliente então se autentica fazendo uma chamada NetrServerAuthenticate3.
  • Essa chamada tem um parâmetro denominado ClientCredential, que é calculado aplicando o ComputeNetlogonCredential ao desafio do cliente enviado na chamada anterior.
  • Não há nada que nos impeça de definir este desafio para oito zeros. Isso significa que para uma em 256 chaves de sessão, o ClientCredential correto também consistirá em oito zeros.

Fonte: https://www.secura.com/

Como as contas do computador não são bloqueadas após tentativas de login inválidas, podemos simplesmente tentar várias vezes (256 em média) até que acertemos essa chave e a autenticação seja bem-sucedida. Todo esse processo leva apenas cerca de 10 segundos na prática. 

Com esse método, podemos fazer login como qualquer computador no domínio. Isso inclui controladores de domínio de backup e até mesmo o próprio controlador de domínio de destino!

 Usando a chamada NetServerPasswordSet2 , podemos redefinir a senha de qualquer sistema – tudo usando o IV totalmente zero!

 Mitigando a vulnerabilidade Zerologon 

  • Aplique o patch relevante da Microsoft o mais rápido possível.
  • Use este script para verificar se todos os seus controladores de domínio foram corrigidos. Certifique-se de que apenas usuários autorizados executem este script e que ele não seja usado por agentes mal-intencionados para identificar controladores de domínio não corrigidos para aproveitar a vulnerabilidade Zerologon.
  • Para dispositivos não Windows, uma conexão de canal seguro Netlogon vulnerável pode ser usada.

Além das correções acima, você pode monitorar esses IDs de evento: 

  • Rastreie as tentativas de logon bem-sucedidas em servidores usando Event ID 4624 com Logon Type 3 (logon de rede) seguido por Event ID 4742 com TargetUsername “ANONYMOUS LOGON”.
  • O ID de evento 5829 é gerado sempre que uma conexão de canal seguro Netlogon vulnerável é permitida.

As ferramentas ofensivas de código aberto são freqüentemente usadas com o ataque para obter acesso mais profundo ou escalar privilégios.

  • As credenciais podem ser descarregadas da memória local (LSASS.exe).
    • Detecção: sysmon EventID = 10 com TargetImage = * lsass.exe (GrantedAccess = 0x1010 OU GrantedAccess = 0x1410)
  • Mimikatz pode ser usado com o Netlogon para obter acesso aos hashes de senha dos usuários do domínio.
    • Detecção: sysmon EventID = 7 & ImageLoaded = * WinSCard.dll | * cryptdll.dll | * hid.dll | * samlib.dll | * vaultcli.dll

Detectando o ataque Zerologon com ManageEngine Log360

O ManageEngine Log360 é uma solução completa que ajuda a manter a segurança da rede. O mecanismo de correlação em tempo real do Log360 correlaciona eventos de segurança distintos, verifica se eles são indicadores do ataque Zerologon e alerta os usuários autorizados em tempo real se uma tentativa de ataque for detectada.

Além disso, o Log360 pode remediar automaticamente esse ataque executando ações de mitigação, como encerrar a sessão do usuário suspeito, desligar dispositivos ou até mesmo executar scripts com base em uma ação personalizada.

Clique no botão abaixo e inicie sua avaliação gratuita de 30 dias do Log360, contando sempre com o apoio da equipe ACSoftware.

ACSoftware revenda e distribuidora ManageEngine no Brasil. Fone / WhatsApp (11) 4063 9639.

PodCafé da TI – Podcast, Tecnologia e Cafeína.

Deixe um comentário

Do NOT follow this link or you will be banned from the site!