Gamers ahora disponen en Latam de SSD más fría
Los ataques a la supply chain aumentaron más del 600% este año y las empresas se están quedando atrás en sus gestiones de código abierto.
La mayoría de las empresas creen que no utilizan bibliotecas de software de código abierto con vulnerabilidades conocidas, pero una nueva investigación las encuentra en el 68% de las aplicaciones empresariales seleccionadas.
Por Lucian Constantin | Original de IDGN
La cantidad de ataques documentados a la cadena de suministros que involucran componentes maliciosos de terceros ha aumentado un 633% durante el último año y, ahora, se ubica en más de 88.000 instancias conocidas, según un nuevo informe de la empresa de administración de la cadena de suministro de software Sonatype.
Mientras tanto, los casos de vulnerabilidades transitivas que los componentes de software heredan de sus propias dependencias también han alcanzado niveles sin precedentes: afectan a dos tercios de las bibliotecas de código abierto.
“La naturaleza interconectada de las dependencias resalta la importancia de tener visibilidad y conocimiento sobre estas cadenas de suministro complejas”, expluca Sonatype en su informe recientemente publicado “State of the Software Supply Chain”.
“Estas dependencias afectan nuestro software por lo que comprender sus orígenes es fundamental para la respuesta a la vulnerabilidad. Muchas organizaciones no tenían la visibilidad necesaria y, como resultado, continuaron con sus procedimientos de respuesta a incidentes para Log4Shell mucho más allá del verano de 2022”, señala el documento.
Falla extendida
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 iniciar sesión.
La misma suele incluirse tanto en millones de aplicaciones empresariales como en productos de software, a menudo como una dependencia indirecta.
Según el seguimiento de Sonatype, a partir de agosto de 2022 la tasa de adopción de versiones fijas de Log4j ronda el 65%.
Además, esto ni siquiera tiene en cuenta el hecho de que la vulnerabilidad de Log4Shell se originó en una clase de Java llamada JndiManager que forma parte de Log4j-core, pero que también ha sido tomada prestada por otros 783 proyectos.
De hecho, JndiManager ahora se encuentra en más de 19.000 componentes de software.
Log4Shell sirvió como un momento decisivo, destacando los riesgos inherentes que existen en el ecosistema de software de código abierto – el cual se encuentra en el centro del desarrollo de software moderno – y la necesidad de administrarlos adecuadamente.
También condujo a varias iniciativas para asegurar la cadena de suministros de software por parte de:
- Organizaciones privadas
- Administradores de repositorios de software
- La Fundación Linux
- Y organismos gubernamentales
El consumo de código abierto sigue creciendo
Sin embargo, la mayoría de las organizaciones están lejos de donde deben estar en términos de gestión de la cadena de suministro de código abierto.
El crecimiento promedio, año tras año, en las descargas de paquetes de los principales repositorios de componentes es de 33% en:
- Maven Central (Java)
- npm (JavaScript)
- PyPi (Python)
- Y NuGet (.NET)
Esto es más bajo que en años anteriores:
- El crecimiento en 2021 fue del 73%
- Pero la cantidad de descargas de componentes ya superó las cifras de 2021 en todos los repositorios
- Y, en conjunto, supera los 3 billones (millardo en nomenclatura hispánica)
Sólo el repositorio npm servirá más descargas este año que los cuatro repositorios durante el 2021.
La disminución en la tasa de consumo de código abierto no se debe, necesariamente, a que los usuarios implementen políticas de administración y adquisición del mismo más estrictas sino que es normal, dado el tamaño que han alcanzado estos ecosistemas para diferentes lenguajes de programación, así como su tasa de agregar nuevos proyectos y lanzamientos.
“Aunque el ritmo de crecimiento se está desacelerando, la escala absoluta de crecimiento continúa aumentando en las tasas anuales anteriores. El ritmo de adopción del código abierto no muestra signos de agotarse en el corto plazo”, concluyó Sonatype.
Los tipos de ataques a la cadena de suministro se han diversificado
Sonatype había rastreado alrededor de 12.000 casos conocidos de ataques maliciosos a la cadena de suministro hasta finales del año pasado, pero ese número ahora ha aumentado a más de 88.000, un crecimiento interanual del 633%.
La empresa también ha descubierto 97.334 paquetes maliciosos distribuidos de diversas formas.
Uno de los principales contribuyentes al crecimiento de los paquetes maliciosos es una técnica de ataque llamada confusión de dependencia que los investigadores de seguridad divulgaron públicamente en febrero de 2021 y que, desde entonces, ha tenido una amplia adopción.
La técnica explota el comportamiento de la mayoría de los clientes de gestión de paquetes configurados para buscar paquetes tanto en repositorios comunitarios públicos como en los internos.
Cuando existe un nombre de paquete 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 usan paquetes desarrollados internamente que solo existen en sus repositorios internos y nunca fueron destinados a ser publicados.
Sin embargo, si los atacantes encuentran los nombres de esos paquetes en 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 creación de software.
Ataques furtivos
Es difícil decir si todos los casos de ataques de confusión de dependencia han sido de naturaleza maliciosa porque la técnica también es popular entre los evaluadores de penetración.
Sin embargo, las organizaciones pueden protegerse registrando los nombres de sus paquetes privados en los repositorios públicos o usar prefijos para todos sus paquetes que luego pueden registrarse como espacios de nombres o ámbitos en estos repositorios públicos, lo cual significa que los atacantes ya no podrían publicar paquetes con esos prefijos.
Otros tipos de ataques masivos que se conocen desde hace un tiempo son el typosquatting y el brandjacking.
Typosquatting implica que los atacantes registren paquetes maliciosos con nombres similares a los de algunos paquetes populares y ampliamente utilizados.
Este es un ataque pasivo que se basa en que los desarrolladores cometen errores (errores tipográficos) al escribir nombres de paquetes en sus scripts o comandos de compilación.
Brandjacking es similar pero se dirige a otros portadores de paquetes, con la esperanza de que incluyan uno secuestrado o con errores tipográficos como una dependencia en sus propios componentes.
Esto también puede suceder cuando el portador de un paquete legítimo pasa la propiedad a otra persona, o cuando deja de desarrollar ese paquete, lo elimina y el nombre anterior vuelve a estar disponible.
La inyección de código malicioso es otra técnica que está más dirigida e involucra atacantes que comprometen el sistema o el repositorio de código de un desarrollador e inyectan código malicioso en su paquete sin su conocimiento.
Esto también puede suceder cuando un portador de paquetes le da a varias partes acceso de compromiso a sus repositorios de código y esas partes tienen intenciones maliciosas o se ven comprometidas.
Otro tipo de ataque del tipo de la inyección de código malicioso pero perpetrado por desarrolladores legítimos se conoce como protestware y se refiere a incidentes en los que un desarrollador agrega código malicioso a su propio paquete, previamente limpio, como señal de protesta.
Elegir componentes con buenas prácticas de seguridad
Crear y mantener un inventario de los componentes utilizados en todos los esfuerzos internos de desarrollo de software 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 comúnmente utilizadas en aplicaciones empresariales y descubrió que solo el 10% de ellas tenía una vulnerabilidad directamente en su código.
Sin embargo, al incluir vulnerabilidades transitivas heredadas de dependencias y dependencias de esas dependencias, la incidencia aumentó al 62%.
En promedio, cada biblioteca tenía 5,7 dependencias.
Además, elegir componentes basados en una tasa más baja de vulnerabilidades no se traduce necesariamente en mejores resultados de seguridad a largo plazo porque hay muchos sesgos en la forma en que los investigadores eligen los proyectos que quieren analizar.
Árbol pequeño de pocas ramas
En otras palabras, un proyecto popular podría tener una mayor cantidad de vulnerabilidades descubiertas solo porque hay más ojos sobre él.
En este punto, los investigadores de Sonatype sugieren que, dado que la mayoría de las vulnerabilidades surgen de las dependencias transitivas, la guía más clara es considerar cuidadosamente cada biblioteca que usa.
“Prefiere los que tienen árboles de dependencia más pequeños. Busque proyectos que se actualicen rápidamente cuando se publiquen nuevas versiones de sus dependencias (MTTU bajo: tiempo medio de actualización). Minimizar el número total de dependencias y mantener tiempos de actualización bajos para las dependencias de su propio proyecto son dos factores críticos para reducir el riesgo de vulnerabilidades transitivas”.
Hay varias métricas disponibles para juzgar las prácticas de seguridad de los proyectos de código abierto.
Uno de ellos es el sistema Security Scorecard desarrollado por Open Source Security Foundation (OpenSSF).
Este sistema realiza una serie de comprobaciones automáticas para verificar:
- Si los proyectos de código abierto tienen vulnerabilidades no corregidas
- Si usan herramientas para ayudar a actualizar sus dependencias
- Si ejecutan pruebas de CI
- Si ejecutan fuzzing de código automatizado,
- Si usan herramientas de análisis de código estático
- Si evitan prácticas de codificación peligrosas
- Si realizan una revisión del código antes de fusionar código nuevo
- Si declaran y fijan sus dependencias
- Y mucho más
Sonatype usó 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 fueron las revisiones de código sin incluir:
- Artefactos binarios
- Evitar prácticas de codificación peligrosas (protección de sucursales)
- Fijación de dependencias
- Y revisar las confirmaciones de código.
“Seguimos recomendando que los desarrolladores seleccionen componentes con el MTTU, Security Scorecard, OpenSSF Criticality y SourceRank más altos en ese orden. Entendemos que tratar de agregar y sopesar los distintos puntajes puede ser difícil. Lo hemos hecho más fácil al agregar la nueva calificación de seguridad de Sonatype a nuestro índice OSS de la base de datos pública de vulnerabilidades”, dijeron los investigadores de Sonatype.
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 e hizo 40 preguntas sobre el 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.
Los puntajes más altos se dieron en las categorías de inventario de aplicaciones y reparación.
Por ejemplo:
- 68% de los encuestados dijo que confiaba en que sus aplicaciones no usaban bibliotecas vulnerables conocidas
- Y el 84% dijo que analizan el historial de seguridad de los componentes de código abierto que usan
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 recopilados durante la encuesta y desglosamos los resultados por título de trabajo”, dijeron los investigadores.
Señalaron que los hallazgos fueron esclarecedores al mostrar que existe un sesgo continuo hacia ver las cosas bajo una mejor luz, en la que los gerentes informan etapas más altas de madurez en comparación con lo que informan otros roles.
“En toda la encuesta, esta discrepancia es estadísticamente significativa cuando se comparan los administradores de TI y los que trabajan en roles de seguridad de la información” .
