Los ciberataques a la cadena de suministro de 'software' han aumentado más del 600% este año

El número de ciberataques a la cadena de suministro de software que implican componentes maliciosos de terceros ha aumentado un 633% en el último año, llegando a ser más de 88.000 casos conocidos, según un nuevo informe de Sonatype. Según el análisis, los casos de vulnerabilidades transitivas que los componentes de software heredan de sus propias dependencias también han alcanzado niveles sin precedentes y afectan a dos tercios de las bibliotecas de código abierto.

"La naturaleza de las dependencias en red pone de manifiesto la importancia de tener visibilidad y conocimiento de estas complejas cadenas de suministro", afirma Sonatype en su recién publicado informe State of the Software Supply Chain. "Estas dependencias afectan a nuestro software, por lo que conocer su origen es fundamental para responder a las vulnerabilidades. Como resultado, muchas organizaciones no tenían la visibilidad necesaria y continuaron sus procedimientos de respuesta a incidentes para Log4Shell mucho más allá del verano de 2022".

Log4Shell es una vulnerabilidad crítica descubierta en noviembre de 2021 en Log4j, una biblioteca Java de código abierto muy popular que se utiliza para el logging y se incluye en millones de aplicaciones empresariales y productos de software, a menudo como una dependencia indirecta. Según el seguimiento de Sonatype, en agosto de 2022, la tasa de adopción de versiones corregidas de Log4j se situaba en torno al 65%. Además, esto no tiene en cuenta el hecho de que la vulnerabilidad de Log4Shell se originó en una clase Java llamada JndiManager que forma parte del núcleo de Log4j, pero que también ha sido tomada prestada por otros 783 proyectos y ahora se encuentra en más de 19.000 componentes de software.

Log4Shell marcó un hito, ya que puso de manifiesto los riesgos inherentes al ecosistema del software de código abierto -que se encuentra en el centro del desarrollo de software moderno- y la necesidad de gestionarlos adecuadamente. También dio lugar a varias iniciativas para asegurar la cadena de suministro de software por parte de organizaciones privadas, gestores de repositorios de software, la Fundación Linux y organismos gubernamentales. Sin embargo, la mayoría de las organizaciones están lejos de lo que necesitan en cuanto a la gestión de la cadena de suministro de código abierto.

El consumo de código abierto sigue creciendo

El crecimiento medio anual de las descargas de paquetes de los principales repositorios de componentes -Maven Central (Java), npm (JavaScript), PyPi (Python) y NuGet (.NET)- es del 33%. Esta cifra es inferior a la de años anteriores, como el crecimiento del 73% de 2021, pero el número de descargas de componentes ya ha superado las cifras de 2021 en todos los repositorios y se sitúa colectivamente en más de 3 billones. Solo el repositorio npm servirá más descargas este año que los cuatro repositorios en 2021.

El descenso en la tasa de consumo de código abierto no se debe necesariamente a que los usuarios apliquen políticas más estrictas de adquisición y gestión de código abierto, sino que es normal dado el tamaño que han alcanzado estos ecosistemas de diferentes lenguajes de programación y su ritmo de incorporación de nuevos proyectos y lanzamientos.

"Aunque el ritmo de crecimiento se está ralentizando, la escala absoluta de crecimiento sigue aumentando con respecto a las tasas anuales anteriores", concluye Sonatype. "El ritmo de adopción del código abierto no muestra signos de agotamiento a corto plazo".

Los tipos de ataques a la cadena de suministro se han diversificado

Sonatype había rastreado alrededor de 12.000 instancias conocidas de ataques maliciosos a la cadena de suministro hasta finales del año pasado, pero ese número ha crecido ahora a más de 88.000, un crecimiento del 633% interanual. La empresa también ha descubierto 97.334 paquetes maliciosos distribuidos de diversas formas.

