.
Os críticos acusam as grandes empresas de tecnologia de não seguirem as regras quando se trata de registrar vulnerabilidades junto às autoridades competentes.
Tanto a Juniper Networks quanto a Ivanti atraíram críticas de membros da indústria de segurança da informação pela forma como lidaram com a divulgação de vulnerabilidades na semana passada.
A gigante das redes foi acusada de corrigir falhas de segurança sem divulgá-las como vulnerabilidades autônomas, enquanto Ivanti foi criticado por aparentemente agrupar múltiplas vulnerabilidades sob um único ID registrado de Vulnerabilidades e Exposições Comuns (CVE).
Vulnerabilidades de segurança que são graves o suficiente para exigir patches para evitar problemas para as organizações geralmente precisam ser registradas em uma Autoridade de Numeração CVE (CNA) e adicionadas ao programa CVE.
Uma vez registradas com um ID CVE, as vulnerabilidades podem ser mais facilmente identificadas e rastreadas pelas organizações, tornando sua rotina de aplicação de patches mais facilmente gerenciável.
Aliz Hammond, pesquisadora da watchTowr, relatou uma série de problemas de segurança à Juniper no final de 2023. O fornecedor os investigou e pediu a Hammond que atrasasse a divulgação dos detalhes além da janela típica de 90 dias da watchTowr para que as correções pudessem ser publicadas primeiro, durante seu lote trimestral de janeiro. de atualizações.
Hammond afirma ter encontrado quatro vulnerabilidades incluídas no último lote de patches da Juniper que não pareciam ter recebido IDs CVE, incluindo uma vulnerabilidade de autenticação ausente – que ele descreveu como “frequentemente as vulnerabilidades mais fáceis de explorar”.
Ele também chamou a atenção para a decisão da Juniper de não lançar um patch fora de ciclo, apesar do fornecedor considerar o bug sério o suficiente para solicitar um adiamento da janela de divulgação.
“A Juniper geralmente publica comunicados na segunda quarta-feira do primeiro mês de cada trimestre, o que parece um cronograma estranho, dada a urgência das atualizações de segurança”, escreveu Hammond. “Afirmamos frequentemente que a resposta de um fornecedor a vulnerabilidades como estas pode ser crítica para fechar a ‘janela de vulnerabilidade’ do seu cliente.
“Diante disso, é interessante que a Juniper não tenha considerado pelo menos a vulnerabilidade de autenticação ausente grave o suficiente para justificar um aviso fora de ciclo, nem para registrar CVE ou mencioná-los nas notas de lançamento (embora eles os considerassem importantes). o suficiente para solicitar que adiemos nosso cronograma de VDP de 90 dias usual e alinhado ao setor).”
Strong The One contatou a Juniper Networks para obter uma resposta, mas a empresa ainda não respondeu.
Aborrecimentos VPN
As práticas de divulgação da Ivanti foram criticadas de forma semelhante por especialistas em segurança da informação que discutiram as descobertas no Mastodon.
Um pesquisador que analisa os dias zero explorados disse ter descoberto que para CVE-2024-21887, que leva à execução remota de código (RCE), eles poderiam encontrar pelo menos cinco vulnerabilidades diferentes de injeção de comando sob um único ID CVE registrado. O especialista em segurança Kevin Beaumont chamou a prática de “um pouco perversa”.
De acordo com a seção 7.2 das regras da CNA, a autoridade define claramente as suas expectativas em relação aos fornecedores ao relatar vulnerabilidades.
“O Programa CVE espera que IDs CVE separados sejam atribuídos a vulnerabilidades corrigíveis de forma independente. Se uma vulnerabilidade puder ser corrigida sem corrigir a outra, então as vulnerabilidades deverão receber IDs CVE separados.”
A única exceção a esta regra é quando as vulnerabilidades corrigíveis de forma independente afetam produtos diferentes que compartilham o mesmo código ou os produtos vulneráveis são afetados porque usam a funcionalidade de outro produto.
A discussão terminou com o pesquisador original, Rich Warren, alegando que cada vulnerabilidade exigiria correções individuais e, de acordo com as regras mencionadas acima, isso exigiria CVEs separados.
Ivanti nos respondeu dizendo o contrário. O fornecedor disse que havia várias vulnerabilidades listadas no mesmo CVE, assim como Warren, mas todas essas vulnerabilidades serão resolvidas pela mesma correção.
“Na Ivanti, a segurança de nossos clientes é nossa principal prioridade. Nosso objetivo é comunicar-se com clareza e garantir que nossos clientes saibam quais ações precisam tomar”, afirmou. Strong The One.
“Neste caso, para evitar confusão, optamos por não ter vários números CVE reservados para vulnerabilidades com a mesma descrição, mesma pontuação CVSS e mesma correção na mesma parte do código.
“Em vez disso, a descrição do CVE observou que havia múltiplas vulnerabilidades naquela seção do código. Esses endpoints vulneráveis foram todos bloqueados com sucesso pela mitigação e serão todos resolvidos nos patches que lançaremos em breve.”
As vulnerabilidades podem ser corrigidas de forma independente, como disse Warren, mas a declaração de Ivanti sugere que todas elas também podem ser corrigidas por um único patch, que será aplicado a todas elas, o que significa que a abordagem de CVE único pode estar dentro das regras aqui.
De qualquer forma, as mesmas expectativas em relação às alocações de CVE também se aplicam à Juniper Networks – um fornecedor de segurança de rede. Quanto ao motivo pelo qual nenhum CVE foi atribuído, não está claro neste momento.
As quatro vulnerabilidades destacadas por Hammond, por exemplo, são atualmente rastreadas pelo próprio sistema de identificação da Juniper, com detalhes em um artigo pago da base de conhecimento do cliente.
Apesar da própria Juniper ser uma CNA, é possível que o atraso na atribuição de IDs CVE esteja sendo feito para permitir que os clientes tenham tempo para aprender e corrigir os problemas antes que as informações sejam divulgadas publicamente, junto com um CVE.
Além disso, embora não divulgar vulnerabilidades individuais seja contra as melhores práticas do setor, a Juniper as corrigiu e ofereceu patches para os clientes de acordo com seu cronograma típico, portanto, não há abuso flagrante das regras e expectativas aqui.
Adam Pilton, consultor de segurança cibernética da CyberSmart, disse-nos que, embora não haja limite de tempo para a atribuição de CVEs, é uma boa prática registrá-los o mais rápido possível para garantir que sejam resolvidos em tempo hábil.
Referindo-se ao caso da Juniper, disse: “Devemos levar em consideração que não conhecemos todos os fatos, mesmo que superficialmente pareçam questionáveis.
“Atrasar os relatórios pode ser necessário para permitir que uma correção esteja pronta para garantir a divulgação responsável. Isso ajuda a proteger os usuários, dando-lhes tempo para aplicar patches antes que os detalhes da vulnerabilidade se tornem públicos. Também pode evitar o pânico entre os usuários e a exploração potencial por atores mal-intencionados antes uma solução está disponível.
“No entanto, atrasos nos relatórios podem prejudicar a transparência e deixar os usuários inconscientes e expostos a riscos potenciais em seus sistemas”. ®
.
