Las dependencias de código abierto se han convertido en una fuente creciente de riesgo para organizaciones de todas las formas y tamaños. log4j, Utilidades xz y otras historias de alto perfil han resaltado debilidades sistemáticas en el ecosistema, que los actores de amenazas son cada vez más capaces de explotar. Pero pocos sospechaban que Apple alguna vez se vería afectada. Después de todo, este es el proveedor que examina minuciosamente cualquier aplicación permitida en su App Store. Bueno, eso fue hasta el 1 de julio, cuando Los investigadores de seguridad abandonaron Otra bomba de código abierto: nuevas vulnerabilidades críticas en un popular administrador de dependencias utilizado en más de tres millones de aplicaciones macOS e iOS.

Los errores se han solucionado, pero nadie sabe si ya se han aprovechado de ellos en ataques encubiertos a la cadena de suministro. Esto plantea una pregunta cada vez más frecuente: ¿cómo solucionamos un problema como el del código abierto?

¿Que pasó?

Las vulnerabilidades se encontraron en CocoaPods, un repositorio de proyectos Swift y Objective-C de código abierto del que dependen millones de aplicaciones de Apple. Cuenta con más de 100,000 bibliotecas externas (o "pods"), que utilizan algunas de las aplicaciones más populares del mundo, incluidas Airbnb, Instagram y Uber. Según EVA Information Security, las vulnerabilidades son las siguientes:

CVE-2024-38368: Una falla de diseño en el servidor CocoaPods permite a cualquier usuario reclamar un pod que no tiene un propietario identificado sin necesidad de verificación alguna. Hoy en día, existen miles de estos pods sin propietario. Según Endor Labs, esto significa que un actor de amenazas podría haber registrado una cuenta de CocoaPods, reclamado un pod y comenzado a distribuir malware como si fuera un mantenedor de confianza. Tiene una puntuación CVSS de 9.3.

CVE-2024-38367:El servidor CocoaPods confía en un encabezado de solicitud en el que no debería, lo que permite a un atacante subvertir el flujo de trabajo de validación de correo electrónico para evitar la apropiación de cuentas. Esto podría haber llevado a los actores de amenazas a secuestrar cuentas de usuario existentes y reemplazar los pods asociados con versiones maliciosas o comprometidas. Tiene una puntuación CVSS de 8.2.

CVE-2024-38366: Se origina a partir de una vulnerabilidad en una gema de Ruby denominada “rfc-822”, que es una biblioteca de código abierto de la que depende el software del servidor CocoaPods para validar direcciones de correo electrónico. Los actores de amenazas podrían haberla explotado para lograr la ejecución remota de código en el servidor Trunk. Tiene una puntuación CVSS de 10.0.

¿Qué pasa después?

La buena noticia es que los errores se solucionaron en octubre pasado, pero aún quedan dudas sobre si se han aprovechado de ellos durante la última década, dada la cantidad de pods expuestos y el tiempo durante el que estuvieron expuestos (más de 10 años). Si así fuera, la complejidad de la cadena de suministro de software habría proporcionado a los actores de la amenaza una amplia cobertura.

“Si bien no hay evidencia directa de que alguna de estas vulnerabilidades se esté explotando en la naturaleza, la evidencia de ausencia no es ausencia de evidencia”, advierte EVA.

Es por eso que el proveedor recomienda a los desarrolladores afectados (aquellos que usan CocoaPods antes de octubre de 2023) proteger su código mediante los siguientes pasos:

  • Mantenga los archivos “podfile.lock” sincronizados con todos los desarrolladores de CocoaPods para que todos tengan la misma versión de los paquetes. Esto significa que si se implementa una nueva actualización dañina, los desarrolladores no la actualizarán automáticamente.
  • Para los pods desarrollados internamente y alojados únicamente en CocoaPods para su distribución, los desarrolladores deben realizar una validación de CRC (suma de comprobación) contra el descargado del servidor troncal de CocoaPods para asegurarse de que sea el mismo que el desarrollado internamente.
  • Implementar una revisión de seguridad exhaustiva de cualquier código de terceros utilizado en las aplicaciones
  • Revise las dependencias de CocoaPods y verifique que no esté usando un pod huérfano.
  • Utilice únicamente dependencias de terceros que se mantengan activamente y cuya propiedad esté clara.
  • Realice análisis periódicos de códigos de seguridad para detectar secretos y códigos maliciosos en todas las bibliotecas externas, especialmente CocoaPods.

The Bigger Picture

Los desarrolladores siguen confiando en los componentes de código abierto porque son una forma rápida, rentable y sencilla de acortar los tiempos de desarrollo. Pero los riesgos son cada vez más grandes como para ignorarlos. Según el informe de ISMS.online Informe sobre el estado de la seguridad de la información 2024Tres cuartas partes (75 %) de las organizaciones se vieron afectadas por un incidente de seguridad causado por un proveedor externo. Y casi la mitad (45 %) sufrió múltiples incidentes durante el año pasado.

