A Intel é o nosso feed de ameaças de segurança de código aberto alimentado por IA e pela nossa equipa de investigação interna. A Intel monitoriza e descobre vulnerabilidades em pacotes de código aberto antes de estas serem divulgadas. Muitas nunca são.
67% das vulnerabilidades de software corrigidas silenciosamente nunca foram divulgadas
O software de código aberto dá poder ao mundo, literalmente. No entanto, a segurança do software de código aberto é também uma área de grande preocupação em termos de segurança. As ferramentas de código aberto, como tudo o resto, podem introduzir vulnerabilidades de segurança. Estas podem ser utilizadas por atacantes para explorar a sua aplicação. Deixando os fornecedores de software expostos a ataques que não são da sua responsabilidade. Isto torna a segurança de código aberto um tópico muito importante.
Não só contamos com a comunidade de código aberto para construir e manter estas ferramentas, como também contamos com eles para corrigir quaisquer vulnerabilidades de segurança conhecidas. É importante salientar que também contamos com esses mantenedores para relatar publicamente as vulnerabilidades quando elas são descobertas. A divulgação pública de vulnerabilidades pela comunidade constitui a base da segurança de código aberto.
A correção silenciosa, ou correção sombra, é quando uma correção de segurança é aplicada (corrigida) mas nunca divulgada. Este é um grande problema porque significa que os fornecedores podem estar a executar software vulnerável sem estarem conscientes do risco.
Estamos a lançar o Aikido Intel para tirar da sombra software silenciosamente corrigido que o pode afetar. Com o Aikido Intel, podemos avisar os programadores o mais cedo possível se encontrarmos vulnerabilidades que os possam afetar e melhorar a segurança de código aberto.
O que é o Aikido Intel?
Aikido Intel é uma iniciativa da AI + da nossa equipa de investigação interna para melhorar a segurança de 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 o conseguir, utilizamos LLMs treinados à medida para analisar as alterações nos pacotes e identificar quando um problema de segurança foi corrigido.
Como todo o software, o código aberto mantém um registo de alterações do que foi ajustado em cada nova versão. A Intel utiliza a IA para ler todos estes registos públicos de alterações e notas de lançamento para encontrar exemplos de correcções de problemas de segurança. Em seguida, é efectuada uma comparação com 5 bases de dados de vulnerabilidades para verificar se o problema foi comunicado. Caso contrário, um engenheiro de segurança analisa e avalia a vulnerabilidade, atribuindo-lhe um número de vulnerabilidade Aikido e uma gravidade e anunciando-a publicamente para que saiba se foi afetado. Leia mais pormenores sobre isto mais tarde
Verificar o Aikido Intel agora
Aikido Intel em números
Desde o seu lançamento em janeiro, o Aikido, a Intel descobriu 511 vulnerabilidades que foram corrigidas mas não divulgadas publicamente, representando uma ameaça real para quem utiliza esses pacotes.
Por 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, a Aikido reavalia o estado das vulnerabilidades anteriores para ver se alguma tem um CVE atribuído. Podemos revelar que 67% das vulnerabilidades que descobrimos nunca foram divulgadas publicamente em nenhuma base de dados de vulnerabilidades!
Embora não seja surpreendente que as vulnerabilidades de baixa gravidade sejam mais frequentemente corrigidas de forma silenciosa, não deixa de ser chocante o facto de mais de 50% das vulnerabilidades de alta gravidade e críticas nunca serem divulgadas. Isto cria um enorme ponto cego para os programadores e fornecedores de software.
Sei que alguns de vós se estarão a contorcer nas vossas cadeiras, dizendo que talvez se trate de pequenos projectos de código aberto, não tão populares, com políticas de segurança limitadas, mas, na verdade, estariam enganados. Encontrámos algumas vulnerabilidades não reveladas em alguns projectos muito grandes. .
O Axios, um cliente HTTP baseado em promessas para o browser e o node.js, com 56 milhões de descarregamentos semanais e mais de 146 000 dependentes, corrigiu uma vulnerabilidade de poluição de protótipos em janeiro de 2024 que nunca foi divulgada publicamente.
Facto curioso sobre esta vulnerabilidade: Esta foi, de facto, a primeira vulnerabilidade que a Aikido Intel encontrou (Ver número 2023-10001).... Continua a não ser divulgada até hoje!
Agora, não quero dar-lhes a mão à palmatória, a Axios não é a única, há mais alguns nomes que merecem uma saudação especial. A Apache corrigiu silenciosamente uma vulnerabilidade no software echarts para scripts entre sítios que nunca foi divulgada.
Outro exemplo interessante que descobrimos foi uma vulnerabilidade crítica de passagem de caminho no Chainlit que foi corrigida em setembro, mas a vulnerabilidade nunca foi divulgada publicamente.
As vulnerabilidades mais comuns
O scripting entre sítios foi a vulnerabilidade não divulgada mais comum, representando 14,8%, seguida da exposição de informações sensíveis, 12,3%. No total, detectámos 90 tipos diferentes de vulnerabilidades, criando uma longa cauda de resultados.
As vulnerabilidades mais comuns descobertas
Se olharmos apenas para as vulnerabilidades de cutícula e de alto nível, podemos ver um quadro ligeiramente diferente, com a execução remota de código a ocupar o primeiro lugar da lista
As vulnerabilidades mais comuns descobertas - apenas críticas e graves
Tempo para a divulgação
Enquanto no momento em que este artigo foi escrito 67% dos pacotes nunca revelaram suas vulnerabilidades, 31% o fizeram, seja pelos mantenedores ou pesquisadores de segurança (parabéns a eles). Dos pacotes que divulgaram as vulnerabilidades, levou uma média de 27 dias desde o momento em que o patch foi lançado até quando um CVE foi atribuído. O tempo mais rápido que observámos foi de apenas 1 dia e o tempo mais longo foi de 9 meses!
Como funciona a Intel (em pormenor)
Sei que estamos todos fartos das novas tretas da IA, mas a Intel é uma iniciativa da equipa de investigação de segurança da Aikido e a equipa de IA da Aikido utiliza a IA com um humano no circuito para fornecer um feed público de ameaças para melhorar a segurança de fonte aberta.
A Intel trabalha lendo todos os changelogs e notas de lançamento disponíveis publicamente para entender se as correções de segurança foram feitas, mas não divulgadas. Para tal, são utilizados dois modelos LLM, um para filtrar os dados e remover todo o contexto desnecessário, para que o segundo LLM se possa concentrar na análise das vulnerabilidades. Em seguida, um engenheiro de segurança humano analisa as descobertas do LLM, valida as descobertas e libera uma Intel quando uma vulnerabilidade é confirmada.
Este é um método tão eficaz porque consome muito menos poder computacional do que tentar analisar todos estes sistemas em busca de vulnerabilidades. No entanto, provou ao longo de um ano encontrar muitos resultados verdadeiros.
Como é que os registos de alterações são vistos pela Aikido Intel
Os registos de alterações são documentos mantidos em projectos de código aberto que registam actualizações, correcções de erros, adições de funcionalidades e patches. Os exemplos incluem CHANGELOG.md mensagens de commit e notas de lançamento do GitHub.
O Intel LLM identifica entradas que sugerem alterações relacionadas à segurança, procurando por:
- Palavras-chave: "vulnerabilidade", "segurança", "correção", "exploração", "validação de entrada", etc.
- Dicas contextuais: "Corrigido um erro crítico", "Corrigido um estouro de buffer", "Resolvidos problemas de autenticação".
Exemplo de entradas assinaladas 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 travessia de caminho na funcionalidade de upload de arquivos.
Segurança de fonte aberta, como as vulnerabilidades são divulgadas corretamente
Tal como referido anteriormente, a divulgação pública é uma componente importante da segurança de código aberto. São utilizadas várias bases de dados diferentes para divulgar quando um software tem uma vulnerabilidade. A principal base de dados é a National Vulnerability Database (NVD), mantida pelo governo dos EUA. Esta base de dados não é apenas utilizada pelas empresas para verificar a sua cadeia de abastecimento, mas também por software de segurança que verifica os projectos com base nesta base de dados e noutras (software SCA). Existem várias outras bases de dados, incluindo a base de dados de Vulnerabilidades e Exposições Comuns (CVE) da Mitre, a base de dados consultiva do GitHub e muitas outras, num total de 5 bases de dados diferentes que o Aikido verifica. Mas o que a maioria destas bases de dados tem em comum é o facto de exigirem que as vulnerabilidades sejam divulgadas publicamente, normalmente após a publicação de uma correção.
Porque é que as vulnerabilidades não são divulgadas?
Esta é uma boa pergunta e gostaria de começar por dizer que não existe uma boa razão para não divulgar vulnerabilidades. Talvez a mais comum seja o risco para a reputação, o facto de o seu software poder ser visto como inseguro, mas eu diria que há muito mais a perder com a não divulgação do que com a divulgação.
Porque é que o shadow patching é um problema para a segurança de código aberto
Não divulgar publicamente as vulnerabilidades do seu software cria um enorme risco para os seus utilizadores. Como diz o ditado, se não está estragado, não o arranje, o que se aplica frequentemente ao software.
A atualização de componentes do seu software pode muitas vezes criar problemas de desempenho e usabilidade ou simplesmente avariar a sua aplicação. Com isto em mente, nem sempre é prática comum atualizar imediatamente os pacotes quando uma versão mais recente está disponível.
No entanto, quando existe um problema de segurança num componente, é importante sabê-lo, uma vez que altera a urgência com que actualiza os seus componentes de código aberto e de terceiros. Não divulgar esta informação significa que é menos provável que os utilizadores actualizem, o que significa que terão falhas de segurança nas suas ferramentas que desconheciam, daí a razão pela qual o shadow patching é um problema tão grande.
Não deixe que vulnerabilidades ocultas comprometam a sua segurança.
Estabeleça hoje uma parceria com a Aikido Security para proteger a sua cadeia de fornecimento e ganhar paz de espírito.
.png)
.svg)
.png)
.png)
.png)
.jpg)
.jpg)
.jpg)
.jpg)
.png)