Uno de los principales responsables del crecimiento de los paquetes maliciosos es una técnica de ataque denominada confusión de dependencias, que fue revelada públicamente por investigadores de seguridad en febrero de 2021 y que desde entonces ha sido ampliamente adoptada. La técnica aprovecha el comportamiento de la mayoría de los clientes de gestión de paquetes configurados para buscar paquetes tanto en los repositorios públicos de la comunidad como en los internos.

Cuando el nombre de un paquete existe en ambas ubicaciones, el cliente extraerá el que tenga el número de versión más alto. Esto causa un problema porque muchas organizaciones utilizan paquetes desarrollados internamente que sólo existen en sus repositorios internos y nunca fueron pensados para ser publicados abiertamente. Sin embargo, si los atacantes encuentran los nombres de esos paquetes a partir de los archivos de manifiesto, pueden publicar paquetes maliciosos con esos nombres en los repositorios públicos, con un número de versión más alto para engañar a los clientes de construcción de software.

Es difícil decir si todos los casos de ataques de confusión de dependencias han sido de naturaleza maliciosa porque la técnica también es popular entre los probadores de penetración. Sin embargo, las organizaciones pueden protegerse registrando los nombres de sus paquetes privados en los repositorios públicos o utilizando prefijos para todos sus paquetes que luego pueden registrarse como espacios de nombres o ámbitos en los repositorios públicos, lo que significa que los atacantes ya no deberían poder publicar paquetes con esos prefijos.

Otros tipos de ataques masivos conocidos desde hace tiempo son el typosquatting y el brandjacking. El typosquatting consiste en que los atacantes registran paquetes maliciosos con nombres similares a los de algunos paquetes populares y ampliamente utilizados. Se trata de un ataque pasivo que se basa en que los desarrolladores cometen errores (erratas) al escribir los nombres de los paquetes en sus scripts o comandos de compilación.

El brandjacking es similar, pero se dirige a otros mantenedores de paquetes con la esperanza de que incluyan un paquete secuestrado o con errores tipográficos como dependencia en sus propios componentes. Esto también puede ocurrir cuando el mantenedor de un paquete legítimo pasa la propiedad a otra persona, o cuando dejan de desarrollar ese paquete y lo borran y el nombre antiguo queda disponible.

La inyección de código malicioso es otra técnica más selectiva y consiste en que los atacantes comprometan el sistema o el repositorio de código de un desarrollador e inyecten código malicioso en su paquete sin su conocimiento. Esto también puede ocurrir cuando un mantenedor de paquetes da a varias partes acceso a sus repositorios de código y esas partes tienen intenciones maliciosas o se ven comprometidas.

Otro tipo de ataque similar a la inyección de código malicioso pero perpetrado por desarrolladores legítimos se conoce como protestware. Se trata de incidentes en los que un desarrollador añade código malicioso a su propio paquete, previamente limpio, como señal de protesta.

Elegir componentes con buenas prácticas de seguridad

Construir y mantener un inventario de componentes utilizados en todos los esfuerzos de desarrollo de software interno y rastrear las vulnerabilidades descubiertas en ellos es un aspecto clave para mitigar los riesgos de seguridad. Sin embargo, tener políticas claras sobre la procedencia de los componentes es igual de importante. Elegir componentes o bibliotecas con una baja incidencia de vulnerabilidades en su propio código no es una garantía, porque muchos de ellos pueden heredar vulnerabilidades de sus propias dependencias, por lo que el tiempo que tardan en responder a dichas vulnerabilidades y actualizar sus propias dependencias es crítico.

Sonatype analizó un conjunto de más de 12.000 bibliotecas utilizadas habitualmente en las aplicaciones empresariales y descubrió que sólo el 10% de ellas tenía una vulnerabilidad directamente en su código. Sin embargo, al incluir las vulnerabilidades transitivas heredadas de las dependencias y las dependencias de esas dependencias, la incidencia se elevó al 62%. De media, cada biblioteca tenía 5,7 dependencias.

