Intel es nuestra fuente de amenazas a la seguridad de código abierto impulsada por IA y nuestro equipo interno de investigación. Intel supervisa y descubre vulnerabilidades en paquetes de código abierto antes de que se divulguen. Muchas nunca lo son.
El 67% de las vulnerabilidades de software parcheadas silenciosamente nunca se divulgaron
El software de código abierto impulsa el mundo, literalmente. Sin embargo, la seguridad del código abierto es también un área de enorme preocupación. Las herramientas de código abierto, como todo lo demás, pueden introducir vulnerabilidades de seguridad. Estos pueden ser utilizados por los atacantes para explotar su aplicación. Esto deja a los proveedores de software expuestos a ataques por causas ajenas a su voluntad. Esto hace que la seguridad del código abierto sea un tema muy importante.
No sólo confiamos en la comunidad de código abierto para construir y mantener estas herramientas, sino también para corregir cualquier vulnerabilidad de seguridad conocida. Y lo que es más importante, también confiamos en que estos responsables informen públicamente de las vulnerabilidades cuando se descubran. La divulgación pública de las vulnerabilidades por parte de la comunidad constituye la base de la seguridad del código abierto.
El parcheado silencioso, o parcheado en la sombra, se produce cuando se aplica una corrección de seguridad (parcheado) pero nunca se da a conocer. Se trata de un problema importante porque significa que los vendedores pueden estar utilizando software vulnerable sin ser conscientes del riesgo.
Lanzamos Aikido Intel para sacar de las sombras el software parcheado en silencio que podría afectarle. Con Aikido Intel, podemos avisar a los desarrolladores lo antes posible si encontramos vulnerabilidades que puedan afectarles y mejorar la seguridad del código abierto.
¿Qué es el Aikido Intel?
Aikido Intel es una iniciativa de AI + nuestro equipo interno de investigación para mejorar la seguridad del código abierto descubriendo vulnerabilidades en la cadena de suministro del código abierto lo antes posible. Incluso antes de que se divulguen en una base de datos de vulnerabilidades. Para lograrlo, utilizamos LLM entrenados a medida para revisar los cambios en los paquetes e identificar cuándo se ha solucionado un problema de seguridad.
Como todo software, el de código abierto mantiene un registro de cambios de lo que se ha ajustado en cada nueva versión. Intel utiliza IA para leer todos estos registros de cambios públicos y notas de la versión para encontrar ejemplos de dónde se han parcheado los problemas de seguridad. A continuación, se cotejan con 5 bases de datos de vulnerabilidades para comprobar si se ha notificado el problema. Si no es así, un ingeniero de seguridad analiza y evalúa la vulnerabilidad, le asigna un número de vulnerabilidad Aikido y la gravedad, y la anuncia públicamente para que usted sepa si está afectado. Lea más detalles sobre esto más adelante
Aikido Intel en cifras
Desde su lanzamiento en enero, Aikido, Intel ha descubierto 511 vulnerabilidades que fueron parcheadas pero no divulgadas públicamente, lo que supone una amenaza real para cualquiera que utilice esos paquetes.
A veces puede pasar tiempo entre que se parchea una vulnerabilidad y se le asigna un número CVE. Cada semana, Aikido reevalúa el estado de las vulnerabilidades anteriores para ver si alguna tiene un CVE asignado. Podemos revelar que el 67% de las vulnerabilidades que descubrimos ¡nunca fueron reveladas públicamente a ninguna base de datos de vulnerabilidades!
Aunque no es sorprendente que las vulnerabilidades de baja gravedad se parcheen silenciosamente con más frecuencia, sigue siendo chocante que más del 50% de las vulnerabilidades graves y críticas nunca se divulguen. Esto crea un enorme punto ciego para los desarrolladores y proveedores de software.
Ahora sé que algunos de ustedes estarán retorciéndose en sus asientos diciendo que tal vez se trata de proyectos pequeños, no tan populares, de código abierto con políticas de seguridad limitadas, pero en realidad, estarían equivocados. Encontramos algunas vulnerabilidades no reveladas en algunos proyectos muy grandes. .
Axios un cliente HTTP basado en promesas para el navegador y node.js con 56 millones de descargas semanales y 146.000 + dependientes solucionó una vulnerabilidad de contaminación de prototipos en enero de 2024 que nunca ha sido revelada públicamente.
Dato curioso sobre esta vulnerabilidad: Esta fue en realidad la primera vulnerabilidad que encontró Aikido Intel (Ver número 2023-10001).... A día de hoy sigue sin revelarse.
Ahora no quiero dárselo todo a ellos, Axios no está solo, hay algunos otros nombres que merecen un grito especial. Apache parcheó silenciosamente una vulnerabilidad en el software echarts para cross-site scripting que nunca fue revelada.
Otro ejemplo interesante que descubrimos fue una vulnerabilidad de cruce de ruta crítica en Chainlit que se parcheó en septiembre, pero la vulnerabilidad nunca se hizo pública.
Las vulnerabilidades más comunes
Las secuencias de comandos en sitios cruzados fueron la vulnerabilidad no revelada más común, con un 14,8%, junto con la exposición de información sensible, con un 12,3%. En total, detectamos 90 tipos diferentes de vulnerabilidades, lo que dio lugar a una larga cola de resultados.
Las vulnerabilidades más comunes descubiertas
Si nos fijamos sólo en las vulnerabilidades cuticulares y altas, podemos ver un panorama ligeramente diferente, con la ejecución remota de código ocupando el primer puesto de la lista
Las vulnerabilidades más comunes descubiertas - Sólo críticas y altas
Tiempo de divulgación
Mientras que en el momento de escribir esto el 67% de los paquetes nunca revelaron sus vulnerabilidades, el 31% sí lo hicieron, ya sea por parte de los mantenedores o de los investigadores de seguridad (enhorabuena a ellos). De los paquetes que revelaron las vulnerabilidades, pasaron una media de 27 días desde que se publicó el parche hasta que se asignó un CVE. El tiempo más rápido que observamos fue de sólo 1 día y el más largo de 9 meses.
Cómo funciona Intel (en detalle)
Sé que todos estamos hartos de las nuevas chorradas de la IA, pero Intel es una iniciativa del equipo de investigación de seguridad de Aikido y el equipo de IA de Aikido aprovecha la IA con un humano en el bucle para proporcionar una alimentación pública de amenazas para mejorar la seguridad de código abierto.
Intel trabaja leyendo todos los registros de cambios y notas de la versión disponibles públicamente para saber si se han realizado correcciones de seguridad pero no se han divulgado. Para conseguirlo, se utilizan dos modelos LLM, uno para filtrar los datos y eliminar todo el contexto innecesario para que el segundo LLM pueda centrarse en el análisis de vulnerabilidades. A continuación, un ingeniero de seguridad humano revisa los descubrimientos del LLM, valida las conclusiones y publica un Intel cuando se confirma una vulnerabilidad.
Se trata de un método tan eficaz porque consume notablemente menos potencia de cálculo que intentar escanear todos estos sistemas en busca de vulnerabilidades. Sin embargo, ha demostrado durante un año encontrar muchos resultados verdaderos.
Cómo ve Aikido Intel los Changelogs
Los registros de cambios son documentos mantenidos en proyectos de código abierto que registran actualizaciones, correcciones de errores, adiciones de características y parches. Algunos ejemplos son CHANGELOG.md mensajes de confirmación y notas de publicación de GitHub.
El Intel LLM identifica las entradas que sugieren cambios relacionados con la seguridad buscando:
- Palabras clave: "vulnerabilidad", "seguridad", "solución", "exploit", "validación de entradas", etc.
- Indicaciones contextuales: "Corregido un error crítico", "Parcheado un desbordamiento de búfer", "Resueltos los problemas de autenticación".
Ejemplo de entradas marcadas por el LLM:-
- Se ha resuelto una fuga de memoria que podía dar lugar a ataques de denegación de servicio.
- Se ha corregido una vulnerabilidad de cruce de rutas en la función de carga de archivos.
Seguridad de código abierto, cómo divulgar correctamente las vulnerabilidades
Como ya se ha dicho, la divulgación pública es un componente importante de la seguridad del código abierto. Se utilizan varias bases de datos diferentes para revelar cuándo un software tiene una vulnerabilidad en su interior. La principal base de datos es la National Vulnerability Database (NVD) que mantiene el gobierno estadounidense. Esta base de datos no sólo es utilizada por las empresas para comprobar su cadena de suministro, sino también por el software de seguridad que comprueba los proyectos con esta base de datos y otras (software SCA). Existen muchas otras bases de datos, como la base de datos de vulnerabilidades y exposiciones comunes (CVE) de Mitre, la base de datos de avisos de GitHub y muchas más; en total, Aikido comprueba 5 bases de datos diferentes. Pero lo que la mayoría de estas bases de datos tienen en común es que requieren que las vulnerabilidades sean divulgadas públicamente, por lo general después de que se haya publicado una corrección.
¿Por qué no se divulgan las vulnerabilidades?
Esta es una buena pregunta y quiero empezar diciendo que no hay ninguna buena razón para no revelar las vulnerabilidades. Tal vez la más común sea el riesgo para la reputación, que su software pueda ser visto como inseguro, pero yo diría que hay mucho más que perder por no revelar que por revelar.
Por qué el shadow patching es un problema para la seguridad de código abierto
No revelar públicamente las vulnerabilidades de su software crea un enorme riesgo para sus usuarios. Como dice el refrán, si no está roto, no lo arregles, y esto se aplica a menudo al software.
La actualización de los componentes de su software a menudo puede crear problemas en el rendimiento y la usabilidad o simplemente romper su aplicación, con esto en mente no siempre es una práctica común para actualizar inmediatamente los paquetes cuando una nueva versión está disponible.
Sin embargo, cuando hay un problema de seguridad en un componente es importante saberlo, ya que cambia la urgencia con la que actualizas tus componentes de código abierto y de terceros. No revelar esta información significa que es menos probable que los usuarios actualicen, lo que significa que tendrán fallos de seguridad en sus herramientas que no conocían, de ahí que el shadow patching sea un problema.
No deje que las vulnerabilidades ocultas comprometan su seguridad.
Asóciese con Aikido Security hoy mismo para proteger su cadena de suministro y ganar en tranquilidad.
.png)
.svg)
.png)
.png)
.png)
.jpg)
.jpg)
.jpg)
.jpg)
.png)