Xurum : Découverte d'une nouvelle campagne Magento

Le commerce digital est un secteur largement ciblé par les cybercriminels en général, mais la grande popularité de Magento en a malheureusement fait une cible particulièrement attrayante (et lucrative). L'attaque spécifique la plus notable est Magecart,  dans laquelle les attaquants visent à déployer des skimmers basés sur JavaScript afin d'acquérir de manière illicite des informations sensibles sur les utilisateurs. Ces acteurs de la menace Magecart profitent de vulnérabilités Web bien connues pour parvenir à leurs fins.

Au moins sept groupes malveillants ont ciblé des boutiques Magento depuis 2015, ce qui témoigne de l'importance de la plateforme et du succès que les acteurs malveillants ont obtenu grâce à ce code d'exploitation.

Au début de l'année 2022, la vulnérabilité CVE-2022-24086 a été révélée, permettant aux attaquants d'exploiter le moteur de modèles de Magento et d'exécuter un code PHP arbitraire sur des cibles sensibles. Cette attaque se déroule en plusieurs étapes, les vecteurs les plus courants étant l'exploitation du processus de paiement ou de la fonctionnalité « liste de souhaits ». Depuis sa divulgation, cette vulnérabilité est apparue comme un point d'entrée principal pour de nombreux acteurs utilisant Magecart pour cibler les boutiques vulnérables Magento 2.

Au cours des derniers mois, Akamai a surveillé de près une campagne ciblant spécifiquement un nombre relativement restreint de déploiements Magento. Nous avons baptisé cette campagne Xurum en référence au nom de domaine du serveur C2 utilisé par les attaquants.

Pendant la campagne en cours, nous avons observé des attaquants tentant d'exécuter deux charges utiles distinctes à partir de quatre adresses IP au total (Figure 1). Ces adresses IP sont associées à l'infrastructure de deux hébergeurs : Hetzner en Allemagne et Shock Hosting aux États-Unis.

Au cours de notre enquête sur le serveur xurum.com, il est apparu qu'il était physiquement situé aux Pays-Bas (Figure 4) et hébergé par l'hébergeur russe VDSina.ru (Figure 5).

Comme il existe plusieurs itérations de cette attaque, nous avons choisi de l'appeler xurum pour distinguer cette campagne des autres.

Les auteurs d'attaques utilisent souvent des conventions de dénomination distinctes pour leurs domaines ou leurs logiciels malveillants, qui, par inadvertance ou délibérément, constituent leur signature distinctive. Au cours de notre enquête sur la signification possible de "xurum," nous avons identifié deux interprétations potentielles.

Selon Google Translate, xurum se traduit par "juste" en latin, ce qui implique de "faire ce qui est juste" (Figure 7). D'autre part, le dictionnaire WordSense indique que xurum est le mot pour « garçon » dans une langue éteinte autrefois parlée au Guatemala (Figure 8).

Veuillez noter qu'au moment de la rédaction de cet article de blog, les attaquants ont mis hors service leur serveur xurum et sont passés à un autre serveur qui semble être encore en phase d'assurance qualité.

Le script PHP malveillant qui est téléchargé depuis le serveur xurum et exécuté sur la machine de la victime passe par plusieurs stades d'infection.

Tout d'abord, il collecte des informations techniques sur la victime, telles que :

• La version PHP

• Si l'attaque a atterri dans le répertoire « /pub » (structure de répertoire courante dans Magento)

• Si le fichier « /var/www/html/vendor/magento/google-shopping-ads/registration.php »  existe et est accessible en écriture 

• Le contenu du fichier « env.php », qui contient des informations cruciales pour l'application Magento, comme les paramètres spécifiques à l'environnement, mais aussi des secrets comme la clé de cryptage utilisée pour sécuriser les données sensibles telles que les mots de passe, les détails des cartes de crédit et les informations sur les clients

Ensuite, il décode un blob dissimulé vi un encodage en Base64 et l'écrit dans le fichier « /var/www/html/vendor/magento/google-shopping-ads/registration.php » (Figure 9).

Le nouveau fichier présente un contenu intrigant. Plutôt que de maintenir leur propre copie d'un shell Web et de l'héberger sur leur serveur C2, le code du nouveau fichier des attaquants pointe vers un dépôt GitHub public appartenant à un chercheur en sécurité nommé "Bad Advertiser" or "@0xbadad ». Ce référentiel contient un shell Web connu dénommé wso-ng. Ce qui rend ce cas particulièrement intéressant, c'est que le shell Web n'est pas écrit sur le disque du serveur. Au lieu de cela, il est récupéré et exécuté uniquement en mémoire lors de l'accès à la page "registration.php" nouvellement créée. Pour renforcer la protection contre les accès non autorisés, les attaquants exigent également la présence d'un cookie "magemojo000" spécifique dans la requête pour que le shell Web s'exécute correctement.

L'attaquant enregistre ensuite la nouvelle fonctionnalité du shell Web en tant que nouveau composant Magento masqué sous le nom « GoogleShoppingAds » (Figure 10).

Après avoir installé la porte dérobée, les attaquants récupèrent des informations sur les méthodes de paiement des commandes au cours des dix derniers jours et exfiltrent ces données vers leur zone de dépôt xurum.com, en même temps que les informations techniques collectées précédemment (Figure 11).

Dans la dernière étape, les attaquants créent un utilisateur administrateur de porte dérobée portant le nom de "mageworx" (ou "mageplaza" dans certaines variantes). Ces noms correspondent à des boutiques d'extension Magento 2 populaires, Mageworx et Mageplaza (Figure 12). Ce choix de noms semble être une tentative de camoufler leurs actions en processus légitimes liés à ces fournisseurs d'extensions réputés.

