Zerologon – hacking servidores Windows com um monte de zeros

Views: 687

O grande e mau inseto da semana se chama Zerologon.

Como você provavelmente pode dizer pelo nome, ele envolve o Windows – todo mundo fala sobre login, mas no Windows você sempre está muito definitivamente conectado – e é um bypass de autenticação, porque permite que você saia com o uso de uma senha de comprimento zero.

Você também verá isso referido como CVE-2020-1472, e a boa notícia é que ele foi corrigido na atualização de agosto de 2020da Microsoft.

Em outras palavras, se você pratica a remenda adequada, você não precisa entrar em pânico. (Sim, essa é uma dica indisfarmável: se você ainda não remendou seus servidores Windows a partir de agosto de 2020, por favor, vá e faça isso agora, para o bem de todos, não apenas os seus.)

No entanto, Zerologon é uma história fascinante que nos lembra a todas as duas lições muito importantes, ou seja:

1. Criptografia é difícil de acertar.
2. Erros criptográficos podem levar anos para serem detectar.

Os detalhes sangrentos do bug não foram divulgados pela Microsoft em agosto de 2020, mas pesquisadores da empresa holandesa de cibersegurança Secura investigaram o componente afetado do Windows, Netlogon, e descobriram um monte de buracos criptográficos sérios na versão não reparada, e como explorá-los.

Neste artigo, não vamos construir um ataque ou mostrar como criar pacotes de rede para explorar a falha, mas vamos olhar para os problemas criptográficos que ficaram despercebidos no Protocolo Remoto Microsoft Netlogon por muitos anos.

Afinal, aqueles que não se lembram da história estão condenados a repeti-la.“Com o Sophos, não tivemos infecções por ransomware”Inicie um teste gratuito de 30 dias do Sophos Intercept X Endpoint em menos de 2 minutos.Baixe uma avaliação gratuita

Autenticação via Netlogon

Netlogon é um protocolo de rede que, em suas próprias palavras, “é uma interface de chamada de procedimento remoto (RPC) que é usada para autenticação de usuários e máquinas em redes baseadas em domínio”.

Com 280 páginas, a Especificação do Protocolo Remoto Netlogon – é uma especificação aberta nos dias de hoje, não proprietária da Microsoft – é muito menor que o Bluetooth, mas muito mais longa do que qualquer equipe de programação pode receber durante um período de meses ou anos, muito menos dias ou semanas.

Seu comprimento vem em parte do fato de que muitas vezes existem muitas maneiras diferentes de fazer a mesma coisa, às vezes com vários algoritmos de recuo diferentes que foram mantidos para garantir a retrocompatibilidade com dispositivos mais antigos.

Ironicamente, talvez, a Seção 5, Considerações de Segurança,tem apenas duas partes curtas: uma subseção de uma página intitulada Considerações de Segurança para Implementadores,e uma breve (embora reconhecidamente útil) tabela chamada Índice de Parâmetros de Segurança que se liga a várias seções importantes na especificação.

Começando com Netlogon

Um computador cliente que deseja se comunicar com um servidor Netlogon, como um controlador de domínio do Windows, começa enviando oito bytes aleatórios (o que muitas vezes é chamado de nonce, abreviação de número usado uma vez) para o servidor.

O servidor responde com 8 bytes aleatórios próprios, conforme explicado na seção 3.1.4.1, Negociação de Sessão-Chave:


   REQUEST --> ClientChallenge (8 random bytes, e.g. 452fdbfd2e38b9e0) -->

   
     REPLY <-- ServerChallenge (8 random bytes, e.g. 7696398fe5417372) <--


Como mostrado acima, a Microsoft refere-se a essas nonces como (CC) e (SC), respectivamente, se você quiser combinar essa discussão com o protocolo documentataion.ClientChallengeServerChallenge

Ambos os lados, em seguida, embaralhar as duas cordas aleatórias juntos com um segredo compartilhado para inventar uma chave de criptografia única, conhecida como (SK).SessionKey

Em uma rede Windows, o componente secreto é a senha de domínio do computador de onde você está se conectando.

No cliente, isso é armazenado com segurança pelo Windows no registro; no controlador de domínio, ele é armazenado no banco de dados Active Directory.

Esta mistura é feita usando o hash criptográfico chaveado chamado HMAC-SHA256.SessionKey

O algoritmo é especificado na seção 3.1.4.3.1, AES Session-Key, e em pseudocódigo ele se parece com este:

