Intel es nuestra fuente de inteligencia de amenazas de seguridad de código abierto impulsada por IA y nuestro equipo de investigación interno. Intel monitoriza 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 fueron reveladas
El software de código abierto impulsa el mundo, literalmente. Sin embargo, la seguridad del código abierto es también un área de gran preocupación en materia de seguridad. Las herramientas de código abierto, como todo lo demás, pueden introducir vulnerabilidades de seguridad. Estas pueden ser utilizadas por atacantes para explotar su aplicación. Dejando a los proveedores de software expuestos a ataques sin que sea culpa suya. Esto convierte la seguridad del código abierto en un tema muy importante.
No solo dependemos de la comunidad de código abierto para construir y mantener estas herramientas, sino que también confiamos en ellos para corregir cualquier vulnerabilidad de seguridad conocida. Es importante destacar que también dependemos de estos mantenedores para informar públicamente sobre las vulnerabilidades cuando se descubren. La divulgación pública de vulnerabilidades por parte de la comunidad constituye la base de la seguridad de código abierto.
El parcheo silencioso, o parcheo en la sombra, es cuando se aplica una corrección de seguridad (se parchea) pero nunca se divulga. Esto es un problema importante porque significa que los proveedores pueden estar ejecutando software vulnerable sin ser conscientes del riesgo.
Lanzamos Aikido Intel para sacar a la luz el software parcheado silenciosamente que podría afectarte. Con Aikido Intel, podemos dar a los desarrolladores la advertencia más temprana posible si encontramos vulnerabilidades que puedan afectarles y mejorar la seguridad del código abierto.
¿Qué es Aikido Intel?
Aikido Intel es una iniciativa de IA + nuestro equipo de investigación interno para mejorar la seguridad de código abierto mediante el descubrimiento de vulnerabilidades en la cadena de suministro de código abierto en el momento más temprano posible. Incluso antes de que se divulguen en una base de datos de vulnerabilidades. Para lograr esto, 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 código abierto mantiene un registro de cambios (change log) 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 lanzamiento para encontrar ejemplos de dónde se han parcheado problemas de seguridad. Esto se compara luego con 5 bases de datos de vulnerabilidades para ver si el problema ha sido reportado. Si no, un ingeniero de seguridad analiza y evalúa la vulnerabilidad, asignándole un número de vulnerabilidad Aikido y una severidad, y lo anuncia públicamente para que 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 representa una amenaza real para cualquiera que utilice esos paquetes.
A veces puede pasar un tiempo entre la aplicación de un parche a una vulnerabilidad y la asignación de un número CVE al problema. 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 se divulgaron públicamente en ninguna base de datos de vulnerabilidades!
Si bien no sorprende que las vulnerabilidades de baja gravedad se parcheen silenciosamente con mayor frecuencia, sigue siendo impactante que más del 50% de las vulnerabilidades de gravedad alta y crítica nunca se revelen. Esto crea un enorme punto ciego para desarrolladores y proveedores de software.
Sé que algunos de vosotros os estaréis removiendo en vuestros asientos diciendo que quizás estos son proyectos de código abierto pequeños, no tan populares, con políticas de seguridad limitadas, pero en realidad, os equivocaríais. Encontramos algunas vulnerabilidades no divulgadas en proyectos muy grandes.
Axios, un cliente HTTP basado en promesas para navegadores y node.js con 56 millones de descargas semanales y más de 146.000 dependencias, solucionó una vulnerabilidad de contaminación de prototipos en enero de 2024 que nunca se había divulgado públicamente.
Dato curioso sobre esta vulnerabilidad: Esta fue en realidad la primera vulnerabilidad que encontró Aikido Intel (Ver número 2023-10001)…. ¡Permanece sin revelar hasta el día de hoy!
No quiero darles todo el mérito, Axios no está solo, hay otros nombres que merecen una mención especial. Apache parcheó silenciosamente una vulnerabilidad en el software echarts para cross-site scripting que nunca fue divulgada.
Otro ejemplo interesante que descubrimos fue una vulnerabilidad crítica de path traversal en Chainlit que fue parcheada en septiembre, pero la vulnerabilidad nunca se divulgó públicamente.
Las vulnerabilidades más comunes
Cross-site scripting fue la vulnerabilidad no revelada más común, representando el 14,8%, seguida de la exposición de información sensible con un 12,3%. En total, detectamos 90 tipos diferentes de vulnerabilidades, generando una larga cola de resultados; a continuación se presentan algunas de las más comunes.
Las vulnerabilidades más comunes descubiertas
Si nos fijamos solo en las vulnerabilidades críticas 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: solo Críticas y Altas
Tiempo hasta la divulgación
Si bien en el momento de redactar esto, el 67% de los paquetes nunca revelaron sus vulnerabilidades, el 31% sí lo hizo, ya fuera por parte de los mantenedores o de los investigadores de seguridad (un aplauso para ellos). De los paquetes que sí revelaron las vulnerabilidades, se tardó una media de 27 días desde el lanzamiento del parche hasta la asignación de un CVE. El tiempo más rápido que observamos fue de solo 1 día y el más largo fue de 9 meses.
Cómo funciona Intel (en detalle)
Sé que todos estamos hartos de las nuevas tonterías 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 un feed de amenazas público y mejorar la seguridad de código abierto.
Intel funciona leyendo todos los registros de cambios y notas de lanzamiento disponibles públicamente para comprender si se han realizado correcciones de seguridad que no se han divulgado. Para lograrlo, se utilizan dos modelos LLM, uno para filtrar los datos y eliminar todo el contexto innecesario, de modo que el segundo LLM pueda centrarse en el análisis de vulnerabilidades. A continuación, un human security revisa los descubrimientos del LLM, valida los resultados y publica un Intel cuando se confirma una vulnerabilidad.
Este es un método tan eficaz porque consume notablemente menos potencia computacional que intentar escanear todos estos sistemas en busca de vulnerabilidades. Sin embargo, durante más de un año ha demostrado encontrar muchos resultados verdaderos.
¿Cómo son vistos los Changelogs por Aikido Intel?
Los changelogs son documentos que se mantienen en proyectos de código abierto y que registran actualizaciones, correcciones de errores, adiciones de características y parches. Entre los ejemplos se incluyen CHANGELOG.md archivos, mensajes de commit y notas de lanzamiento de GitHub.
El LLM de Intel identifica entradas que sugieren cambios relacionados con la seguridad buscando:
- Palabras clave: “vulnerabilidad,” “seguridad,” “corrección,” “exploit,” “validación de entrada,” etc.
- Pistas contextuales: "Se corrigió un error crítico", "Se parcheó un desbordamiento de búfer", "Se resolvieron problemas de autenticación".
Ejemplos de entradas marcadas por el LLM:- Se corrigió un problema de saneamiento de entrada en el manejador de inicio de sesión.
- Se resolvió una fuga de memoria que podría conducir a ataques de denegación de servicio.
- Se abordó una vulnerabilidad de path traversal en la funcionalidad de carga de archivos.
Seguridad de código abierto: cómo se divulgan correctamente las vulnerabilidades
Como se ha mencionado anteriormente, la divulgación pública es un componente importante de la seguridad del código abierto. Se utilizan varias bases de datos diferentes para divulgar cuándo un software tiene una vulnerabilidad. La base de datos principal es la Base de Datos Nacional de Vulnerabilidades (NVD), que mantiene el gobierno de los Estados Unidos. Esta base de datos no solo la utilizan las empresas para comprobar su cadena de suministro, sino también el software de seguridad que comprueba los proyectos con esta base de datos y otras (SCA ). Existen otras muchas 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 cinco bases de datos diferentes. Pero lo que la mayoría de estas bases de datos tienen en común es que exigen que las vulnerabilidades se divulguen públicamente, normalmente 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 una buena razón para no divulgar vulnerabilidades. Quizás la más común sea el riesgo reputacional, que su software pueda ser visto como inseguro, pero yo diría que hay mucho más que perder al no divulgar que al divulgar.
Por qué el parcheo en la sombra es un problema para la seguridad de código abierto
No divulgar públicamente las vulnerabilidades de tu software crea un enorme riesgo para tus usuarios. Como dice el refrán, si no está roto, no lo arregles, esto se aplica con bastante frecuencia al software.
Actualizar los componentes de tu software a menudo puede generar problemas de rendimiento y usabilidad, o simplemente romper tu aplicación. Teniendo esto en cuenta, no siempre es una práctica común actualizar inmediatamente los paquetes cuando hay una nueva versión 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 divulgar esta información significa que los usuarios son menos propensos a actualizar, lo que implica que tendrán fallos de seguridad en sus herramientas de los que no eran conscientes, de ahí que el parcheo en la sombra sea un problema tan grande.
No permitas que las vulnerabilidades ocultas comprometan tu seguridad.
Asóciese Aikido Security con Aikido Security para proteger su cadena de suministro y ganar tranquilidad.
Protege tu software ahora.
.avif)
