Una cantidad casi inconcebible de aplicaciones de Apple han estado expuestas durante años a vulnerabilidades críticas en un popular administrador de dependencias.
CocoaPods es una plataforma que los desarrolladores de El ecosistema de Apple Úselo para agregar y administrar bibliotecas externas (llamadas “pods”). Contiene más de 100.000 bibliotecas utilizadas por más de tres millones de aplicaciones, incluidas las más populares del mundo. Una búsqueda rápida en su sitio web revela paquetes relacionados con Instagram, X, Slack, AirBnB, Tinder y Uber, por nombrar algunos. Esto hace que los pods sean objetivos principales para los piratas informáticos y la plataforma CocoaPods – si contiene una vulnerabilidad subyacente en toda la plataforma – un pozo de dinero real.
De hecho, como reveló EVA Information Security en un informe el lunes, resulta que la plataforma CocoaPods efectivamente contenía un trío de vulnerabilidades graves. Al más grave de ellos, CVE-2024-38366, una oportunidad de ejecución remota de código (RCE), se le asignó una calificación crítica CVSS de 10 sobre 10. Otro error notable causado por pods sin propietario, CVE-2024-38368, recibió una Se asignó una calificación crítica de 9,3 y una calificación de 8,2 al problema de secuestro de verificación de sesión CVE-2024-38367.
“El impacto de esto es enorme”, afirma Alon Boxiner, director ejecutivo y cofundador de EVA. “No se puede describir con palabras. Ni siquiera sabemos sumar los números. [of affected apps] debido al amplio uso de CocoaPods.
CocoaPods administró mal las API durante una década
CocoaPods se desarrolló y lanzó por primera vez en 2011. Sus problemas actuales se remontan a 2014, cuando reemplazó un sistema de autenticación basado en GitHub por uno nuevo.Trompa“, que luego sirvió como repositorio centralizado y centro de distribución de la plataforma.
Aunque Trunk prometió beneficios en seguridad, escalabilidad y calidad de vida de los desarrolladores, el proceso de migración resultó complicado. Por ejemplo, se restableció la propiedad de todas las cápsulas, lo cual es impactante.
“Como parte de la integración, se expusieron algunas API, incluida una página web de front-end, para permitir a los propietarios de negocios autenticados a través de su cuenta de GitHub reclamar sus propios pods”, recuerda Reef Spektor, vicepresidente de búsqueda de EVA. En otras palabras, los usuarios recuperaban sus pods simplemente llamando a dibs.
Muchos autores no recogieron sus cápsulas en absoluto. Miles de dependencias han quedado “huérfanas”. Con el tiempo, otras obras fueron abandonadas cuando los autores renunciaron a su propiedad. Miles de vainas siguen sin dueño hoy.
¿El problema? El punto final de la API pública para reclamar pods todavía estaba disponible nueve años después.
Cualquiera en posesión de este conocimiento podría, en cualquier momento entre 2014 y 2023, tomar el control del módulo de otra persona, modificarlo como quisiera y aplicar esa modificación a todas las aplicaciones de Apple que lo utilizan.
¿Qué aplicación razonable dependería de una cápsula abandonada? Resulta que muchos hacen esto, a veces sin darse cuenta, simplemente porque es una dependencia de otro pod. EVA encontró evidencia de pods huérfanos en la documentación de aplicaciones como Facebook, Safari, Microsoft Teams, TikTok, Snapchat y muchas otras.
Sorprendentemente, este ni siquiera fue el error más grave que encontraron.
Error de RCE de gravedad máxima relacionado con RubyGem
Irónicamente, la peor vulnerabilidad de CocoaPods radica en un componente de código abierto incorporado en 2014 para validar las direcciones de correo electrónico de los usuarios.
Utilizando ciertos métodos vulnerables en el paquete rfc-22 de RubyGem, un atacante podría haber inyectado código malicioso arbitrario en el campo de dirección durante el proceso de validación de la cuenta de Trunk. El servidor habría ejecutado entonces, sin saberlo, su código arbitrario, dándole así carta blanca.
En este punto, Spektor explica: “Tengo acceso completo al servicio Trunk: cada propietario, cada módulo, no reclamado, reclamado, en realidad no importa. Puedo tomar posesión total de ellos si quiero, puedo modificarlos en tiempo de ejecución. Entonces, por ejemplo, alguien publica un pod y en el servidor puedo iniciar sesión en la especificación del pod y modificarla para agregar código malicioso. Y realmente no sería visible desde el exterior. »
El tipo de código malicioso que un atacante podría agregar silenciosamente a un pod sería ilimitado, y esta es solo una forma en que podrían aprovechar dicho acceso. Podría usar este acceso para cerrar Trunk por completo o robar tokens de sesión de los propietarios de pods o del propio CocoaPods.
Aguja en un pajar
No hay evidencia clara de que los atacantes explotaran alguno de los problemas descubiertos por los investigadores y arreglado por CocoaPods en octubre.
Cabe señalar, sin embargo, que la naturaleza fácilmente ocultable de los errores de la cadena de suministro de software, combinada con la gran cantidad de pods en riesgo durante tanto tiempo, proporcionaría una amplia cobertura para cualquiera que lo hiciera.
Encontrar un defecto de CocoaPods durante la última década puede parecer fácil, pero no ha sido el caso. Por lo tanto, EVA recomienda que todos los desarrolladores de aplicaciones que usaron Pods antes de octubre pasado (es decir, casi todas las aplicaciones de Apple) sigan seis pasos de remediación, como encontrar Pods huérfanos y revisarlos minuciosamente. todas las dependencias de código de terceros.
Dark Reading también se ha puesto en contacto con Apple para hacer comentarios.
“CocoaPods es un ejemplo perfecto de por qué debemos preocuparnos por el riesgo de la cadena de suministro”, dice Boxiner. “No se trata sólo de cómo desarrollas lo que desarrollas, sino también de las dependencias [which can be] puntos ciegos.”