Supondo que o cliente que solicita acesso tenha a mesma senha armazenada localmente como o servidor Netlogon tem em registro centralmente, e dado que cada lado já disse ao outro seu desafio aleatório de 8 byte, ambos os lados agora deveriam ter chegado ao mesmo valor único (SK) para garantir o resto de sua comunicação.SessionKey

Esta configuração de chave de sessão evita o uso da senha secreta diretamente na criptografia do tráfego do Netlogon e garante uma chave única para cada sessão, na qual ambas as partes injetam sua própria aleatoriedade. (Esta é uma abordagem comum: configurar uma conexão sem fio WPA-2 usando uma chave pré-compartilhada segue um processo semelhante.)

Em teoria, o servidor poderia assumir cegamente que o cliente conhece a senha real simplesmente aceitando chamadas de função criptografadas imediatamente; se o cliente tivesse trapaceado até agora usando uma senha inventada, as solicitações não seriam descriptografadas corretamente e o ardil falharia.

A boa prática, no entanto, diz que cada extremidade deve verificar a outra primeiro, por exemplo, criptografando uma sequência de teste conhecida que a outra extremidade pode validar, e é isso que acontece a seguir.

Obviamente, o cliente não pode compartilhar a chave da sessão diretamente porque isso permitiria que qualquer outra pessoa na rede farejasse e seqüestrásse a sessão.

Em vez disso, o cliente prova que conhece a chave da sessão criptografando o que se comprometeu no início, usando o que ele apenas calculou.ClientChallengeSessionKey

A Microsoft chama isso de “Computação de Credenciais” do Netlogon,detalhado na seção 3.1.4.4.1:

Na outra ponta, o servidor faz a mesma coisa ao contrário, e verifica que o original sai corretamente quando o texto cifrado é descriptografado com a tecla de sessão.ClientChallenge

Neste ponto, parece que um cliente impostor está preso.

Sem a senha secreta certa, que você só pode obter já tendo acesso em nível de administrador a um computador confiável na rede, você não terá a mesma chave de sessão que o servidor.

Sem a chave de sessão certa, você não produzirá uma versão criptografada da sua sequência aleatória original de 8 byte que o servidor aceitará para autenticar você.

Uma fenda na armadura

Neste ponto, se você está interessado em criptografia, você provavelmente está se perguntando: “O que na terra é o algoritmo de criptografia apelidado no pseudocódigo acima?”AES-128-CFB8

Vamos investigar.

AES, abreviação de Advanced Encryption Standard, soa como uma boa escolha porque atualmente é aceito como um algoritmo forte sem falhas de segurança conhecidas.

Além disso, um tamanho-chave de 128 bits é atualmente considerado satisfatório porque levaria muito tempo para experimentar todas as possíveis 2¹²⁸ chaves, mesmo se você aproveitasse todo o poder de computação do mundo para si mesmo.

Para registro: a AES não usa nenhum cálculo interno que possa ser acelerado com os chamados algoritmos quânticos,por isso é considerado seguro pós-quântico. Mesmo que um computador quântico verdadeiramente poderoso fosse construído amanhã, não seria de qualquer uso especial, até onde sabemos, em quebrar AES mais rápido do que podemos com computadores regulares hoje.

Mas algoritmos como o AES podem ser usados em muitos modos diferentes, e nem todos eles são adequados para todos os fins.

O modo mais conhecido, que você pode pensar como “criptografia reta”, é chamado , e embaralha 16 bytes de entrada por vez, produzindo diretamente 16 bytes de saída.AES-128-ECB

Note que simplificamos esses diagramas fingindo que o AES-128 funciona em 4 bytes (32 bits) de cada vez em vez de 16 bytes (128 bits), mas os princípios subjacentes ainda são perfeitamente claros:

BCE significa Livro de Códigos Eletrônicos, porque a cifra neste modo realmente funciona como um livro de códigos inimaginavelmente grande.

O apelido do livro de códigos é inteiramente teórico. Na prática, você precisaria de um codebook diferente para cada uma das 2¹²⁸ chaves diferentes, com cada livro listando cada um dos valores de criptografia para cada uma das 2¹²⁸ diferentes strings de entrada de 16 byte. E você precisaria de mais 2¹²⁸ (são 300 milhões milhões milhões de milhões) livros de código para listar todas as descriptografias possíveis, também, se você já teve espaço ou tempo para desembaraçá-lo o que você havia criptografado anteriormente.

Infelizmente, a simplicidade do modo codebook também é uma fraqueza, porque sempre que houver texto repetido em um dos blocos de entrada, você saberá porque você terá uma repetição no texto cifrado, também:

Na melhor das hipóteses, o BCE vaza se há algum padrão na entrada, algo que um algoritmo de criptografia deve esconder.

Na pior das hipóteses, significa que se você descobrir qual era o texto simples em uma parte da entrada – um título de capítulo, por exemplo, ou parte de um endereço Bitcoin – você será automaticamente capaz de descriptografar esse texto em todos os outros lugares que ele aparece.

Existem várias soluções para usar algoritmos de criptografia baseados em blocos para que eles não revelem padrões repetidos, e uma delas é o modo Cipher Feedback (CFB), que funciona assim:

Em vez de criptografar os blocos de texto simples com AES cada vez, você criptografa o último bloco de texto cifrado em vez disso, e, em seguida, XOR que “keystream” com o próximo bloco de texto simples.

Dessa forma, mesmo que você tenha dois blocos de texto simples idênticos em uma fileira, o texto cifrado não se repetirá.

Claro, não há bloco de texto cifrado para usar no início, então o modo requer não apenas uma chave de 16 bytes para o motor de criptografia, mas também um vetor de inicialização (IV) de 16 bytes como uma entrada inicial para começar o keystream.AES-128-CFB

Observe que o IV pode, e geralmente é, compartilhado junto com o texto cifrado – o IV não precisa ser mantido em segredo, porque o sigilo da criptografia é fornecido pela chave que controla o mecanismo de criptografia AES.

No entanto, um vetor de inicialização de CFB deve ser escolhido aleatoriamente, e nunca deve ser reutilizado, especialmente com a mesma chave AES.

CFB8 explicou

Uma desvantagem que a AES-ECB e a AES-CFB têm em comum é que até que você tenha um bloco completo de 16 byte de entrada, você não pode produzir qualquer saída, porque eles não podem trabalhar em blocos parciais – o AES foi projetado para misturar e trocar e trocar pedaços de 128 bits de cada vez.

Isso também significa que você está preso se você tiver algum bytes de sobra no final, por exemplo, se você tem 67 bytes para criptografar, que é 4×16 + 3.

Você precisa descobrir uma maneira de pad out o último bloco para o tamanho certo, e, em seguida, descobrir de forma confiável se havia algum bytes extra adicionado sobre essa necessidade de ser despojado quando você descriptografar os dados.

Uma solução para isso é o AES-CFB8, um modo que nunca ouvimos falar de ninguém que usasse na vida real antes, mas que foi projetado para usar um ciclo completo de mistura de AES de 128 bits para cada byte de entrada, para que você possa criptografar até mesmo apenas um único caractere sem qualquer preenchimento.

Em vez de criptografar o último bloco completo de texto cifrado para criar o próximo bloco completo de dados de keystream, você usa apenas o primeiro byte do keystream cada vez e XOR-o com um byte de texto simples em vez de um bloco de texto simples de 16 byte.

Em seguida, você corta o byte keystream que acabou de usar e adiciona o novo byte de texto cifrado no final do keystream, dando-lhe um bloco completo de dados para criptografar para gerar o próximo byte keystream:

Netlogon CFB8 considerado prejudicial

Infelizmente, a maneira como a Netlogon usa é significativamente menos segura do que deveria ser.AES-128-CFB8

Os pesquisadores da Secura detectaram o problema muito rapidamente ao analisar a documentação da Microsoft, onde o algoritmo não é definido genericamente (como listamos acima), mas dado de forma perigosamente simplificada.

A seção 3.1.4.4.1 especifica o processo de Credencial AES [Computação]da seguinte forma:


   If AES support is negotiated between the client and the server, 
   the Netlogon 
credentials are computed using the AES-128 encryption 
   algorithm in 8-bit CFB 
mode with a zero initialization vector. 
   [Sk below is short for SessionKey]

   

      ComputeNetlogonCredential(Input, Sk, Output)
      
         SET IV = 0
      
         CALL AesEncrypt(Input, Sk, IV, Output)


Você provavelmente já viu o erro criptográfico: “as credenciais são computadas […] com vetor de inicialização zero.”

Como já mencionamos, os IVs devem ser escolhidos aleatoriamente, e usados apenas uma vez com qualquer chave – na verdade, é por isso que muitas vezes são referidos como nonces, para números usados once.

Mas há um problema ainda maior com um iv zero no modo CFB8, como Secura descobriu.

Você pode visualizar o problema se usar um IV de zero mais um bloco de bytes de texto simples:

