Se exploradas, essas falhas podem permitir que invasores obtenham acesso não autorizado a informações confidenciais ou geralmente causem problemas
Alguns dias atrás. Foi anunciada a notícia de que un equipa de pesquisadores da Universidade da Califórnia em San Diego mostrou o capacidade de recriar a sua chaves Host RSA privado um servidor SSH através a análise passiva do tráfego SSH.
A pesquisa publicada mostrar que quando assinaturas digitais são usadas baseado no algoritmo RSA em SSH, une-osques que usam o método Lattice (Ataque de falha) prevenir recriar la clave RSA privado eles são adequado prevenir assinaturas digitais em caso de uma vazar de Programas ou hardware durante o processo de cálculo de assinatura. O essência do método é que al comparar assinaturas digitais RSA corretas e incorretas, você pode para determinar o maior comum divisor, gerando assim uno dos números primos usados prevenir gerar la clave.
A criptografia RSA é baseada na operação de exponenciação de um grande número, enquanto a chave pública contém o módulo e o grau. O módulo é formado por dois números primos aleatórios, que apenas o dono da chave privada conhece. O ataque pode ser aplicado a implementações RSA usando o teorema do resto chinês e esquemas de preenchimento determinísticos, como PKCS#1 v1.5.
Um ataque pode ser realizado em servidores em que, devido a uma combinação de circunstâncias ou ações do invasor, Podem ocorrer falhas durante o cálculo da assinatura digital ao estabelecer uma conexão SSH. As falhas podem ser de software (execução incorreta de operações matemáticas, corrupção de memória) ou de hardware (erros na operação de NVRAM e DRAM ou falhas durante quedas de energia).
Uma das opções para estimular falhas poderiam ser os ataques da classe RowHammer, que entre outras coisas, permite remotamente ou ao processar código JavaScript em um navegador conseguir distorção do conteúdo de bits de memória individuais durante leitura cíclica intensiva de dados de vizinhos. células de memória. Outra opção para causar falhas poderia ser a exploração de vulnerabilidades que causam buffer overflows e corrupção de dados com chaves na memória.
Para realizar um ataque, basta monitorar passivamente as conexões legítimas ao servidor SSH até que uma assinatura digital defeituosa seja identificada no tráfego, que pode ser usada como fonte de informação para reconstruir a chave privada RSA. Depois de recriar a chave RSA do host, um invasor pode usar um ataque MITM para redirecionar silenciosamente as solicitações para um host falso que se faz passar por um servidor SSH comprometido e interceptar os dados transmitidos a esse servidor.
Ao examinar uma coleção de dados de rede interceptados que incluía aproximadamente 5200 bilhões de registros associados ao uso do protocolo SSH, os pesquisadores identificaram aproximadamente 3200 bilhões de chaves públicas de host e assinaturas digitais usadas durante a negociação de sessões SSH. Destes, 1.200 bilhão (39,1%) foram gerados pelo algoritmo RSA.
O grupo de pesquisadores menciona que:
Em 593671 casos (0,048%) a assinatura RSA estava corrompida e não pôde ser verificada, enquanto para 4962 assinaturas com falha, conseguimos usar o método de fatoração reticulada para determinar a chave privada a partir da chave pública conhecida, resultando na reconstrução de 189 RSA exclusivos. pares de chaves (em muitos casos, as mesmas chaves e dispositivos com falha foram usados para gerar diferentes assinaturas corrompidas). Foram necessárias aproximadamente 26 horas de CPU para recriar as chaves.
O problema afeta apenas implementações específicas do protocolo SSH, usado principalmente em dispositivos embarcados. Além disso, é mencionado que o OpenSSH não é afetado por este problema porque utiliza a biblioteca OpenSSL (ou LibreSSL) para gerar chaves, que está protegida contra ataques de falhas desde 2001.
Além disso, no OpenSSH, o esquema de assinatura digital ssh-rsa (baseado em sha1) foi descontinuado desde 2020 e desativado na versão 8.8 (o suporte para os esquemas rsa-sha2-256 e rsa-sha2-512 permanece). O ataque poderia ser potencialmente aplicável ao protocolo IPsec, mas os pesquisadores não tinham dados experimentais suficientes para confirmar tal ataque na prática.
Por fim, se estiver interessado em saber mais sobre o assunto, pode consultar os detalhes no link a seguir