.
Atualizada Duas vulnerabilidades DNSSEC foram divulgadas no mês passado com descrições semelhantes e a mesma pontuação de gravidade, mas não são o mesmo problema.
Um deles, denominado KeyTrap (CVE-2023-50387) pelo Centro Nacional de Pesquisa para Segurança Cibernética Aplicada da Alemanha (ATHENE), foi descrito como “um dos piores já descobertos”, pelo executivo da Akamai, Sven Dummer, porque poderia ser usado para desativar grandes porções. da internet.
O KeyTrap permitiu que um único pacote DNS negasse serviço, esgotando os recursos da CPU de máquinas que executavam serviços DNS validados por DNSSEC, como os fornecidos pelo Google e Cloudflare.
DNSSEC (Extensões de Segurança do Sistema de Nomes de Domínio) oferece uma maneira criptográfica de proteger as interações DNS. Mas sua especificação de implementação não levou em conta a possibilidade de pacotes criados com códigos maliciosos que poderiam forçar um respondente a se envolver em cálculos obrigatórios.
A outra falha do DNSSEC, o gabinete NSEC3 (CVE-2023-50868), foi encontrada por Petr Špaček do Internet Systems Consortium (ISC) e também foi apresentada como um risco de esgotamento da CPU. Mas com base numa análise conduzida pela equipa ATHENE, parece agora em grande parte inconsequente.
Ambos obtiveram uma classificação de gravidade de 7,5 em 10 no Common Vulnerability Scoring System (CVSS) do MITRE, a organização de segurança sem fins lucrativos que opera centros de pesquisa e desenvolvimento financiados pelo governo federal dos EUA.
As duas falhas também foram descritas em comunicados do ISC, fabricante do software DNS BIND 9 afetado, usando termos idênticos. Os CVEs para KeyTrap e NSEC3-encloser sugerem que as vulnerabilidades podem ser exploradas para conduzir ataques de negação de serviço.
Veja como o ICS descreve o KeyTrap:
E aqui está o palavreado para o gabinete NSEC3:
Mas as duas vulnerabilidades não são comparáveis em termos de gravidade, de acordo com Haya Schulmann, professora de ciência da computação na Goethe University Frankfurt, uma das acadêmicas da ATHENE por trás da pesquisa KeyTrap. Por e-mail, Schulmann disse Strong The One que os experimentos indicam que nenhuma negação de serviço por esgotamento da CPU é possível com a vulnerabilidade NSEC3.
Schulmann disse que a equipe ATHENE publicou descobertas nesse sentido em um artigo [PDF] intitulado “Atacar com algo que não existe: inundação de baixa taxa com ‘prova de inexistência’ pode esgotar a CPU do resolvedor de DNS.”
O artigo, disse ela, analisa especificamente o impacto da vulnerabilidade do gabinete NSEC3 e descobre que é várias ordens de magnitude menos desgastante para os núcleos da CPU do que o KeyTrap.
“Realizamos avaliações extensivas do ataque ao gabinete NSEC3 e descobrimos que ele pode criar um aumento maciço na contagem de instruções da CPU nos resolvedores DNS das vítimas”, diz o jornal. “Isso é muito menos do que o ataque KeyTrap divulgado recentemente, que cria um fator de aumento de 2.000.000 na contagem de instruções da CPU.”
Disseram-nos que o documento foi compartilhado com vários fornecedores de software DNS, incluindo o ISC, em 17 de março e ainda não gerou nenhuma resposta.
Strong The One pediu ao MITRE, que designou os CVEs, que comentasse as preocupações levantadas por Schulmann e seus colegas. Não tivemos resposta.
Schulmann diz que levantou essas preocupações ao MITRE, que segundo ela respondeu da seguinte forma:
Schulmann achou esta resposta preocupante porque parece que o MITRE está sugerindo que a avaliação da importância de uma vulnerabilidade pode variar, dependendo da documentação consultada.
“A resposta do MITRE implica que existem diferentes perspectivas sobre a vulnerabilidade, incentivando as partes interessadas a lerem todo o relatório técnico para compreenderem que a descrição do MITRE está incorreta”, escreveu ela. “A pesquisa científica tira conclusões baseadas em análises e avaliações, e não em opiniões e perspectivas.
“Embora nosso relatório técnico forneça análises e avaliações detalhadas, o blog do ISC descreve brevemente ambos os problemas, mas sem quaisquer detalhes. Esta resposta do MITRE também contradiz as informações do NIST relativas ao processo de atribuição de vulnerabilidades, uma vez que o processo exige que os analistas use qualquer informação disponível para estabelecer a gravidade. Como resultado da ‘adoção de uma perspectiva’ do MITRE, tanto a pontuação CVSS quanto as descrições dos CVEs estão incorretas e são enganosas. “
O NIST não respondeu imediatamente a um pedido de comentário.
De acordo com Schulmann, os dois CVEs mostram que há motivos para duvidar da exatidão e do controle de qualidade das avaliações de vulnerabilidade do MITRE e do Banco de Dados Nacional de Vulnerabilidade administrado pelo NIST que armazena essas informações.
Schulmann argumenta que embora às vezes possa ser razoável para o MITRE apresentar a “perspectiva” dos fornecedores em relatórios de vulnerabilidade, isso deve ser feito com cuidado porque os fornecedores podem ser tentados a minimizar vulnerabilidades graves para evitar publicidade negativa.
Ela cita o recente comprometimento de uma chave de assinatura da Microsoft como exemplo.
“Essa violação afetou os clientes dos produtos em nuvem Azure, e compreender os detalhes exatos da violação foi essencial para que as organizações se defendessem”, explicou ela. “No entanto, havia preocupações na comunidade de que a Microsoft ocultasse detalhes da violação, minimizando o incidente.”
Schulmann argumenta que o MITRE e outros encarregados da disseminação de informações de resposta de segurança precisam ser mais exigentes em suas avaliações de vulnerabilidade, mesmo que isso signifique desconforto para o fornecedor.
“É fundamental que o MITRE mantenha o profissionalismo e a neutralidade na avaliação das informações sobre vulnerabilidade, para que o público possa confiar nelas”, disse Schulmann. “Em particular, o MITRE, tal como afirma o NIST, deve utilizar qualquer informação disponível para basear a sua avaliação.
“A falta de transparência e o recurso a uma perspetiva preferida podem não só criar desconfiança entre os intervenientes, mas também prejudicar a segurança geral.” ®
Atualizado para adicionar
Em comunicado fornecido a Strong The One depois que esta história foi arquivada, Matt Scholl, chefe da divisão de segurança de computadores do NIST, disse: “Em geral, publicamos as Pontuações Comuns de Vulnerabilidade usando a especificação CVSS v3 e as informações fornecidas no CVE enviado.
“Isso gera uma ‘pontuação básica’ que pode precisar de refinamento para contexto, uso, tolerância a riscos e modelos de ameaças em nível local.
“As pontuações básicas do CVSS também são sobre a tecnologia e não a escala em que ela pode ser usada ou implantada. Se as pontuações básicas do CVSSv3 parecerem ‘frouxas’ para um usuário, então encorajamos o uso de entradas de localidade para que a pontuação seja mais significativa para esse usuário.”
.
