Uma vulnerabilidade no TLS permite a definição da chave para conexões baseadas em cifras DH

Revelado informações sobre o novo no aplicativo para Windows, que permitia ao usuário elevar seus privilégios no sistema para administrador (a vulnerabilidade foi causada pela interação inadequada entre o cliente GUI sem privilégios e o serviço de sistema). (CVE-2020-1968) no protocolo TLS, codinome
Raccoon e que permite, em circunstâncias raras, identificar a chave primária preliminar (pre-master), que pode ser usada para decifrar conexões TLS, incluindo HTTPS, ao interceptar tráfego transitório (MITM). Observa-se que o ataque é muito difícil de ser implementado na prática e tem mais caráter teórico. Para realizar o ataque, é necessária uma configuração específica do servidor TLS e a capacidade de medir com precisão o tempo de processamento das operações pelo 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 cifras ECDH, o problema não se manifesta e elas permanecem seguras. Apenas protocolos TLS até a versão 1.2, inclusive, são vulneráveis; o protocolo TLS 1.3 não é suscetível ao problema. A vulnerabilidade se manifesta nas implementações de TLS que reutilizam a chave secreta DH em diferentes conexões TLS (esse comportamento é observado em aproximadamente 4,4% dos servidores na classificação Alexa Top 1M).

No OpenSSL 1.0.2e e em 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. A partir do OpenSSL 1.0.2f, a chave primária DH é reutilizada apenas ao usar cifras DH estáticas (‘DH-*’, como ‘DH-RSA-AES256-SHA’). No OpenSSL 1.1.1, a vulnerabilidade não se manifesta, pois nesta versão não é utilizada a chave primária DH e não são aplicadas cifras DH estáticas.

Ao usar o método de troca de chaves DH, ambas as partes da conexão geram chaves privadas aleatórias (chave ‘a’ e chave ‘b’), a partir das quais são calculadas e enviadas as chaves públicas (ga mod p e gb mod p). Após receber as chaves públicas, cada parte calcula a chave primária compartilhada (gab mod p), que é usada para formar as chaves de sessão. O ataque Raccoon permite determinar a chave primária através da análise de informações de canais secundários, com base no fato de que as especificações do TLS até a versão 1.2 determinam que todos os bytes iniciais nulos da chave primária devem ser descartados antes das operações que envolvem a chave.

Incluindo a chave primária reduzida que é passada para a função de geração da chave de sessão, baseada em funções de hash com diferentes latências ao processar diferentes dados. A medição exata do tempo das operações realizadas pelo servidor com a chave permite que um atacante identifique dicas (oracle) que possibilitam concluir se a chave primária começa com zero ou não. Por exemplo, o atacante pode interceptar a chave pública enviada pelo cliente (ga), reenviá-la ao servidor e determinar
se a chave primária resultante começa com zero.

Definir um byte da chave por si só não fornece informações, mas ao interceptar o valor "ga" transmitido durante a negociação da conexão pelo cliente, o atacante pode formar um conjunto de outros valores relacionados a "ga" e enviá-los ao servidor em sessões separadas de negociação de conexão. Ao gerar e enviar os valores "gri*ga", o atacante pode, através da análise da variação de latência na resposta do servidor, determinar os valores que resultam em chaves primárias que começam com zero. Ao identificar esses valores, o atacante pode criar um conjunto de equações para Um mesmo o problema dos números ocultos e calcular a chave primária original.

No OpenSSL, as vulnerabilidades recebeu têm baixo nível de risco, e a correção consistiu em mover, na versão 1.0.2w, os cifradores problemáticos "TLS_DH_*" para a categoria de cifradores desativada por padrão ("weak-ssl-ciphers"). De forma semelhante, os desenvolvedores da Mozilla desativaram na biblioteca NSS, usada no Firefox, os conjuntos de cifradores DH e DHE. A partir do Firefox 78, os cifradores problemáticos estão desativados. No Chrome, o suporte a DH foi encerrado ainda em 2016. As bibliotecas BearSSL, BoringSSL, Botan, Mbed TLS e s2n não são vulneráveis ao problema, pois não suportam cifradores DH ou variantes estáticas de cifradores DH.

Adicionalmente, são mencionados problemas (CVE-2020-5929) no stack TLS dos dispositivos F5 BIG-IP, tornando o ataque mais realista. Em particular, foram identificadas discrepâncias no comportamento dos dispositivos na presença de um byte nulo no início da chave primária, que podem ser utilizadas em vez de medir o tempo exato de latência durante os cálculos.

Fonte: opennet.ru