Déniché par les chercheurs de Cisco Talos, le groupe RA commence à faire parler de lui. Son ransomware repose sur le malware Babuk dont le code source a été publié, avec un art du chiffrement plus raffiné.
La famille des groupes de ransomware s’élargit avec la découverte du gang RA par les équipes de sécurité de Cisco Talos. Depuis la fin du mois d’avril, il cible les entreprises et se livre également au vol de données et à l’extorsion. « Comme d’autres acteurs du ransomware, RA Group a aussi ouvert un site sur lequel il menace de publier les données exfiltrées des victimes qui ne les contactent pas dans un délai déterminé ou qui ne répondent pas à leurs demandes de rançon », indiquent les chercheurs dans leur rapport.
Un vecteur d’intrusion encore inconnu
« Cette forme de double extorsion augmente les chances de faire payer la rançon demandée par la victime », ajoutent-ils. L’équipe Talos n’a analysé que l’échantillon du ransomware, qui est la charge utile finale, mais elle ne sait pas comment les attaquants parviennent à s’introduire en premier lieu dans les réseaux. Cependant, il est probable que pour gagner cet accès initial, RA Group s’appuie, comme la plupart des gangs de ransomware, sur les vecteurs habituels : exploitation de vulnérabilités dans des systèmes exposés au public, vol d’identifiants d’accès à distance ou achat d’un accès auprès d’un autre gang de cybercriminels qui exploite une plateforme de distribution de logiciels malveillants.
L’accès initial est probablement suivi d’un mouvement latéral et du déploiement d’autres malwares, car les attaquants souhaitent d’abord exfiltrer des données potentiellement sensibles et précieuses pour l’entreprise. En fait, la dernière demande de rançon déposée par le groupe est adaptée à chaque victime, se réfère à elle par son nom et énumère le type exact de données qui ont été copiées et qui seront divulguées publiquement si aucun contact n’est établi dans les trois jours. Cela suggère que les attaquants connaissent très bien leurs victimes. À la fin du mois d’avril, le site de fuite de données du groupe, lancé le 22 avril, répertoriait déjà quatre victimes avec leurs noms, des liens vers leurs sites web et un résumé des données disponibles également mises en vente pour d’autres. Les données elles-mêmes sont hébergées sur un serveur Tor et les victimes doivent contacter le groupe en utilisant l’application de messagerie cryptée qTox. « Nous avons également constaté que l’acteur apportait des modifications esthétiques à son site de fuite après avoir divulgué les informations sur la victime, ce qui confirme qu’il en est aux premiers stades de son opération », ont déclaré les spécialistes.
Une variante de Babuk au chiffrement renforcé
En plus d’adapter les demandes de rançon à chaque victime, le fichier exécutable du ransomware inclut aussi le nom de la victime, ce qui suggère que les attaquants compilent des variantes uniques pour chaque cible. Le binaire du ransomware analysé par Talos a été compilé le 23 avril, a été écrit en C++ et contient un chemin de débogage qui correspond aux chemins trouvés dans Babuk, un ransomware dont le code source a été mis en ligne en septembre 2021 par un membre du groupe Babuk, en désaccord avec le groupe. Depuis, plusieurs ransomwares ont été développées sur la base du code divulgué de Babuk, notamment Rook, Night Sky, Pandora, Cheerscrypt, AstraLocker, EXSiArgs, Rorschach, RTM Locker, et maintenant RA Group. Contrairement à Babuk qui utilisait l’AES-256-CTR avec le chiffrement ChaCha8 pour le cryptage des fichiers, RA Group a opté pour une approche différente : il utilise la fonction WinAPI CryptGenRandom pour générer des octets cryptographiquement aléatoires, utilisés ensuite comme clé privée pour chaque victime, puis dans un schéma de chiffrement basé sur la courbe elliptique Curve25519 à 128 bits de sécurité et le chiffrement eSTREAM hc-128. Les fichiers ne sont que partiellement chiffrés pour accélérer le processus et sont renommés avec l’extension .GAGUP.
Le ransomware dispose d’une liste de dossiers et de fichiers (les principaux fichiers critiques du système) qu’il ne chiffreur pas pour éviter de planter le système, mais il vérifie le réseau à la recherche de partages de fichiers accessibles en écriture et tente de crypter les fichiers qui y sont stockés. D’autres opérations consistent à vider la corbeille du système et à utiliser l’outil vssadmin.exe pour supprimer les volumes Shadow Copy qui pourraient servir à récupérer des fichiers. « L’acteur étend rapidement ses opérations », indiquent les chercheurs de Talos dans leur rapport. « À ce jour, le groupe a compromis trois entreprises aux États-Unis et une en Corée du Sud dans plusieurs secteurs d’activité, notamment l’industrie manufacturière, la gestion de patrimoine, les compagnies d’assurance et l’industrie pharmaceutique », ont précisé les chercheurs.
Une faille critique dans le service de mise en file d’attente des messages MSMQ de Microsoft est susceptible d’être exploitée. En effet, de nombreuses entreprises ignorent que ce service est actif. La firme de Redmond les encourage à appliquer le correctif disponible dans le dernier Patch Tuesday.
Si le dernier Patch Tuesday s’est focalisé sur la correction d’un faille zero-day exploitée par des gangs de ransomware, une autre vulnérabilité mérite une attention particulière. Baptisée QueueJumper, la CVE-2023-21554, qui a été découverte par des chercheurs de Check Point Software, est évaluée à 9,8 sur 10 sur l’échelle de gravité CVSS. L’avis de Microsoft indique que la complexité de l’attaque est faible et que l’évaluation de l’exploitabilité est plus probable. Son impact est l’exécution de code à distance.
Exécution de code à distance dans l’ancien service Message Queuing
La brèche se trouve dans un composant de Windows appelé service Microsoft Message Queuing (MSMQ), qui permet aux applications de communiquer et d’assurer la livraison des messages même quand les réseaux et les systèmes sont temporairement hors ligne, en conservant les messages dans une file d’attente. Au fil du temps, ce service, présent dans Windows depuis Windows NT, a connu plusieurs versions. Quand il est actif, le service accepte les communications sur le port 1801 TCP. Même si MSMQ est généralement considéré comme un service ancien qui a été remplacé par des technologies de communication plus récentes, il existe toujours en tant que composant optionnel dans Windows 11 et dans la dernière version de Windows Server. De plus, les applications conçues pour l’utiliser l’activeront au moment de l’installation, à l’insu des utilisateurs ou des administrateurs. La documentation de Microsoft donne des exemples de cas d’usage de MSMQ par les services financiers critiques pour le commerce électronique, par les applications embarquées et mobiles comme celles utilisées dans les systèmes d’acheminement des bagages dans les aéroports, et par les applications d’automatisation des ventes pour les représentants commerciaux itinérants. Mais, cette documentation ayant été rédigée en 2016, il y a peu de chance que la liste d’applications soit à jour et exhaustive.
En fait, selon Haifei Li, chercheur chez Check Point, l’application Microsoft Exchange Server, largement utilisée par les entreprises, active le service MSMQ au cours du processus d’installation avec des paramètres par défaut. Ces dernières années, les serveurs Exchange sur site ont été la cible privilégiée des attaquants, en particulier des groupes de cyber-espions. « Nous savons maintenant que le vecteur d’attaque envoie des paquets au port de service 1801/tcp », a déclaré l’expert. « Afin de mieux comprendre l’impact potentiel de ce service dans le monde réel, Check Point Research a effectué un balayage complet de l’Internet. De manière surprenante, nous avons découvert que plus de 360 000 adresses IP avaient une adresse 1801/tcp ouverte sur lnternet et exécutaient le service MSMQ », a-t-il ajouté. Ce dernier précise aussi que ce chiffre n’inclut que le nombre d’hôtes en frontal de l’Internet et ne tient pas compte des ordinateurs hébergeant le service MSMQ sur des réseaux internes, où le nombre devrait être beaucoup plus élevé. Check Point recommande aux administrateurs de déterminer si le service Message Queuing fonctionne sur leurs systèmes et s’ils peuvent le désactiver sans affecter les applications critiques. Si le service est nécessaire et que le correctif de Microsoft ne peut pas être appliqué immédiatement, les entreprises devraient bloquer l’accès au port TCP 1801 à partir d’adresses IP non fiables à l’aide d’un pare-feu. Haifei Li pense néanmoins que cela ne protégera pas le système contre les attaques en cas d’intrusion dans le réseau local et d’un mouvement latéral qui permet aux attaquants de compromettre l’un des systèmes de confiance figurant sur la liste blanche des adresses IP du pare-feu. Le déplacement latéral est une technique courante employée par la plupart des gangs APT et de ransomware.
D’autres vulnérabilités critiques de Windows à surveiller
Une autre vulnérabilité d’exécution de code à distance avec un score de gravité de 9,8, similaire à celle de MSMQ, a été corrigée dans le composant Pragmatic General Multicast (PGM) de Windows. Cette faille est répertoriée sous la référence CVE-2023-28250 et dépend également de l’activation de MSMQ et de l’acceptation par le système de connexions sur le port TCP 1801. Cependant, Microsoft considère que l’exploitation de cette faille, répertoriée sous la référence CVE-2023-28252, est moins probable. La vulnérabilité zero-day corrigée par Microsoft, qui aurait déjà été utilisée par un gang de ransomware appelé Nokoyawa, se trouve dans le pilote Windows Common Log File System (CLFS).
Affectée d’un score de gravité de 7,8, cette vulnérabilité d’escalade de privilèges ne peut pas être exploitée à distance, mais pourrait être exploitée localement sur le système pour obtenir l’exécution de code en tant que SYSTEM. Microsoft a corrigé deux vulnérabilités CLFS similaires en février 2023 et en septembre 2022. « En avril 2023, 45 vulnérabilités distinctes d’exécution de code à distance (Remote Code Execution, RCE) ont été corrigées, ce qui représente une augmentation significative par rapport à la moyenne de 33 par mois au cours des trois derniers mois », a expliqué par courriel Adam Barnett, ingénieur logiciel en chef de l’entreprise de sécurité Rapid7. Ce mois-ci, dept des vulnérabilités RCE ont été qualifiées de critiques par Microsoft, y compris deux vulnérabilités connexes avec un score CVSSv3 de 9,8.
L’IA a aussi ses problèmes de sécurité avec la découverte d’une vulnérabilité critique dans MLflow, un framework open source très utilisé pour les tests de machine learning. Un correctif est disponible et à installer rapidement.
Alerte sur la sécurité des modèles de machine learning avec la découverte d’une faille sévère dans le framework open source MLflow. Les attaquants pourraient s’en servir pour extraire des informations sensibles des serveurs, comme des clés SSH et des identifiants AWS. Les campagnes peuvent être exécutées à distance sans authentification, car MLflow n’implémente pas d’authentification par défaut et un nombre croissant de déploiements de MLflow sont directement exposés à lnternet.
« En clair, chaque entreprise qui utilise cet outil risque de perdre ses modèles d’IA, d’avoir un serveur interne compromis et d’avoir son compte AWS compromis », a déclaré Dan McInerney, ingénieur senior en sécurité senior pour la startup de cybersécurité Protect AI. « C’est assez brutal ». Il a découvert la vulnérabilité et l’a signalée au projet MLflow en privé. Elle a été corrigée dans la version 2.2.1 du framework publiée il y a trois semaines, mais les notes de version ne mentionnent aucun correctif de sécurité.
Un framework très utilisé
Écrit en Python, MLflow automatise les workflows d’apprentissage machine. Du fait de ses nombreux composants, les utilisateurs peuvent déployer des modèles à partir de diverses bibliothèques de machine learning, gérer leur cycle de vie, y compris la version du modèle, les transitions d’étape et les annotations, suivre les expériences pour enregistrer et comparer les paramètres et les résultats, et même empaqueter le code d’apprentissage machine sous une forme reproductible pour le partager avec d’autres scientifiques des données. MLflow peut être contrôlé via une API REST et une interface en ligne de commande. Toutes ces capacités font de ce framework un outil précieux pour toute entreprise qui expérimente le machine learning.
Les analyses effectuées à l’aide du moteur de recherche Shodan confirment ce constat : au cours des deux dernières années, les instances MLflow exposées publiquement n’ont cessé d’augmenter, le nombre actuel s’élevant à plus de 800. Cependant, on peut supposer que de nombreux autres déploiements de MLflow existent au sein de réseaux internes et pourraient être atteints par des attaquants qui gagneraient un accès à ces réseaux. « Plusieurs entreprises du Fortune 500 que nous avons contactées nous ont toutes confirmé qu’elles utilisaient MLflow en interne pour leur flux de travail d’ingénierie de l’IA », a encore déclaré Dan McInerney.
Une faille classée 10 en CVSS
Répertoriée sous la référence CVE-2023-1177, la vulnérabilité découverte par Dan McInerney est classée 10 (critique) sur l’échelle CVSS. Le référentiel la décrit comme une inclusion de fichier en local et distante (LFI/RFI) via l’API, où un attaquant distant et non authentifié peut envoyer des requêtes spécifiquement conçues au endpoint de l’API qui forcerait MLflow à exposer le contenu de n’importe quel fichier lisible sur le serveur. Par exemple, l’attaquant peut inclure JSON dans une requête où le paramètre source est un fichier de son choix sur le serveur et l’application le renverra. L’un de ces fichiers peut être les clés ssh, généralement stockées dans le répertoire .ssh à l’intérieur du répertoire personnel de l’utilisateur local. Cependant, la connaissance préalable du répertoire personnel de l’utilisateur n’est pas une condition à l’exploitation, car l’attaquant peut d’abord lire le fichier /etc/passwd, disponible sur tous les systèmes Linux, qui recense tous les utilisateurs disponibles et leurs répertoires personnels. Aucun des autres paramètres envoyés dans le cadre de la requête malveillante n’a besoin d’exister et peut être arbitraire.
La vulnérabilité est d’autant plus grave que la plupart des entreprises configurent leurs instances MLflow pour qu’elles utilisent AWS S3 afin de stocker leurs modèles et autres données sensibles. Selon l’analyse de la configuration des instances MLflow accessibles au public effectuée par Protect AI, sept configurations sur dix utilisaient S3. Cela signifie que les attaquants peuvent définir le paramètre source de leur requête JSON comme étant l’URL s3:// du bucket utilisé par l’instance pour voler des modèles à distance. Cela signifie également que les identifiants AWS sont probablement stockés localement sur le serveur MLflow afin que le framework puisse accéder aux buckets S3, et ces identifiants sont généralement stockés dans un dossier appelé ~/.aws/credentials dans le répertoire personnel de l’utilisateur. L’exposition des informations d’identification AWS peut constituer une violation grave, car, en fonction de la politique IAM, elle peut donner aux attaquants des capacités de mouvement latéral dans l’infrastructure AWS d’une entreprise.
Des déploiements non sécurisés, faute d’authentification par défaut
Exiger une authentification pour accéder au endpoint de l’API empêcherait l’exploitation de cette faille, mais MLflow n’implémente aucun mécanisme d’authentification. Il est possible d’en ajouter une avec un nom d’utilisateur et un mot de passe statiques en déployant un serveur proxy comme nginx devant le serveur MLflow et en forçant ainsi l’authentification. Malheureusement, presque aucune des instances exposées publiquement n’utilise une telle configuration.
« Il est difficile de dire que ce mode de déploiement de l’outil est sûr, mais à tout le moins, le déploiement le plus sûr de MLflow tel qu’il est actuellement est de le garder sur un réseau interne, dans un segment de réseau séparé de tous les utilisateurs, sauf ceux qui ont besoin de l’utiliser, et de le placer derrière un proxy nginx avec une authentification de base », a expliqué Dan McInerney. « Cela n’empêche pas un utilisateur ayant accès au serveur de télécharger les modèles et artefacts d’autres utilisateurs, mais cela limite au moins l’exposition. L’exposition sur un serveur public orienté vers lnternet suppose qu’absolument rien de ce qui est stocké sur le serveur ou sur le système de stockage d’artefacts à distance ne contient de données sensibles », a-t-il ajouté.
Atlassian a publié des versions corrigées de Jira Service Management Server et Data Center. L’éditeur a publié une méthode de contournement de la faille critique qui expose les tokens d’accès des utilisateurs.
En fin de semaine dernière, Atlassian sonnait l’alerte suite à la découverte d’une vulnérabilité grave dans la déclinaison serveur et datacenter de sa plateforme de gestion des incidents, Jira. Cette faille touche les versions 5.3.0 à 5.3.1 et 5.4.0 à 5.5.0 de Jira Service Management Server et Data Center. L’éditeur a publié rapidement des versions corrigées du logiciel, mais il a aussi fourni une solution de contournement qui consiste à mettre à jour un seul fichier JAR dans les déploiements impactés. Les instances Atlassian Cloud ne sont pas concernées.
Un problème de rupture d’authentification
Selon la description de la vulnérabilité par Atlassian, il s’agit d’un problème d’authentification rompue. Le fournisseur qualifie la CVE-2023-2250 de critique dans sa propre échelle de gravité. « Avec un accès en écriture à un répertoire d’utilisateurs et un courrier électronique sortant activé sur une instance de gestion des services Jira, un attaquant pourrait avoir accès aux jetons de signature envoyés aux utilisateurs avec des comptes qui n’ont jamais été connectés », a expliqué l’entreprise dans son bulletin. « Il y a deux possibilités pour accéder à ces jetons : Si l’attaquant est inclus dans des problèmes ou des demandes Jira avec ces utilisateurs, ou si l’attaquant est transféré ou obtient autrement l’accès à des courriels contenant un lien ‘View Request’ (Afficher la demande) de ces utilisateurs », a encore expliqué l’éditeur. « Les comptes bot créés pour travailler avec Jira Service Management sont particulièrement sensibles à ce scénario », prévient l’entreprise. Même si la faille n’a pas d’impact sur les utilisateurs synchronisés via les répertoires d’utilisateurs (User Directories) en lecture seule ou le Single Sign-On (SSO), les personnes qui interagissent avec l’instance par courriel sont toujours affectées, même si l’authentification unique est activée.
Jira Service Management peut être utilisé pour mettre en place et gérer un centre de services qui unifie les services d’assistance de différents départements, comme l’IT, les RH, les finances ou le service clientèle, ce qui permet aux équipes de mieux travailler ensemble sur des tâches communes. La plateforme est également utilisée par les entreprises pour gérer les actifs, effectuer des inventaires, suivre la propriété et le cycle de vie, et peut servir aux équipes IT pour gérer la configuration de l’infrastructure, suivre les dépendances des services, et créer des bases de connaissances pour le libre-service. Compte tenu des nombreuses fonctionnalités prises en charge par la plateforme et des tâches qu’elle peut accomplir dans un environnement d’entreprise, la probabilité qu’un grand nombre d’employés, de sous-traitants et de clients aient des comptes sur cette plateforme est élevée, tout comme la possibilité d’abus.
Atténuation de la vulnérabilité de Jira Service Management
Atlassian insiste sur le fait que les entreprises qui n’exposent pas Jira Service Management publiquement doivent tout de même effectuer une mise à jour vers une version corrigée dès que possible. Si elles ne peuvent pas mettre à jour l’ensemble du système, elles doivent télécharger le JAR corrigé de servicedesk-variable-substitution-plugin pour leur version particulière, arrêter Jira, copier le fichier dans le répertoire /plugins/installed-plugins et relancer Jira. Une fois que le JAR corrigé ou la version corrigée a été installé, les entreprises peuvent rechercher dans la base de données les utilisateurs dont la propriété com.jsm.usertokendeletetask.completed est définie sur « TRUE » depuis que la version vulnérable a été installée. Il s’agit d’utilisateurs qui auraient pu être touchés, l’étape suivante consiste donc à vérifier qu’ils ont les bonnes adresses électroniques. Les utilisateurs internes doivent avoir le bon domaine de messagerie et les utilisateurs inscrits publiquement doivent avoir un nom d’utilisateur identique à leur adresse de messagerie.
Il faut ensuite imposer une réinitialisation du mot de passe à tous les utilisateurs potentiellement concernés, ce qui implique l’envoi d’un courriel de confirmation. Il est donc impératif que leurs adresses électroniques soient correctes. L’API Jira peut être utilisée pour forcer la réinitialisation du mot de passe, y compris l’expiration de toute session active et la déconnexion de tout attaquant potentiel. « S’il est établi que l’instance Jira Service Management Server/DC a été compromise, nous conseillons d’arrêter immédiatement le serveur et de le déconnecter du réseau/de l’Internet », a indiqué l’entreprise dans une FAQ accompagnant l’avis. « Il est également possible de quitter immédiatement tous les autres systèmes qui partagent potentiellement une base d’utilisateurs ou qui ont des combinaisons de nom d’utilisateur/mot de passe communes avec le système compromis. Avant de faire quoi que ce soit d’autre, il est important de travailler avec l’équipe de sécurité locale pour identifier la portée de la violation et les options de récupération », a encore recommandé Atlassian.