Vulnerabilidade no TLS que permite a descoberta de chaves para conexões baseadas em cifras DH

Divulgado informações sobre o novo vulnerabilidades (CVE-2020-1968) no protocolo TLS, codinome
guaxinim e permitir, em raras circunstâncias, determinar uma chave primária preliminar (pré-mestre), que pode ser usada para descriptografar conexões TLS, incluindo HTTPS, ao interceptar tráfego de trânsito (MITM). Nota-se que o ataque é muito difícil de ser implementado na prática e é mais de natureza teórica. Para realizar um ataque, é necessária uma configuração específica do servidor TLS e a capacidade de medir com muita precisão o tempo de processamento do servidor.

O problema está presente diretamente na especificação TLS e afeta apenas conexões que utilizam cifras baseadas no protocolo de troca de chaves DH (Diffie-Hellman, TLS_DH_*"). Com as cifras ECDH o problema não ocorre e elas permanecem seguras. Apenas os protocolos TLS até a versão 1.2 são vulneráveis; o TLS 1.3 não é afetado pelo problema. A vulnerabilidade ocorre em implementações TLS que reutilizam a chave secreta DH em diferentes conexões TLS (esse comportamento ocorre em aproximadamente 4.4% dos servidores Alexa Top 1M).

No OpenSSL 1.0.2e e versões anteriores, a chave primária DH é reutilizada em todas as conexões do servidor, a menos que a opção SSL_OP_SINGLE_DH_USE seja explicitamente definida. Desde o OpenSSL 1.0.2f, a chave primária DH só é reutilizada ao usar cifras DH estáticas ("DH-*", por exemplo, "DH-RSA-AES256-SHA"). A vulnerabilidade não aparece no OpenSSL 1.1.1, pois esta ramificação não usa uma chave primária DH e não usa cifras DH estáticas.

Ao usar o método de troca de chaves DH, ambos os lados da conexão geram chaves privadas aleatórias (doravante denominadas chave “a” e chave “b”), com base nas quais as chaves públicas (ga mod p e gb mod p) são calculadas e enviadas. Depois que cada parte recebe as chaves públicas, uma chave primária comum (gab mod p) é calculada, que é usada para gerar chaves de sessão. O ataque Raccoon permite determinar a chave primária por meio de análise de canal lateral, com base no fato de que as especificações TLS até a versão 1.2 exigem que todos os bytes nulos iniciais da chave primária sejam descartados antes dos cálculos que a envolvem.

Incluir a chave primária truncada é passada para a função de geração de chave de sessão, que é baseada em funções hash com atrasos diferentes ao processar dados diferentes. Medir com precisão o tempo das operações de chave realizadas pelo servidor permite ao invasor determinar pistas (oráculo) que permitem julgar se a chave primária começa do zero ou não. Por exemplo, um invasor poderia interceptar a chave pública (ga) enviada pelo cliente, retransmiti-la ao servidor e determinar
se a chave primária resultante começa do zero.

Por si só, definir um byte da chave não dá nada, mas ao interceptar o valor “ga” transmitido pelo cliente durante a negociação da conexão, o invasor pode gerar um conjunto de outros valores associados a “ga” e enviá-los para o servidor em sessões de negociação de conexão separadas. Ao gerar e enviar valores “gri*ga”, um invasor pode, através da análise de alterações nos atrasos na resposta do servidor, determinar os valores que levam ao recebimento de chaves primárias começando do zero. Tendo determinado tais valores, o atacante pode criar um conjunto de equações para soluções problemas de números ocultos e calcule a chave primária original.

Vulnerabilidade no TLS que permite a descoberta de chaves para conexões baseadas em cifras DH

Vulnerabilidades OpenSSL atribuído baixo nível de perigo, e a correção foi reduzida a mover as cifras problemáticas “TLS_DH_*” na versão 1.0.2w para a categoria de cifras com nível de proteção insuficiente (“cifras SSL fracas”), que está desabilitada por padrão . Os desenvolvedores da Mozilla fizeram a mesma coisa, desligado na biblioteca NSS usada no Firefox, os conjuntos de criptografia DH e DHE. A partir do Firefox 78, as cifras problemáticas estão desativadas. O suporte do Chrome para DH foi descontinuado em 2016. As bibliotecas BearSSL, BoringSSL, Botan, Mbed TLS e s2n não são afetadas pelo problema porque não suportam cifras DH ou variantes estáticas de cifras DH.

Problemas adicionais são anotados separadamente (CVE-2020-5929) na pilha TLS de dispositivos F5 BIG-IP, tornando o ataque mais realista. Em particular, foram identificados desvios no comportamento dos dispositivos na presença de um byte zero no início da chave primária, que pode ser usado em vez de medir a latência exata dos cálculos.

Fonte: opennet.ru

Adicionar um comentário