Une belle prise de guerre. Le Centre de lutte contre les criminalités numériques de la Gendarmerie Nationale (C3N), basé à Pontoise (Val d'Oise) a annoncé avoir démantelé l'un des plus gros réseaux d'ordinateurs pirates au monde. Composé de 850 000 systèmes zombies répartis principalement en Amérique du Sud mais aussi aux Etats-Unis et en Russie, ce botnet était piloté via un serveur de commande et de contrôle (C&C) hébergé en France, capable d'infecter les machines à distance avec le virus Retadup. Objectif : permettre à des pirates d'utiliser les ressources systèmes à l'insu des utilisateurs pour miner des bitcoins (cryptominage) ou lancer des opérations de rançonnage.

« C'était très dangereux en matière de potentialité d'attaques : il fallait vraiment faire cesser l'infraction. Le virus Retadup est connu pour avoir attaqué des hôpitaux en Israël, volé des données de patients israéliens, et même fabriqué énormément de cryptomonnaie grâce aux 850 000 ordinateurs », a expliqué le colonel Jean-Dominique Nollet, nommé en août 2018 à la tête du C3N. Afin de mettre hors d'état de nuire le botnet, la section de lutte contre la cybercriminalité de la Gendarmerie s'est appuyé sur l'expertise technique de l'éditeur de sécurité Avast qui lui a fourni un serveur de C&C désinfecté. Les chercheurs de l'éditeur ont contacté le C3N fin mars pour partager ses informations après avoir identifié que l'infrastructure de C&C de Retadup se situait principalement en France. Le FBI a aussi été mis dans la boucle, une autre partie de l'infrastructure ayant été localisée aux Etats-Unis.

Un snapshot du disque du serveur C&C récupéré par le C3N

« En juillet 2019, la Gendarmerie a reçu le feu vert du procureur, ce qui signifie qu'elle pouvait légalement procéder à la désinfection. Ils ont remplacé le serveur C&C malveillant par un serveur de désinfection préparé permettant aux instances connectées de Retadup de s'autodétruire. Dans la toute première seconde de son activité, plusieurs milliers de robots s’y sont connectés afin de récupérer les commandes du serveur. Le serveur de désinfection leur a répondu et les a désinfecté, en abusant de la faille de conception du protocole C&C », a indiqué Jan Vojtěšek, analyste des logiciels malveillants d'Avast dans un billet fournissant des détails sur le fonctionnement de l'attaque.

« Pendant que la Gendarmerie présentait le scénario de désinfection au procureur, nous étions en train d'analyser Retadup plus en détail. Nous avons créé un programme de suivi simple qui nous avertissait chaque fois qu'il y avait une nouvelle variante de Retadup ou s'il commençait à distribuer de nouvelles charges utiles malveillantes à ses victimes. Nous avons ensuite testé le scénario de désinfection proposé localement et discuté des risques potentiels associés à son exécution. La gendarmerie a également obtenu un snapshot du disque du serveur C&C auprès de son fournisseur d’hébergement et en a partagé certaines  parties avec nous afin que nous puissions commencer à procéder à une ingénierie inverse du contenu du serveur C&C. Pour des raisons évidentes de confidentialité, nous n’avions accès qu’à des parties du serveur C&C ne contenant aucune information privée sur les victimes de Retadup. »

Des pirates ont commencé à exploiter des vulnérabilités récemment corrigées dans les pare-feu de Juniper Networks, qui peuvent être enchaînées pour exécuter du code à distance (Remote Code Execution, RCE). Les détails de l'exploit et d'un PoC associé ont été publiés fin de semaine dernière par une équipe de chercheurs en sécurité. « Cette chaîne de bogues intéressante exploite deux bogues presque inutiles de manière isolée, mais qui, une fois combinés, permettent une exécution de code à distance non authentifiée à très fort impact », ont déclaré les chercheurs de l’entreprise de sécurité WatchTowr dans leur analyse détaillée. « Ceux qui utilisent un appareil affecté sont invités à mettre à jour vers une version corrigée dès que possible, et/ou à désactiver l'accès à l'interface J-Web si c’est possible », ont recommandé les chercheurs.

Le 18 août, Juniper a corrigé quatre vulnérabilités identifiées dans ses pare-feu des séries SRX et EX. Les failles se trouvent dans le composant J-Web de Junos OS, le système d'exploitation des pare-feu Juniper, et elles ont toutes un score de 5,3 sur 10 sur l'échelle CVSS (Common Vulnerability Scoring System). Cela correspond à une criticité moyenne, c’est-à-dire que ces failles sont généralement traitées avec une priorité moindre dans les cycles de correction. Cependant, dans ce cas particulier, certaines des vulnérabilités peuvent être enchaînées pour permettre l'exécution de code à distance sans authentification, ce que Juniper met clairement en garde dans son avis.

Les CVE-2023-36846 et CVE-2023-36847 dans le viseur

Deux failles, référencées CVE-2023-36846 et CVE-2023-36847, sont similaires et donnent la capacité à un attaquant non authentifié d'envoyer des requêtes spécialement conçues à un appareil pour télécharger des fichiers arbitraires via J-Web vers le système de fichiers. Deux autres vulnérabilités, référencées CVE-2023-36844 et CVE-2023-36845, également similaires, permettent à un attaquant non authentifié de modifier certaines variables d'environnement PHP. Suite à l'avis de Juniper, les chercheurs de watchTowr ont été intrigués par la possibilité d'enchaîner ces failles et ont donc entrepris de les étudier. Il s'avère que seules deux failles sont nécessaires pour réaliser l'attaque, un téléchargement de fichier et une modification de variable d'environnement. Dans un premier temps, ils ont trouvé la vulnérabilité CVE-2023-36846 en examinant les fonctions internes de l'interface J-Web, qui est une application PHP. Ils en ont repéré une appelée do_upload qui gère le téléchargement de fichiers et ont immédiatement remarqué qu'elle ne comportait pas de contrôle d'authentification. L'exploitation était donc simple, mais le fichier de téléchargement était placé dans un dossier tmp et il semblait que le serveur web lui-même s'exécutait en tant que « jailed process », un processus emprisonné dans un environnement virtuel.

Les chercheurs n’ont pas eu trop de mal non plus à localiser la seconde faille nécessaire à la modification des variables d'environnement PHP. Par contre, le passage à l'exécution de code arbitraire a été difficile grâce aux défenses de sécurité de Junos OS. Tout d'abord, les chercheurs ont essayé d'abuser de la variable LD_PRELOAD qui demande au processus PHP de charger une bibliothèque. Ils ont pointé cette variable vers l'emplacement du fichier qu'ils ont téléchargé en utilisant la première faille, mais la tentative d'exécution a échoué avec un message d'erreur d'authentification. Les chercheurs ont essayé de déboguer l'erreur pendant un long moment pour comprendre ce qui se passait et ont même essayé de charger des bibliothèques qui existaient déjà sur le système, sans succès. « Il s'avère que Juniper utilise (judicieusement) un outil appelé veriexec, qui limite l'exécution aux binaires ayant une signature valide et vérifie également leur emplacement sur le système de fichiers », ont expliqué les chercheurs. « Cela signifie que les tentatives de téléchargement et d'exécution d'une charge utile échoueront, car les charges utiles se trouvent à un emplacement qui ne figure pas sur la liste blanche (et aussi parce qu'elles ne sont pas signées cryptographiquement). C'est excellent pour la sécurité, mais mauvais pour nous ».

Un PoC d'exploit publié sur Github

Les chercheurs se sont ensuite demandé quels binaires à signature numérique pouvaient exister sur le système et s'ils pouvaient influencer leur exécution par le biais d'une variable d'environnement. La réponse, c’est qu’il s’agit du binaire PHP lui-même. PHP est un framework et un runtime, et lorsqu'il démarre, il a un fichier de configuration, généralement appelé php.ini, dont l'emplacement est défini dans une variable d'environnement appelée PHPRC. Les chercheurs ont donc pu télécharger un fichier de configuration php.ini spécialement conçu à l'aide de la vulnérabilité de téléchargement de fichiers, puis utiliser la seconde vulnérabilité pour modifier la variable PHPRC et y faire pointer le processus PHP. Ensuite, ils se sont demandés comment exécuter un code arbitraire à partir d'un fichier de configuration.

Il s'avère que php.ini possède une entrée appelée auto_prepend_file qui permet à l'utilisateur de pointer vers un fichier que le processus exécutera avant tout autre code PHP. La chaîne était désormais complète. Télécharger un fichier contenant un shellcode malveillant, puis télécharger un php.ini spécialement conçu avec une entrée auto_prepend_file pointant vers lui, puis modifier la variable PHPRC pour exécuter le php.ini et implicitement le shellcode malveillant. En plus de leur article détaillé, les chercheurs ont également publié sur GitHub une preuve de concept qui automatise l'ensemble de l'attaque. « Même si la qualité du code est très proche de celle d'autres dispositifs de sa catégorie, comme les dispositifs Fortiguard et Sonicwall que nous avons cassés, il convient de souligner ici que l'utilisation de veriexec par Juniper a été judicieuse, car elle complique l'exécution du code et des commandes », ont déclaré les chercheurs de watchTowr. Mais cela ne suffira pas à décourager des pirates déterminés. Au total, les chercheurs auront mis environ une demi-heure à contourner la limite d’exécution (et, je l'admets, beaucoup plus de temps à se rendre compte qu'elle était en vigueur).

Des attaques en cours 

Le jour même où watchTowr a publié son exploit PoC, la Shadowserver Foundation, une entreprise qui analyse l’Internet à la recherche de logiciels malveillants et surveille les attaques à l'aide d'honeypot, a signalé des tentatives d'exploitation de la vulnérabilité Juniper J-Web CVE-2023-36844 et les autres failles. L'organisation a indiqué qu'elle suivait actuellement plus de 8 200 adresses IP avec des interfaces J-Web exposées à Internet. Les chercheurs de watchTowr ont souligné que l'application de correctifs pourrait ne pas être simple, en particulier pour les systèmes Juniper virtualisés fonctionnant dans le cloud.

« Nous avons effectué cette recherche en utilisant un appareil SRX hébergé par Amazon Elastic Compute Cloud EC2, et nous avons été consternés de constater qu'il était apparemment impossible pour nous de mettre à jour l'appareil », ont-ils déclaré. « Les mises à jour ne sont disponibles que pour les utilisateurs enregistrés, et il semble que l'intégration EC2 qui effectue l'enregistrement soit défectueuse ». Les chercheurs conseillent aux utilisateurs qui ne peuvent pas appliquer les correctifs immédiatement de désactiver le composant J-Web ou d'en limiter l'accès à des utilisateurs de confiance. Leur rapport comprend également des indicateurs de compromission que les administrateurs peuvent rechercher dans les fichiers logs PHP de leurs terminaux.