“El software de código abierto, al ser de acceso público, puede contener vulnerabilidades no descubiertas o sin parches que los actores maliciosos podrían explotar. Esto se ve agravado por la falta de soporte especializado en muchos proyectos de código abierto, lo que dificulta obtener asistencia o actualizaciones oportunas cuando surgen problemas”, afirma Rich Hildyard, director de productos y entrega de software en MOBSTR, especialista en seguridad móvil.

“Otro riesgo importante está relacionado con las licencias. El incumplimiento de las licencias de código abierto puede dar lugar a complicaciones legales, especialmente cuando las licencias tienen requisitos específicos que deben cumplirse”.

Hildyard también advierte sobre proyectos que pueden ser abandonados por sus mantenedores.

“Cuando esto sucede, los usuarios se quedan sin actualizaciones o correcciones esenciales, lo que puede poner en peligro la estabilidad y la seguridad de sus sistemas”, explica a ISMS.online. “Los problemas de compatibilidad también suponen una amenaza, ya que las actualizaciones en dependencias de código abierto a veces pueden introducir cambios o conflictos con otros componentes de software, lo que altera la funcionalidad general”.

Boris Cipot, ingeniero de seguridad sénior del Grupo de Integridad de Software de Synopsys, sostiene que la complejidad y el gran volumen de dependencias directas y transitivas hacen que sea un desafío para los CISO gestionar y rastrear vulnerabilidades que afectan a múltiples proyectos. Incluso si pueden, la aplicación de parches puede demorarse debido a problemas de compatibilidad y/o requisitos de prueba, le dice a ISMS.online.

Mitigación de riesgos de código abierto con la norma ISO 27001

Sin embargo, es posible mitigar el riesgo de que se produzca otro Log4Shell o CocoaPods. Sostiene que será de ayuda supervisar continuamente los componentes de código abierto, incluso mediante herramientas de análisis de composición de software (SCA), para identificar y gestionar automáticamente los componentes de código abierto y sus dependencias. Cipot también recomienda que los equipos de seguridad sigan la norma ISO 27001.

“La ISO/IEC 27001 es una norma internacional para sistemas de gestión de seguridad de la información (SGSI) que proporciona un enfoque sistemático para gestionar la información confidencial de la empresa y garantizar su seguridad”, explica. “Esta norma también puede ayudar a las organizaciones a mitigar los riesgos asociados con el uso de software de código abierto mediante la creación de un marco estructurado que aborde diversos riesgos, mejorando así la seguridad general de la información”.

Aporta un valor especial con:

  • Evaluación y tratamiento de riesgos: incluye la evaluación de los riesgos de utilizar software de código abierto, como vulnerabilidades, falta de soporte o problemas de licencia, y la implementación de medidas para mitigar estos riesgos.
  • Gestión de activos: mantener un inventario de activos de información, incluido el software de código abierto, ayuda a identificar y gestionar los aspectos de seguridad del software, garantizando que todos los componentes estén actualizados y seguros.
  • Control de acceso: Para garantizar que solo el personal autorizado pueda usar o modificar software de código abierto, evitando cambios no autorizados que podrían introducir vulnerabilidades.
  • Políticas y procedimientos de seguridad: pueden incluir pautas para el uso, monitoreo y actualización de software de código abierto.
  • Relaciones con proveedores: garantizar que los proveedores externos de software de código abierto cumplan con los estándares y prácticas de seguridad que se alinean con los de la propia organización.
  • Gestión de parches: para garantizar que cualquier vulnerabilidad de seguridad en el software de código abierto se identifique y solucione rápidamente.
  • Gestión de incidentes: un proceso definido para gestionar incidentes de seguridad, que incluye la detección y respuesta a vulnerabilidades o infracciones asociadas con software de código abierto, minimizando los daños y recuperándose rápidamente.
  • Cumplimiento de los requisitos legales: la norma ayuda a las organizaciones a cumplir con los requisitos legales, reglamentarios y contractuales, incluida la adhesión a las licencias de código abierto y la garantía de que el uso de software de código abierto no viole las leyes de propiedad intelectual.
  • Mejora continua: Promover una cultura de mejora continua, donde la eficacia de los controles de seguridad, incluidos los relacionados con el software de código abierto, se revise y mejore periódicamente.
  • Capacitación y concientización: para garantizar que los empleados comprendan los riesgos asociados con el software de código abierto y las medidas implementadas para mitigar esos riesgos.

Hoy en día, el código abierto está en todas partes, lo que hace que las mejoras de seguridad sean una responsabilidad compartida entre todos los usuarios, mantenedores, colaboradores y patrocinadores.

“Los CISO deberían fomentar las relaciones dentro de la comunidad y participar en esfuerzos colaborativos para mejorar las prácticas de seguridad en toda la cadena de suministro”, concluye Cipot. Mientras tanto, puede ser necesario un cambio de cultura en muchas organizaciones de usuarios finales. Los riesgos del código abierto no son los mismos que los que surgen del código propietario. Cuanto antes acepten y aprendan a gestionar este hecho los CISO, mejor.