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 a lançar Aikido para trazer à luz softwares corrigidos silenciosamente que podem afetá-lo. Com Aikido , podemos alertar os programadores o mais cedo possível se encontrarmos vulnerabilidades que possam afetá-los e melhorar a segurança do código aberto.
O que é Aikido ?
Aikido é uma iniciativa da AI + nossa equipa de investigação interna para melhorar a segurança do código aberto, descobrindo vulnerabilidades na cadeia de fornecimento de código aberto o mais cedo possível. Mesmo antes de serem divulgadas numa base de dados de vulnerabilidades. Para isso, usamos LLMs treinados de forma personalizada para analisar alterações em pacotes e identificar quando um problema de segurança foi corrigido.
Como todo software, o código aberto mantém um registo de alterações do que foi ajustado em cada nova versão. A Intel usa IA para ler todos esses registos públicos de alterações e notas de lançamento para encontrar exemplos de onde problemas de segurança foram corrigidos. Em seguida, isso é comparado com cinco bases de dados de vulnerabilidades para verificar se o problema foi relatado. Caso contrário, um engenheiro de segurança analisa e avalia a vulnerabilidade, atribuindo-lhe um número Aikido e gravidade, e anunciando-a publicamente para que você saiba se foi afetado. Leia mais detalhes sobre isso mais adiante.
Aikido em números
Desde o lançamento Aikido em janeiro, a Intel descobriu 511 vulnerabilidades que foram corrigidas, mas não divulgadas publicamente, representando uma ameaça real para qualquer pessoa que utilize esses pacotes.
Às vezes, pode demorar algum tempo entre a correção de uma vulnerabilidade e a atribuição de um número CVE ao problema. Todas as semanas, Aikido o estado das vulnerabilidades anteriores para verificar se alguma delas recebeu um número CVE. Podemos revelar que 67% das vulnerabilidades que descobrimos nunca foram divulgadas publicamente em nenhuma base 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 encontrada Aikido (ver número 2023-10001)…. Ela permanece confidencial 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)
Sei que estamos todos fartos das novas tretas sobre IA, mas a Intel é uma iniciativa da equipa de investigação de segurança Aikidoe a equipa de IA Aikido aproveita a IA com um humano no circuito para fornecer um feed público de ameaças para melhorar a segurança de código aberto.
A Intel funciona lendo todos os registos de alterações e notas de lançamento disponíveis publicamente para entender se foram feitas correções de segurança, mas não divulgadas. Para isso, são utilizados dois modelos LLM, um para filtrar os dados e remover todo o contexto desnecessário, para que o segundo LLM possa se concentrar na análise de vulnerabilidades. Um human security então analisa as descobertas do LLM, valida as conclusões 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 registos de alterações são visualizados pela Aikido
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 componente importante da segurança de código aberto. Várias bases de dados diferentes são utilizadas para divulgar quando um software tem uma vulnerabilidade interna. A principal base de dados é a National Vulnerability Database (NVD), mantida pelo governo dos EUA. Essa base de dados não é utilizada apenas por empresas para verificar a sua cadeia de abastecimento, mas também por softwares de segurança que verificam projetos em relação a essa base de dados e outras (SCA ). Existem várias outras bases de dados, incluindo a base de dados Common Vulnerabilities and Exposures (CVE) da Mitre, a GitHub Advisory Database e muitas outras. No total, Aikido cinco bases de dados diferentes. Mas o que a maioria dessas bases de dados tem em comum é que elas 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.
Não deixe que vulnerabilidades ocultas comprometam sua segurança.
Faça uma parceria com Aikido hoje mesmo para proteger a sua cadeia de abastecimento e ficar tranquilo.
Proteja seu software agora
.avif)