Notez une nuance intéressante dans les adresses e-mail des utilisateurs de la porte dérobée. Il y a un double « z » dans « mageplazza » dans l'adresse e-mail developer@mageplazza.com, alors que le nom de domaine de la boutique légitime comporte un seul « z » dans mageplaza.com, ce qui semble être une faute de frappe de la part des attaquants. Une faute de frappe similaire a été commise dans l'autre adresse e-mail de l'utilisateur de la porte dérobée : support@magaworx.com,  avec un « a » au lieu d'un « e » comme dans le nom original du magasin Mageworx.

Un shell Web est un script malveillant ou un morceau de code que les attaquants téléchargent et exécutent sur un serveur Web pour obtenir un accès et un contrôle non autorisés sur le serveur et ses fichiers et données sous-jacents de manière persistante.

Dans cette opération, les attaquants exploitent un shell Web très avancé dénommé wso-ng, qui, comme indiqué précédemment, a été créé par un chercheur en sécurité il y a plusieurs années. Comme l'indique l'auteur, wso-ng est une nouvelle génération de l'ancien et célèbre WSO (qui signifie Web Shell by Orb). 

Outre les fonctionnalités typiques des shells Web, telles que la collecte d'informations sur le système et la gestion de fichiers et de SQL, wso-ng présente d'autres fonctionnalités remarquables qui lui permettent de se démarquer (Figure 13).

L'une de ces nouvelles fonctionnalités est la page de connexion cachée. Lorsque l'on accède à la page, elle répond par un code d'état HTTP 404 Not Found, donnant l'impression d'une page inexistante. Le contenu visible semble être vide à première vue (Figure 14). Cependant, une inspection du code source de la page révèle la présence d'un formulaire de connexion caché.

Le formulaire est astucieusement caché à l'aide d'une astuce CSS simple : il est décalé de 1 000 pixels vers la gauche, ce qui le maintient hors de la zone visible. Ce formulaire de connexion caché est conçu pour attendre que l'utilisateur saisisse son mot de passe.

Nous avons trouvé un autre outil intéressant dans l'arsenal des attaquants sur le serveur xurum.com : une attaque publique d'une ancienne CVE-2016-5195 nommée Dirty COW pour les élévations de privilèges locales sous Linux (Figure 15).

Étant donné que bon nombre de nos web application firewall (WAF) ont efficacement atténué cette campagne, nous n'avons pas directement observé d'autres actions entreprises par les acteurs malveillants. Cependant, au cours de notre enquête, nous avons remarqué des noms de sites Web qui étaient indirectement liés à cette campagne et qui apparaissaient dans l'en-tête HTTP d'origine/référent de la requête du code d'exploitation.

Au moins l'un de ces sites web était infecté par un simple web skimmer. Le skimmer était installé sur la page principale et n'appliquait aucune technique de dissimulation. Il recueillait les informations relatives aux cartes de crédit et les extrayait vers une zone de dépôt hébergée sur « smileface.site » (Figure 16).

Lors d'une tentative d'accès, ce site Web répond par un message froid « Get out! » Message (Figure 17).

Les informations IP montrent que le serveur est situé à Moscou et hébergé par l'hébergeur russe « reg.ru »(Figure 18).

Notre enquête sur cette campagne indique qu'elle remonte au moins à la fin du mois de janvier 2023. Les attaquants ont fait preuve d'une approche méticuleuse, ciblant des instances spécifiques de Magento 2 plutôt que de répandre leurs attaques sur Internet. Ils possèdent une grande expertise de Magento et consacrent un temps considérable à la compréhension de ses rouages, à la mise en place d'une infrastructure d'attaque et au test de leurs attaques sur des cibles réelles.

Cette campagne est un exemple concret de la façon dont les anciennes vulnérabilités continuent d'être exploitées des années après leur divulgation, alors que les entreprises s'efforcent d'appliquer les correctifs et les mesures de sécurité.

Pour empêcher l'accès initial au serveur, il est conseillé aux professionnels de la sécurité de se tenir au courant des derniers correctifs et de les compléter par la mise en œuvre d'un WAF, tel que App & API Protector d'Akamai.

Étant donné que l'objectif principal des acteurs de la menace Magecart est d'infecter les pages Magento avec des web skimmers et de dérober les informations des cartes de crédit des clients, il est fortement recommandé d'utiliser des solutions de sécurité dédiées supplémentaires. Ces solutions doivent fournir une visibilité sur les comportements des scripts du navigateur et offrir une défense contre les attaques côté client.

Une approche efficace consiste à déployer des mesures de sécurité plus près de l'endroit où se produisent les attaques réelles contre les clients. Il s'agit notamment d'identifier les tentatives de lecture de champs de saisie sensibles et d'exfiltration de données. Nous suggérons de collecter rapidement ces événements pour faciliter une atténuation rapide et efficace avec l'aide de produits de sécurité tels que Akamai Page Integrity Manager.

Au cours de notre analyse des récentes tentatives d'exploitation CVE-2022-24086 de Magento chez nos clients, nous avons découvert d'autres campagnes qui font actuellement l'objet d'une enquête. Nous poursuivrons nos investigations et partagerons nos conclusions avec la communauté de la sécurité. Pour découvrir d'autres recherches approfondies sur la sécurité, suivez-nous sur Twitter.

Les indicateurs d'infection suivants sont destinés à faciliter la détection des activités malveillantes décrites dans l'article.