Además, la elección de componentes basados en un menor índice de vulnerabilidades no se traduce necesariamente en mejores resultados de seguridad a largo plazo, ya que existe un gran sesgo en la forma en que los investigadores eligen los proyectos que quieren examinar. En otras palabras, un proyecto popular podría tener un mayor número de vulnerabilidades descubiertas sólo porque hay más ojos sobre él.

"Dado que la mayoría de las vulnerabilidades surgen de las dependencias transitivas, la orientación más clara es considerar cuidadosamente todas las bibliotecas que se utilizan", dicen los investigadores de Sonatype. "Favorezca las que tengan árboles de dependencias más pequeños. Busque proyectos que se actualicen rápidamente cuando se publiquen nuevas versiones de sus dependencias (bajo MTTU o tiempo medio de actualización). Minimizar el número total de dependencias y mantener bajos los tiempos de actualización de las dependencias del propio proyecto son dos factores críticos para reducir el riesgo de vulnerabilidades transitivas".

Existen varias métricas para juzgar las prácticas de seguridad de los proyectos de código abierto. Una de ellas es el sistema Security Scorecard desarrollado por la Open Source Security Foundation (OpenSSF). Este sistema realiza una serie de comprobaciones automatizadas para verificar si los proyectos de código abierto tienen vulnerabilidades no corregidas, si utilizan herramientas para ayudar a actualizar sus dependencias, si ejecutan pruebas de CI, si ejecutan fuzzing de código automatizado, si utilizan herramientas de análisis de código estático, si evitan prácticas de codificación peligrosas, si realizan una revisión de código antes de fusionar código nuevo, si declaran y fijan sus dependencias, y mucho más.

Sonatype utilizó sus propios datos para evaluar el impacto que tienen algunas de esas prácticas en la reducción de la posibilidad de que un proyecto tenga vulnerabilidades y descubrió que las acciones de mayor impacto eran las revisiones de código, la no inclusión de artefactos binarios, evitar las prácticas de codificación peligrosas (protección de ramas), la fijación de dependencias y la revisión de los commits de código.

"Seguimos recomendando a los desarrolladores que seleccionen los componentes con mayor MTTU, Security Scorecard, OpenSSF Criticality y SourceRank en ese orden", dijeron los investigadores de Sonatype. "Entendemos que tratar de agregar y sopesar las distintas puntuaciones puede ser difícil. Lo hemos hecho más fácil añadiendo el nuevo Sonatype Safety Rating a nuestra base de datos pública de vulnerabilidades OSS Index".

Las empresas confían demasiado en sus prácticas de código abierto

Sonatype realizó una encuesta a 662 profesionales de la ingeniería empresarial y les hizo 40 preguntas sobre su uso de componentes de código abierto, gestión de dependencias, gobernanza, procesos de aprobación y herramientas. La mayoría de las respuestas indicaron niveles de gestión de la cadena de suministro inferiores a los necesarios para producir resultados de alta calidad en la evaluación de Sonatype.

Las puntuaciones más altas se dieron en las categorías de remediación e inventario de aplicaciones. Por ejemplo, el 68% de los encuestados dijo que confiaba en que sus aplicaciones no utilizaban bibliotecas vulnerables conocidas y el 84% dijo que examinaba el historial de seguridad de los componentes de código abierto que utilizaba. Sin embargo, esto no coincidió con los hallazgos de Sonatype en la práctica, donde un análisis de 55.000 aplicaciones empresariales seleccionadas al azar reveló que el 68% de ellas tenía vulnerabilidades conocidas.

"Aprovechamos los datos demográficos recogidos durante la encuesta y desglosamos los resultados por puestos de trabajo", dijeron los investigadores. "Los resultados fueron esclarecedores. Existe un sesgo continuo hacia una mejor visión de las cosas, en la que los directivos informan de etapas de madurez más altas en comparación con lo que informan otros roles. En toda la encuesta, esta discrepancia es estadísticamente significativa cuando se comparan los directores de TI y los que trabajan en funciones de seguridad de la información".