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:
- 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.
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.
- 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.
