Intel é o nosso feed de ameaças de segurança open-source alimentado por IA e pela nossa equipe de pesquisa interna. O Intel monitora e descobre vulnerabilidades em pacotes open-source antes que sejam divulgadas. Muitas nunca são.
67% das vulnerabilidades de software corrigidas silenciosamente nunca foram divulgadas
O software open-source impulsiona o mundo, literalmente. No entanto, a segurança open-source também é uma área de grande preocupação. Ferramentas open-source, como tudo o mais, podem introduzir vulnerabilidades de segurança. Estas podem ser usadas por atacantes para explorar sua aplicação. Deixando os fornecedores de software vulneráveis a ataques sem culpa própria. Isso torna a segurança open-source um tópico muito importante.
Não apenas dependemos da comunidade open-source para construir e manter essas ferramentas, mas também dependemos dela para corrigir quaisquer vulnerabilidades de segurança conhecidas. É importante ressaltar que também contamos com esses mantenedores para relatar publicamente as vulnerabilidades quando são descobertas. A divulgação pública de vulnerabilidades pela comunidade forma a base da segurança open-source.
Silent patching, ou shadow patching, é quando uma correção de segurança é aplicada (patch) mas nunca divulgada. Este é um grande problema porque significa que os fornecedores podem estar executando software vulnerável sem estarem cientes do risco.
Estamos lançando o Aikido Intel para tirar das sombras softwares corrigidos silenciosamente que podem afetá-lo. Com o Aikido Intel, podemos dar aos desenvolvedores o aviso mais cedo possível se encontrarmos vulnerabilidades que possam afetá-los e melhorar a segurança de código aberto.
O que é o Aikido Intel?
O Aikido Intel é uma iniciativa da IA + nossa equipe de pesquisa interna para melhorar a segurança de código aberto, descobrindo vulnerabilidades na cadeia de suprimentos de código aberto no momento mais oportuno. Mesmo antes de serem divulgadas em um banco de dados de vulnerabilidades. Para isso, usamos LLMs treinados sob medida para revisar as mudanças nos pacotes e identificar quando um problema de segurança foi corrigido.
Como todo software, o código aberto mantém um log de alterações do que foi ajustado em cada nova versão. O Intel usa IA para ler todos esses logs de alterações públicos e notas de lançamento para encontrar exemplos de onde problemas de segurança foram corrigidos. Isso é então comparado com 5 bancos de dados de vulnerabilidades para ver se o problema foi relatado. Se não, solicitamos que um engenheiro de segurança analise e avalie a vulnerabilidade, atribuindo-lhe um número e gravidade de Vulnerabilidade Aikido e anunciando-a publicamente para que você saiba se está sendo afetado. Leia mais detalhes sobre isso mais adiante
Aikido Intel em números
Desde o lançamento em janeiro, a Aikido, o Intel descobriu 511 vulnerabilidades que foram corrigidas, mas não divulgadas publicamente, representando uma ameaça real para qualquer pessoa que use esses pacotes.
Às vezes, pode levar tempo entre a correção de uma vulnerabilidade e a atribuição de um número CVE ao problema. Toda semana, a Aikido reavalia o status de vulnerabilidades anteriores para verificar se alguma tem um CVE atribuído. Podemos divulgar que 67% das vulnerabilidades que descobrimos nunca foram divulgadas publicamente em nenhum banco de dados de vulnerabilidades!
Embora não seja surpresa que vulnerabilidades de baixa gravidade sejam corrigidas silenciosamente com mais frequência, ainda é chocante que mais de 50% das vulnerabilidades de alta e crítica gravidade nunca sejam divulgadas. Isso cria um enorme ponto cego para desenvolvedores e fornecedores de software.
Sei que alguns de vocês devem estar se contorcendo em suas cadeiras, pensando que talvez sejam projetos open-source pequenos, não tão populares, com políticas de segurança limitadas, mas, na verdade, vocês estariam errados. Encontramos algumas vulnerabilidades não divulgadas em projetos muito grandes.
Axios, um cliente HTTP baseado em promises para navegador e node.js, com 56 milhões de downloads semanais e mais de 146.000 dependentes, corrigiu uma vulnerabilidade de prototype pollution em janeiro de 2024 que nunca foi divulgada publicamente.
Curiosidade sobre esta vulnerabilidade: Esta foi, na verdade, a primeira vulnerabilidade que o Aikido Intel encontrou (Veja o número 2023-10001)…. Ela permanece não divulgada até hoje!
Não quero dar todo o crédito a eles, o Axios não está sozinho; há alguns outros nomes que merecem uma menção especial. A Apache corrigiu silenciosamente uma vulnerabilidade no software echarts para cross-site scripting que nunca foi divulgada.
Outro exemplo interessante que descobrimos foi uma vulnerabilidade crítica de path traversal no Chainlit que foi corrigida em setembro, mas a vulnerabilidade nunca foi divulgada publicamente.
As vulnerabilidades mais comuns
Cross-site scripting foi a vulnerabilidade não divulgada mais comum, representando 14,8%, seguida pela exposição de informações sensíveis, com 12,3%. No total, detectamos 90 tipos diferentes de vulnerabilidades, criando uma longa cauda de resultados; abaixo estão algumas das mais comuns.
As vulnerabilidades mais comuns descobertas
Se olharmos apenas para as vulnerabilidades críticas e de alta severidade, podemos ver um cenário ligeiramente diferente, com a execução remota de código ocupando o primeiro lugar na lista.
As vulnerabilidades mais comuns descobertas - Somente Críticas e Altas
Tempo para divulgação
Enquanto, no momento da escrita, 67% dos pacotes nunca divulgaram suas vulnerabilidades, 31% o fizeram, seja por parte dos mantenedores ou de pesquisadores de segurança (mérito a eles). Dos pacotes que divulgaram as vulnerabilidades, levou em média 27 dias desde o lançamento do patch até a atribuição de um CVE. O tempo mais rápido que observamos foi de apenas 1 dia e o mais longo foi de 9 meses!
Como o Intel funciona (em detalhes)
Eu sei que estamos todos cansados dos exageros sobre a nova IA, mas o Intel é uma iniciativa da equipe de pesquisa de segurança da Aikido e a equipe de IA da Aikido aproveita a IA com um Humano no Ciclo para fornecer um feed de ameaças público para melhorar a segurança de código aberto.
O Intel funciona lendo todos os changelogs e notas de lançamento disponíveis publicamente para entender se correções de segurança foram feitas, mas não divulgadas. Para isso, dois modelos LLM são usados, um para filtrar os dados e remover todo o contexto desnecessário para que o segundo LLM possa focar na análise de vulnerabilidades. Um engenheiro de segurança humano então revisa as descobertas do LLM, valida os achados e lança um Intel quando uma vulnerabilidade é confirmada.
Este é um método tão eficaz porque consome notavelmente menos poder computacional do que tentar escanear todos esses sistemas em busca de vulnerabilidades. No entanto, provou, ao longo de um ano, encontrar muitos resultados verdadeiros.
Como os Changelogs São Vistos pelo Aikido Intel
Changelogs são documentos mantidos em projetos open-source que registram atualizações, correções de bugs, adições de recursos e patches. Exemplos incluem CHANGELOG.md arquivos, mensagens de commit e notas de lançamento do GitHub.
O LLM do Intel identifica entradas que sugerem mudanças relacionadas à segurança procurando por:
- Palavras-chave: “vulnerabilidade,” “segurança,” “correção,” “exploit,” “validação de entrada,” etc.
- Pistas contextuais: “Corrigido um bug crítico,” “Corrigido um estouro de buffer,” “Problemas de autenticação resolvidos.”
Exemplos de Entradas Sinalizadas pelo LLM:- Corrigido um problema de sanitização de entrada no manipulador de login.
- Resolvido um vazamento de memória que poderia levar a ataques de negação de serviço.
- Abordada uma vulnerabilidade de path traversal na funcionalidade de upload de arquivos.
Segurança de código aberto: como as vulnerabilidades são divulgadas adequadamente
Como mencionado anteriormente, a divulgação pública é um grande componente da segurança de código aberto. Vários bancos de dados diferentes são usados para divulgar quando um software possui uma vulnerabilidade. O principal banco de dados é o National Vulnerability Database (NVD), mantido pelo governo dos EUA. Este banco de dados não é apenas usado por empresas para verificar sua supply chain, mas também por softwares de segurança que verificam projetos contra este e outros bancos de dados (software SCA). Existem vários outros bancos de dados, incluindo o Common Vulnerabilities and Exposures database (CVE) da Mitre, o GitHub Advisory Database e muitos outros; no total, a Aikido verifica 5 bancos de dados diferentes. Mas o que a maioria desses bancos de dados tem em comum é que eles exigem que as vulnerabilidades sejam divulgadas publicamente, geralmente após o lançamento de uma correção.
Por que as vulnerabilidades não são divulgadas?
Esta é uma boa pergunta e quero começar dizendo que não há uma boa razão para não divulgar vulnerabilidades. Talvez o mais comum seja o risco reputacional, de que seu software possa ser visto como inseguro, mas eu argumentaria que há muito mais a perder ao não divulgar do que ao divulgar.
Por que o shadow patching é um problema para a segurança de código aberto
Não divulgar publicamente as vulnerabilidades em seu software cria um enorme risco para seus usuários. Como diz o ditado, se não está quebrado, não conserte, isso se aplica com bastante frequência a softwares.
Atualizar componentes do seu software pode frequentemente criar problemas de desempenho e usabilidade ou simplesmente quebrar sua aplicação; com isso em mente, nem sempre é prática comum atualizar pacotes imediatamente quando uma versão mais recente está disponível.
Quando, no entanto, há um problema de segurança em um componente, é importante saber, pois isso altera a urgência com que você atualiza seus componentes de código aberto e de terceiros. Não divulgar essas informações significa que os usuários são menos propensos a atualizar, o que significa que terão falhas de segurança em suas ferramentas que desconheciam, daí por que o shadow patching é um problema tão grande.