Como o AES é uma cifra de alta qualidade sem vieses estatísticos conhecidos, você pode colocar qualquer entrada e criptografá-la com qualquer tecla, e a chance de cada bit individual na saída ser zero (ou um) é de 50%.

O valor de cada bit de saída é como um lançamento de moeda digital.

Assim, a chance do primeiro byte de saída ser zero é a mesma que a chance de que os primeiros 8 bits de saída são todos zero, que é 50% × 50% × 50% … oito vezes mais (50% é apenas outra forma de escrever 0,50, que é o mesmo que 1/2).

50%⁸ é 2^-8, ou 1/256.

Lembre-se dessa probabilidade.

No diagrama acima, assumimos que o primeiro byte de saída realmente saiu como zero, e você pode ver que se isso acontecer, todo o processo de criptografia essencialmente fica “bloqueado” em um estado tudo-zero.

O byte keystream (preto) sai como 00, então quando você XOR com o primeiro byte de texto simples (rosa) de 00 você ganha um texto cifrado byte (vermelho) de 00.

Então, quando você cortar os primeiros 00 da extremidade esquerda do IV (branco) e anexar o novo texto cifrado 00 no final, você está de volta onde você começou, com outro all-zero IV e um buffer de texto simples restante de todos os zeros.

Quando você criptografa o “novo” IV com a chave, você recebe exatamente o mesmo resultado de antes, porque todas as suas entradas são as mesmas novamente, e sai outro byte keystream de 00, que XORs com o próximo texto simples 00 para produzir outro texto cifrado byte de 00, que se alimenta de volta para o IV para torná-lo zero novamente.

Como enganar o Netlogon

Os pesquisadores da Secura rapidamente perceberam o que aconteceria se tentassem autenticar para um servidor Netlogon várias vezes usando uma nonce composta por 8 zeros.ClientChallenge

Aproximadamente uma vez em cada 256 vezes o servidor inventaria aleatoriamente uma chave de sessão para a qual a versão corretamente criptografada de seu tudo-zero …ClientChallenge

… seria em si todos os zeros.

Em outras palavras, submetendo um de 0000000000000000000 e, em seguida, também cegamente também submetendo uma Computação Credencial Netlogon (ver acima) de 0000000000000000000000000000, eles acertariam a calculadoe credencial por acaso 1/256 da época, mesmo que eles não tivessem ideia de qual deveria ser o valor certo porque eles não tinham ideia de qual senha secreta usar.ClientChallengeSessionKey

Simplificando, 1/256 do tempo, eles acabaram em uma situação onde eles sempre poderiam produzir dados corretamente criptografados para transmitir ao servidor, sem ter uma pista de qual era a senha ou chave de sessão, desde que eles só precisassem criptografar zeros!

Melhor ainda, o servidor os notificaria automaticamente quando acertassem o jackpot aceitando sua apresentação credencial.

Certamente isso não é explorável?

Agora você provavelmente está pensando: “Qual é a chance de que cada vez que eles precisavam enviar um token de autenticação criptografada ou para fornecer dados de senha criptografados, eles só precisariam criptografar zeros?”

Também nos perguntamos isso, mas nossos intrépidos pesquisadores encontraram uma maneira.

Uma das funções de senha do Netlogon (seção 3.4.5.2.5), pode ser chamada remotamente a partir de uma sessão do Netlogon que já passou pela verificação de Cálculo de Credenciais da Netlogon.NetrServerPasswordSet2

Esta função, que faz o que seu nome sugere e altera a senha do servidor, exige que o chamador criptografe corretamente dois pedaços de dados:

• O original , tratado como um número de 64 bits, com o tempo atual (no que é conhecido como “Posix seconds” ou Forma de época Unix) adicionado a ele. Esses dados são usados como uma verificação de autenticação para garantir que ainda seja o mesmo programa cliente tentando fazer a alteração de senha.ClientChallenge
• Um buffer de 516 bytes que especifica a nova senha, formatado como (512-N) bytes de dados aleatórios, seguido por N bytes especificando a senha, seguido pelo comprimento da senha N expresso como um número de 4 bytes.

Os zeros são todos, porque isso era necessário para começar a exploração em primeiro lugar, mas o tempo atual em Posix segundos é algo próximo a isso:ClientChallenge


   $ date --utc +%s

   1600300026


Posix denota o número de segundos desde o início da época unix, que começou, por definição, em 1970-01-01T00:00:00Z, data agora mais de 50 anos no passado.

