[26/08/2021] Las aplicaciones de software modernas se combinan a partir de miles de componentes de terceros obtenidos de repositorios públicos. Esta reutilización de código tiene importantes beneficios para la industria del software, ya que reduce el tiempo y los costos de desarrollo y permite a los desarrolladores agregar funcionalidades más rápidamente, pero también genera importantes problemas de administración de vulnerabilidades debido al complejo sistema de dependencias que a menudo son difíciles de rastrear.
[Reciba lo último de CIO Perú suscribiéndose a nuestro newsletter semanal]
Las vulnerabilidades heredadas del código de terceros han plagado las aplicaciones durante años, pero en la era de los ataques a la cadena de abastecimiento del software patrocinados por gobiernos, el problema es más relevante que nunca. Las herramientas de análisis de composición de software pueden ayudar a descubrir algunos de estos riesgos. Sin embargo, aún existen sutiles puntos ciegos de dependencia que le dificultan la detección de todas las fallas heredadas, incluso a los desarrolladores más preocupados por la seguridad.
Un análisis reciente del repositorio de NuGet, realizado por investigadores de seguridad de ReversingLabs, descubrió 50 mil paquetes que utilizaban una versión obsoleta y vulnerable de una biblioteca popular llamada zlib. Muchos de ellos no lo enumeraron explícitamente como una dependencia.
El seguimiento de las dependencias es impredecible
Para descubrir todas las vulnerabilidades, los desarrolladores deben realizar un seguimiento no solo de los componentes que utilizan en sus propias aplicaciones, sino también de las bibliotecas y paquetes de terceros en los que se basan esos componentes. Las cadenas de dependencia pueden llegar a muchas capas. En el 2019, un análisis realizado por investigadores de la Universidad de Darmstadt en el repositorio npm encontró que, en promedio, la importación de un paquete JavaScript introducía confianza implícita para otros 79 paquetes de 39 mantenedores diferentes. En ese momento, los investigadores también encontraron que casi el 40% de los paquetes se basaban en un código con, al menos, una vulnerabilidad conocida públicamente.
Un problema es que solo las dependencias que se relacionan con los paquetes en el mismo repositorio son rastreadas por los repositorios de paquetes y sus correspondientes herramientas de administración de paquetes. Pero esa no es la única forma en que el código de terceros se convierte en un proyecto. Algunos desarrolladores vinculan estáticamente bibliotecas o compilan manualmente código de otros proyectos que se encuentran fuera de los repositorios de paquetes, y esta información no es fácil de encontrar con herramientas de escaneo automatizadas.
ReversingLabs encontró más de 50 paquetes NuGet que contenían vulnerabilidades explotadas activamente porque incluían versiones obsoletas y vulnerables de 7Zip, WinSCP y PuTTYgen. Estos son programas de conectividad de red o compresión populares que no están alojados directamente en NuGet, pero que pueden tener paquetes de envoltura disponibles para ellos en NuGet creados por otros desarrolladores.
NuGet es el repositorio principal del lenguaje de programación .NET y la mayoría de los componentes alojados allí se envían como archivos ZIP con la extensión .nupkg y contienen bibliotecas .DLL de Windows, previamente compiladas, que están destinadas a ser importadas a otros proyectos de software.
Un paquete vulnerable de NuGet, encontrado por ReversingLabs, se llama WinSCPHelper y es una biblioteca contenedora para WinSCP. Permite que las aplicaciones que lo integran administren archivos en servidores remotos a través del protocolo SFTP. WinSCPHelper no se ha actualizado en NuGet desde el 2017, pero la última versión se descargó más de 34 mil veces desde su lanzamiento, y alrededor de 700 veces en las últimas seis semanas. La última versión de WinSCP es la 5.17.10 y contiene una actualización para una vulnerabilidad crítica de ejecución remota de código, pero la versión incluida con WinSCPHelper es mucho más antigua --la 5.11.2.
"Si bien en este caso el paquete analizado indica claramente que usa WinSCP, no revela la versión en la lista de dependencias y no se puede averiguar fácilmente qué vulnerabilidades afectan su dependencia subyacente”, afirmaron los investigadores. "Es un trabajo manual, todavía factible, pero requiere algo de esfuerzo”.
Identificación de vulnerabilidades silenciosas
Pero rastrear las dependencias puede ser incluso más difícil que eso. Tomemos el caso de zlib, una de las bibliotecas de compresión de datos de código abierto más utilizadas, que se escribió originalmente en 1995. Esta biblioteca se ha convertido en un estándar casi de facto y sus responsables la proporcionan como código fuente. Esto significa que los desarrolladores tienden a compilarlo ellos mismos y vincularlo estáticamente en sus proyectos, a menudo sin mencionar su presencia, ya que es muy ubicuo.
A través del análisis de archivos estáticos, ReversingLabs identificó más de 50 mil paquetes NuGet que utilizan zlib versión 1.2.8, que se lanzó en el 2013 y contiene cuatro vulnerabilidades de gravedad alta o crítica. Algunos de los paquetes identificados heredaron esta versión antigua de zlib y sus vulnerabilidades a través de otros componentes de terceros que no están claramente enumerados como dependencias, lo que llevó a los investigadores a referirse a ellos como vulnerabilidades silenciosas.
Un ejemplo proporcionado por ReversingLabs es un paquete NuGet llamado DicomObjects, que implementa el protocolo Digital Imaging and Communications in Medicine (DICOM). DICOM es un estándar utilizado para transmitir y administrar datos de imágenes médicas. Se usa ampliamente en hospitales y es compatible con muchos dispositivos de imágenes, como escáneres médicos, impresoras, servidores y estaciones de trabajo.
DicomObjects, utilizada por desarrolladores de software sanitario para crear fácilmente soluciones DICOM, tiene casi 54 mil descargas y es mantenido por una empresa con sede en el Reino Unido, llamada Medical Connections. El paquete enumera Microsoft.AspNet.WebApi.Client, Newtonsoft.Json y System.Net.Http como dependencias, pero según ReversingLabs, también incluye una biblioteca PDF comercial llamada ceTe.DynamicPDF.Viewer.40.x86.dll que no es mencionada explícitamente en cualquier lugar. DynamicPDF Viewer aparece en NuGet como un paquete separado, pero la versión incluida en DicomObjects es mucho más antigua, una que incluye zlib 1.2.8.
"Este es uno de los problemas de mantenimiento de software más comunes”, señalaron los investigadores. "Los desarrolladores crean un paquete de software, deciden utilizar software de terceros, pero durante las actualizaciones posteriores, las dependencias se pasan por alto. En este caso, las cosas son aún peores porque no se menciona explícitamente en ninguna parte que el paquete DicomObjects depende de DynamicPDF.Viewer. No hay forma de saber que DynamicPDF.Viewer depende de la biblioteca zlib vulnerable. Apilar dependencias ocultas de esta manera conduce a múltiples niveles de vulnerabilidades silenciosas, y hace que el mantenimiento y la auditoría del software sean significativamente más difíciles".
Medical Connections no respondió de inmediato a una solicitud de comentarios.
Otro ejemplo es un paquete muy popular llamado librdkafka.redist, una biblioteca C que implementa el protocolo Apache Kafka. Apache Kafka es un marco de trabajo para el procesamiento de flujos de alto rendimiento de código abierto, destinado a manejar fuentes de datos en tiempo real. El paquete librdkafka.redist tiene 18,9 millones de descargas, de las cuales 312 mil corresponden a la última versión, la 1.7.0, lanzada hace dos meses. Esta versión de librdkafka.redist usa zlib 1.2.8, pero esto no se indica explícitamente en la lista de dependencias del proyecto en NuGet o GitHub.
Hace más de un año, el problema se reportó en el rastreador de errores del proyecto en GitHub y actualmente está marcado para su corrección en la versión 1.8.0. El desarrollador principal del proyecto, Magnus Edenhill, revisó las cuatro vulnerabilidades de zlib y afirmó que solo dos de ellas se aplican a librdkafka, y que el riesgo de explotarlas con éxito a través de mensajes consumidos de Kafka parece muy bajo. Edenhill no respondió de inmediato a una solicitud de comentarios.
Otros 13 paquetes de NuGet dependen de librdkafka.redist, incluidos algunos desarrollados por una empresa de infraestructura de datos llamada Confluent, que tiene muchos clientes de grandes empresas.
"El desarrollo de software seguro es un problema complejo, ya que involucra a muchos participantes en múltiples etapas de desarrollo”, afirmaron los investigadores de ReversingLabs. "Independientemente del tipo de software que produzca su empresa, más temprano que tarde, será necesario incluir dependencias de terceros en su solución. Esto introducirá la necesidad de administrar los riesgos de seguridad y calidad del código. Los ataques a la cadena de abastecimiento de software son una amenaza creciente para la comunidad cibernética. Son el análogo DDoS de las brechas tradicionales”.
Riesgos de la cadena de abastecimiento
NuGet no es el único repositorio de paquetes donde existe este problema de dependencia vulnerable, y se podría argumentar que no depende de NuGet u otros repositorios obligar a los desarrolladores a prestar más atención a estos problemas. Sin embargo, algunas plataformas son más proactivas que otras. GitHub escanea activamente los repositorios de código público alojados en su plataforma, analiza sus dependencias y notifica a sus propietarios si alguna de esas dependencias tiene vulnerabilidades conocidas. La compañía mantiene una base de datos de asesoramiento público con vulnerabilidades conocidas en npm (JavaScript), RubyGems (Ruby), NuGet (.NET), pip (Python), Maven (Java) y acaba de anunciar soporte para los módulos Go.
En su Informe de la cadena de abastecimiento de software del 2020, la empresa de gobernanza de código abierto, Sonatype, observó un crecimiento interanual del 430% en la cantidad de ataques de siguiente generación en los que, en un intento de envenenar proyectos y aplicaciones adicionales más arriba en su cadena de dependencia, los hackers intentaron inyectar activamente malware en proyectos de software de código abierto. Los ataques tradicionales en los que los hackers explotan vulnerabilidades conocidas en componentes de código abierto han seguido siendo fuertes, pero el tiempo para explotar ha disminuido y los atacantes explotan vulnerabilidades recién descubiertas a los pocos días de su divulgación pública. Mientras tanto, la mitad de las empresas tardan más de una semana en enterarse de estos defectos y una semana o más después en implementar las mitigaciones.
Los atacantes están claramente interesados en explotar la cadena de abastecimiento de software. Sin embargo, miles de paquetes de software con vulnerabilidades heredadas todavía se encuentran en repositorios públicos y sirven como bloques de base para el software empresarial.
Basado en el artículo de Lucian Constantin (CSO) y editado por CIO Perú