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.
As etapas envolvidas no processo de autenticação são as seguintes:
- Um desafio do cliente (oito bytes aleatórios) é enviado do cliente.
- Um desafio de servidor (oito bytes aleatórios) é enviado do servidor.
- 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.
- Tanto o cliente quanto o servidor utilizam a chave de sessão criada anteriormente e os desafios para criar credenciais de cliente e servidor.
- 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.
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.
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.
- A conexão de canal seguro Netlogon vulnerável pode ser controlada pela configuração de Política de Grupo “Controlador de domínio: Permitir conexões de canal seguro Netlogon vulneráveis” , que permite que apenas dispositivos autorizados usem a conexão.
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.