Os pesquisadores se encontraram nos chifres de um dilema: o era zero, mas o tempo não era, então a soma desses dois números não poderia ser zero, e, portanto, não criptografaria a zero…ClientChallenge

… e, portanto, os invasores precisariam da chave de sessão original, afinal, e para obter a chave de sessão, eles precisariam saber uma senha válida para um computador adequado na rede.

O que é que eu faço?

Bem, os pesquisadores fingiram que era 1970 de novo, usaram um tempero de zero adicionado a zero…ClientChallenge

… e o servidor não se importou – aparentemente não havia verificação para ver se o horário era décadas no passado.

É claro que os bytes 516 all-zero que os pesquisadores agora precisavam fornecer no buffer de senha criptografado os forçaram a especificar um comprimento de senha de zero, o que você pode pensar que seria proibido pelo servidor.

Mas os pesquisadores tentaram mesmo assim…

… e o servidor também não se importou com isso, definindo sua própria senha do Active Directory para <nenhuma senha em tudo>.

O que vem depois?

Felizmente – ou talvez um pouco menos infeliz – a mudança de senha que eles foram capazes de fazer não redefiniu a senha de login real do servidor, de modo que os pesquisadores não poderiam simplesmente fazer login diretamente e assumir o servidor através de um desktop Windows convencional.

No entanto, eles relataram que, alterando a senha do Active Directory do próprio controlador de domínio, eles foram capazesde:

extrair todos os hashes do usuário do domínio através do protocolo DRS (Domain Replication Service, serviço de replicação de domínio). Isso inclui hashes de administrador de domínio (incluindo a tecla ‘krbtgt’, que pode ser usada para criar bilhetes dourados) que podem ser usados para fazer login no Controlador de Domínio (usando um ataque padrão de passe-o-hash) e atualizar a senha do computador armazenada no registro local dos Controladores de Domínio.

Em outras palavras, compromisso completo de rede.

Tudo por causa de uma especificação criptográfica simplificada que envolvia o pecado cardeal de um vetor de inicialização de zero todas as vezes.

É claro que essa falha foi agravada por vários outros descuidos programáticos onde uma atenção mais rigorosa à segurança e à correção poderia ter evitado este ataque, incluindo:

• Permitindo um total de zero em primeiro lugar. Presumimos que a causa mais provável de um buffer de zero no início do processo Netlogon seria um programa de clientes iniciais ou de buggy incorretamente, então o rejeitaríamos como precaução de qualquer maneira.ClientChallenge
• Permitindo uma senha de comprimento zero. Dado que o Windows já tem um mecanismo seguro para armazenar segredos compartilhados, e depende dele fortemente de qualquer maneira, parece desnecessário permitir senhas em branco, mesmo para contas onde nenhum humano é esperado para fazer logon.
• Permitindo um campo de autenticação baseado em data no qual o data-hora não poderia estar correto. Estaríamos inclinados a tratar isso como um aviso de um cliente de buggy ou uma tentativa de fazer um truque de segurança.

O que é que eu faço?

Este bug abre uma séria brecha de segurança para qualquer pessoa que já esteja dentro de sua organização, e talvez até mesmo para pessoas de fora, dependendo da topologia da sua rede.

Se você ainda não aplicou o patch de agosto de 2020, você precisa fazê-lo – você não está apenas se decepcionando, você está decepcionando todos os outros também, tornando sua rede um alvo mais fácil para bandidos e, portanto, tornando mais provável que você será a fonte de problemas de segurança para outras pessoas.

Além disso:

• Não pegue atalhos criptográficos, como escolher um modo de criptografia conveniente para o seu aplicativo, mas depois tomar liberdades com a forma como você usá-lo, porque isso é conveniente para seus programadores.
• Programe-se defensivamente sempre que você estiver aceitando dados não confiáveis, especialmente se os dados podem ser facilmente verificados por valores obviamente forjados ou incorretos, como datas de 50 anos no passado.
• Retire peças antigas de seus produtos ou especificações assim que puder depois que as melhores estiverem disponíveis. Embora a exploração neste caso se baseou em partes atualizadas do protocolo Netlogon, como o uso de AES em vez de recuar para algoritmos mais antigos, você pode argumentar que esse bug poderia ter sido encontrado muito mais cedo se a especificação do protocolo não fosse sobrecarregada com tantas maneiras alternativas de fazer todo tipo de verificações relacionadas à segurança.

Mas a grande coisa a se lembrar aqui é: patch cedo, patch muitas vezes.

FONTE: NAKED SECURITY