Cómo el código C++ de código abierto puede introducir riesgos de seguridad

Las bibliotecas y los frameworks de código abierto son una excelente manera de poner en marcha proyectos de desarrollo. El código abierto permite a los desarrolladores lograr grandes cosas sin reinventar la rueda ni desarrollar soluciones para problemas que ya se resolvieron.

Sin embargo, agregar cualquier código a un proyecto conlleva el riesgo inherente de introducir posibles vulnerabilidades que hayan llegado hasta él por error o de forma maliciosa.

Este artículo explora cómo el código de código abierto introduce vulnerabilidades en la cadena de suministro de software. También destaca cómo puedes identificar vulnerabilidades en la seguridad del código abierto en C++ mediante escáneres automatizados de vulnerabilidades.

Cómo el código de código abierto introduce riesgos de seguridad

El ecosistema de software de código abierto está profundamente interconectado. Cuando instalas un componente de código abierto en tu código, este incluye dependencias. Es difícil estar al tanto de forma continua de los problemas de seguridad que puede contener cada dependencia, y no siempre puedes confiar en que los responsables de mantener los paquetes corrijan estas vulnerabilidades a tiempo. Esto significa que puede haber vulnerabilidades sin corregir en los paquetes de código abierto presentes en tu base de código.

Los datos de una investigación reciente de Snyk y la Linux Foundation muestran que el tiempo necesario para corregir vulnerabilidades en proyectos de código abierto ha aumentado de forma constante: pasó de 49 días en 2018 a 110 días en 2021. Corregir vulnerabilidades en proyectos de código abierto toma casi un 20 % más de tiempo (18,75 %) que en proyectos propietarios. Debido a estas complejidades, las aplicaciones de código abierto con vulnerabilidades conocidas son un objetivo atractivo para los hackers.

Las vulnerabilidades de desbordamiento de búfer son frecuentes en lenguajes de programación de bajo nivel, como C o C++, porque los desarrolladores son responsables de asignar la memoria. C y C++ no protegen la aplicación cuando los clientes acceden a datos más allá de los límites establecidos de un búfer o escriben fuera de ellos, lo que hace vulnerables a los proyectos de código abierto en C++. En las aplicaciones cuya memoria no se administra correctamente, los atacantes pueden aprovechar esta vulnerabilidad e insertar código ejecutable en el programa.

Por ejemplo, considera el error de Glibc encontrado en la biblioteca libresolv de GNU C Library. El error exponía Glibc a ataques de desbordamiento de búfer cuando se usaba la función de biblioteca getaddrinfo.

Un atacante puede aprovechar esta vulnerabilidad al engañar a un cliente para que busque un dominio malicioso. Luego, puede devolver una carga útil que active el error. Si el cliente tiene privilegios de root, esto puede comprometer el sistema y dar lugar a un ataque de intermediario. Glibc se usa en millones de sistemas que utilizan el kernel de Linux, por lo que cualquier sistema que ejecute la versión de Glibc con la vulnerabilidad puede verse afectado.

¿Qué es una cadena de suministro de software?

El término «cadena de suministro» se usa tradicionalmente en la industria manufacturera. Por ejemplo, un fabricante de automóviles podría usar algunas piezas fabricadas internamente y comprar otras a diferentes empresas. Esto significa que, antes de que un automóvil llegue a su dueño, muchas personas que usan distintas herramientas habrán trabajado en él.

En el software, la cadena de suministro funciona de manera muy similar. La cadena de suministro de software se refiere a todo lo que forma parte de tu código o interactúa con él, desde el desarrollo hasta la implementación. Esto incluye el código y los archivos binarios, los desarrolladores que trabajaron en el proyecto y los repositorios donde se implementa. También abarca las herramientas de compilación, los scripts de empaquetado y la infraestructura de la aplicación. La seguridad de la cadena de suministro es fundamental.

Como la cadena de suministro de software consta de muchos elementos, puede volverse bastante compleja. A los hackers les gusta aprovechar esta complejidad.

Vulnerabilidades en la cadena de suministro de software

En un ataque a la cadena de suministro de software, los actores maliciosos usan los componentes ascendentes conectados con el objetivo del ataque para obtener acceso. También pueden atacar los servicios que distribuyen o ejecutan el software. En este caso, esos componentes ascendentes no son necesariamente el objetivo del ataque: solo son un medio para obtener acceso.

Los tres objetivos principales de un ataque a la cadena de suministro son las dependencias, los pipelines y las dependencias de los pipelines.

Dependencias

Los atacantes se dirigen a las dependencias de código abierto que los desarrolladores incorporan al crear aplicaciones. Si un atacante inserta malware en un paquete de código abierto común al aprovechar una vulnerabilidad conocida, las aplicaciones de software que lo instalen como dependencia quedan expuestas. Como las aplicaciones de software pueden tener más de una dependencia que contiene otras dependencias, es difícil rastrear las posibles vulnerabilidades. Esto convierte a las dependencias en un blanco fácil.

