CocoaPods est un service communautaire lancé en 2011. L’idée était de simplifier la gestion des dépendances en automatisant une multitude de processus. Le service s’est spécialisé dans la gestion des bibliothèques externes, régulièrement utilisées pour simplifier le développement. Ces bibliothèques proposent en effet des fonctions prêtes à l’emploi, évitant de réinventer la roue.

CocoaPods se présente ainsi comme un dépôt rassemblant de nombreuses bibliothèques open source (pour les projets en Swift et Objective-C). Quand des bibliothèques sont mises à jour, le service se charge de les synchroniser avec les projets existants. En outre, quand des développeurs apportent des modifications à leurs « pods » (des paquets de code individuels), les applications qui en dépendent sont, elles aussi, mises à jour automatiquement.

Les failles découvertes par EVA Information Security appartiennent toutes à la catégorie de la chaine d’approvisionnement. Elles sont toutes critiques, avec une sévérité allant de 8,2 à 10 sur 10. Exploitées via de l’injection de code, elles auraient pu permettre à des pirates de récupérer des informations précises sur les développeurs et jusqu’à la prise de contrôle de pods et de comptes.

Selon les chercheurs, aucun signe d’exploitation n’a été trouvé. Mais puisque ces vulnérabilités sont restées en place dix ans, il est difficile d’en être sûr. En outre, CocoaPods revendique trois millions d’applications ayant fait appel à ses bons offices.

« L'injection de code dans ces applications pourrait permettre aux attaquants d'accéder à ces informations à toutes les fins malveillantes imaginables – rançongiciels, fraude, chantage, espionnage d'entreprise... Ce faisant, elle pourrait exposer les entreprises à des responsabilités juridiques majeures et à des risques pour leur réputation », écrivent les chercheurs.

Des emails de vérification… insuffisamment vérifiés

Les problèmes se situent tous dans la manière dont CocoaPods envoie des courriers pour vérifier l’identité du développeur.

La première faille, CVE-2024-38367 (sévérité 8,2 sur 10), permettait la falsification de l’en-tête X-Forwarded-Host (XHF) dans l’email de confirmation. Exploitée, elle aurait permis la modification du lien, autorisant alors le pirate à renvoyer le développeur vers une page qu’il contrôlait. Plus précisément, la faille réside dans la classe sessions_controller présente dans le code source du serveur. Le mécanisme sessions_controller.rb donnait la priorité au XHF, ce qu’il n’aurait pas dû faire.

La seconde brèche, CVE-2024-38368 (sévérité de 9,3 sur 10), pouvait permettre aux pirates de prendre le contrôle de pods abandonnés par leurs développeurs, mais toujours utilisés par des projets. Une API (interface de programmation) avait été mise en place il y a dix ans pour permettre aux développeurs de récupérer le contrôle de leurs pods après une période d’inactivité. Cependant, toute personne trouvant un pod orphelin pouvait s’en approprier le contrôle. Plus grave encore, aucun contrôle d’identité n’était effectué.

Jusqu'au détournement de la chaine d'approvisionnement

Quant à la dernière vulnérabilité, CVE-2024-38366 (sévérité maximale, 10 sur 10), elle ouvrait le champ à des exécutions de code arbitraire sur le serveur. L’explication est cependant un peu plus technique. Pour vérifier l’unicité des adresses email utilisées par les développeurs, le serveur s’appuie sur la RFC822. Celle-ci, publiée en 1982 (ce qui ne nous rajeunit pas), décrit comment l’unicité des adresses doit être vérifiée, comme le respect du bon format. L’une des clés de cette opération est l’examen de l’enregistrement MX (Mail eXchanger) pour le domaine de l’adresse. Le processus se sert d’une expression régulière pour contrôler que l’adresse respecte le bon format.

Malheureusement, durant l’étape de concaténation de l’adresse avec le domaine, aucun contrôle des caractères malveillants n’est réalisé. Les chercheurs ont ainsi réussi à glisser un script bash dans un enregistrement MX. Ce script, une fois lancé, établissait une connexion avec le serveur, lui permettant d’obtenir un accès au shell du serveur.

Exploitées, ces trois failles permettaient un détournement de la chaine d’approvisionnement (supply chain). Les pirates auraient alors été en mesure de modifier en silence de nombreux éléments, y compris les pods eux-mêmes. L’introduction de code malveillant aurait ensuite été synchronisée avec les projets en ayant besoin.

Selon les modifications, il aurait ainsi été possible de contaminer des centaines de milliers d’applications. Celles-ci auraient pu être utilisées pour récupérer de nombreuses données, y compris sensibles.

Des failles non exploitées… peut-être

EVA Information a publié les résultats de son enquête il y a trois jours, mais les failles étaient corrigées depuis octobre. C’est le délai mis en place avec CocoaPods pour s’assurer que tout avait bien été modifié et contrôlé avant que l’information soit révélée.

La menace était réelle, confirmée d’ailleurs par CocoaPods. Aucune exploitation n’a été détectée, mais ni les chercheurs ni CocoaPods ne peuvent affirmer que rien ne s’est passé. L’échelle est en effet conséquente : ces failles existaient depuis dix ans et pouvaient affecter des millions d’applications. Les chercheurs concluent d’ailleurs que « l’absence de preuve n’est pas la preuve de l’absence ».

Quelques conseils quand même

Aucune action particulière n’est requise de la part des développeurs. Pas même une réinitialisation du mot de passe. Cependant, les chercheurs recommandent quelques vérifications, particulièrement pour les applications qui se servaient déjà de CocoaPods avant les corrections d’octobre.

Par exemple, ils conseillent de garder le fichier podfile.lock synchronisé entre tous les développeurs d’un pod, pour s’assurer que tous ont la même version des paquets. En cas de mise à jour contaminée, cela permettra à des développeurs de ne pas recevoir automatiquement le code frelaté.

Les développeurs sont également invités à vérifier la somme de contrôle CRC d’un pod téléchargé, pour s’assurer qu’elle est identique à celle du pod développé en interne (quand il y en a).

Les autres conseils sont plus généraux, comme la vérification plus poussée de tout code tiers utilisé dans les applications, l’examen des dépendances CocoaPods (notamment pour trouver des pods orphelins) et des dépendances tierces (sont-elles toujours maintenues ?), l’analyse périodique du code pour en évaluer la sécurité, ou encore un zest de méfiance à l’égard des dépendances très utilisées, car elles constituent des cibles de choix pour les pirates.