Pipelines

En un ataque al pipeline, los usuarios maliciosos se dirigen al pipeline de integración y entrega continuas (CI/CD), ya que ofrece una gran superficie de ataque. Puede dar acceso a configuraciones predeterminadas, credenciales de seguridad, bases de datos y código propietario. Por lo tanto, cuando los atacantes insertan código malicioso en un pipeline de CI/CD y lo comprometen, pueden crear una puerta trasera en las aplicaciones que lo usan.

Dependencias de los pipelines

Los atacantes también pueden dirigirse a las dependencias de los pipelines para obtener acceso a un entorno de compilación. Por ejemplo, los actores maliciosos detrás de la brecha de Codecov usaron las credenciales de una imagen de Docker para actualizar un cargador de scripts de Bash. Modificaron el script para enviarse las variables de entorno de los usuarios de Codecov.

Identificar vulnerabilidades en dependencias de código abierto

Aunque el código de código abierto puede presentar sus propios problemas, sigue permitiendo a los desarrolladores lograr cosas increíbles y aprovechar el trabajo de otras personas. Sin embargo, los desarrolladores deben poder identificar vulnerabilidades y evaluar la calidad del código de código abierto que se usa en sus proyectos. Aun así, para la mayoría de las organizaciones no es viable dedicar los recursos necesarios a realizar revisiones manuales del código y auditar el código de código abierto antes de usarlo.

Sería difícil detectar vulnerabilidades como desbordamientos de búfer, punteros nulos, desbordamientos y subdesbordamientos de enteros, entre otras, en cada dependencia de C/C++ de la cadena de suministro. Por ejemplo, los hackers pueden atacar una vulnerabilidad de puntero nulo en un fragmento de código abierto C/C++ que se usa en nuestra cadena de suministro de software y provocar un fallo. No importa que el código de la aplicación no tenga vulnerabilidades: las vulnerabilidades en el código de código abierto la vuelven insegura.

Los dos métodos principales para identificar vulnerabilidades en dependencias de código abierto son crear una cadena de suministro de software segura en la que cada paso esté a cargo de un colaborador de confianza y usar escáneres automatizados de vulnerabilidades, como Snyk para C/C++.

Crear una cadena de suministro de software segura

Llevar un registro de cada colaborador de la cadena de suministro y asegurarse de que sea de confianza es una buena solución en teoría, pero es extremadamente difícil de implementar. La cadena de suministro de software incluye muchos desarrolladores responsables de varias bibliotecas y componentes que se usan en una aplicación.

Escáneres automatizados de vulnerabilidades, como Snyk para C/C++

Una solución más práctica es analizar el código de código abierto para detectar vulnerabilidades de seguridad. Sin embargo, realizar análisis manuales puede llevar mucho tiempo y dar lugar a errores. La mejor práctica es analizar el código C++ de código abierto con un escáner automatizado de vulnerabilidades, como Snyk.

Con Snyk Open Source, los desarrolladores pueden ver el código C++ de código abierto que usan. La CLI de Snyk convierte los archivos en firmas digitales —o hashes— que luego se comparan con las bases de datos de Snyk para crear una lista de componentes de código abierto coincidentes. Los desarrolladores pueden encontrar vulnerabilidades al comparar esta lista con la Snyk Vulnerability Database.

A diferencia de otros escáneres de vulnerabilidades que analizan archivos individuales, Snyk considera el contexto de los archivos. Al usar archivos auxiliares, como archivos readme y scripts de instalación, Snyk reduce la cantidad de informes de vulnerabilidades que arrojan falsos positivos. Esto reduce el ruido y ayuda a los desarrolladores a enfocarse en dónde se necesitan correcciones.

Cuando se identifica una vulnerabilidad, Snyk notifica a los desarrolladores en el IDE o la CLI e identifica automáticamente la actualización mínima necesaria para corregirla sin afectar otro código.

Conclusión

La popularidad del software de código abierto está creciendo. Como resultado, cada vez más aplicaciones contienen más bibliotecas y componentes de terceros escritos y mantenidos por personas desconocidas. Como estas bibliotecas se encuentran en repositorios públicos, los atacantes pueden aprovechar las menos seguras para obtener acceso.

Para evitar vulnerabilidades al trabajar con código de código abierto en proyectos C++, usa un escáner automatizado de vulnerabilidades como Snyk Open Source. Te permite analizar los proyectos C++ de código abierto de tu aplicación para detectar vulnerabilidades, identificar bibliotecas maliciosas y proteger tu software para que no se vea comprometido.

Consulta la documentación de Snyk para C/C++ para aprender a analizar tus proyectos C/C++.