Attaque de type Magecart déguisée en Google Tag Manager
Une nouvelle campagne sophistiquée de vol de données de cartes bancaires (web skimming) de type Magecart a été découverte sur plusieurs sites d'e-commerce. Les attaques de type Magecart sont une forme de cybercriminalité qui vise spécifiquement les détaillants en ligne. Ces attaques reposent sur l'injection d'un code JavaScript malveillant dans les pages de paiement des sites Web. Ce code récupère les informations sensibles des clients dès leur saisie et les envoie au serveur de l'attaquant. Ces informations peuvent inclure des numéros de carte de crédit et des informations personnelles.
L'attaque récente avait pour but de voler les informations sensibles des internautes sur des pages et formulaires de paiement. Les attaquants ont réussi à injecter un code JavaScript en ligne malveillant dans les sites Web ciblés en exploitant une vulnérabilité. Le skimmer a usurpé l'identité d'un fournisseur tiers légitime, comme Google Tag Manager, et a dissimulé le code malveillant grâce à un encodage Base64.
L'attaque est toujours présente sur certains sites Web, et se rapproche de l'attaque récente contre le plus grand détaillant de boissons alcoolisées du Canada.
Présentation de l'attaque
Usurpation du code d'un fournisseur connu
Le skimmer injecte un code malveillant sous la forme d'un script en ligne (un script intégré au code HTML et non chargé à partir d'un fichier externe) qui ressemble à un extrait de code de Google Tag Manager (Figure 1). Le pirate parvient ainsi à déguiser le code malveillant en script légitime en le dissimulant derrière un fournisseur connu. Plusieurs campagnes de type Magecart ont déjà utilisé cette technique d'évitement, ce qui rend la détection plus difficile.
En outre, le skimmer utilise l'encodage Base64 pour brouiller toute URL ou tout mot-clé qui pourrait révéler le code malveillant. Ainsi, la présence du skimmer est encore mieux dissimulée.
Figure 1 : code imposteur dans Google Tag Manager
Utilisation du protocole WebSockets et de la fonction eval
Dans cette instance, l'extrait de code en ligne sert uniquement de chargeur et non de véritable code d'attaque. Le chargeur inclut une condition qui déclenche l'attaque uniquement sur les pages de paiement, permettant ainsi au skimmer d'opérer en toute discrétion et de charger le code malveillant complet uniquement sur des pages ciblées, sensibles et pertinentes pour l'attaque.
Une fois l'encodage en Base64 du code du chargeur déchiffré, le code JavaScript qui apparaît est court et simple. En effet, il ne réalise que deux étapes : la création d'une nouvelle connexion WebSocket avec le serveur de commande et contrôle (C2) de l'attaquant, et la mise en place d'une fonction d'écoute qui exécutera le code reçu du C2 avec la fonction « eval » (Figure 2).
Figure 2 : l'encodage du code dissimulé à l'intérieur de l'extrait de code de Google Tag Manager.
L'utilisation de WebSockets et de la fonction « eval » dans les attaques de type Magecart est considérée comme une technique avancée, car elle permet au code malveillant de s'exécuter dans le même contexte que la page sous la forme d'un script de base. Il est donc plus difficile à détecter par les chercheurs, les services de sécurité et les analyseurs qui peuvent opérer sur le site Web ciblé (Figure 3). Cette méthode permet aux pirates de rester discrets dans leurs activités et d'être moins détectables que les requêtes XHR ou les balises HTML traditionnelles.
Figure 3 : une autre variation du chargeur du même skimmer avec l'utilisation de WebSockets
Exécution de contrôles de code
Le déclenchement de la connexion au socket permet au navigateur et au serveur C2 d'échanger des données à tout moment. Le premier message envoyé par le serveur C2 de l'attaquant à la page (Figure 4) contient un code JavaScript qui est immédiatement exécuté par une fonction d'écoute spécifiée dans le code du chargeur.
Le code effectue deux vérifications.
- Il vérifie si une connexion WebSocket a été établie par le biais d'une variable générale définie dans le code du chargeur.
- Puis, il détermine si la page est une page de paiement contenant un bouton de validation.
Si ces vérifications sont positives, le code de l'attaquant envoie un message contenant l'URL de la page en cours au serveur C2. Le serveur C2 répond alors en renvoyant le code malveillant approprié adapté à la page cible spécifique.
Le fait que le serveur C2 patiente pour obtenir l'URL d'une page avant de renvoyer le code d'attaque suggère que cette campagne fonctionne via une structure dynamique capable d'exécuter et de prendre en charge de nombreux sites et pages Web simultanément.
Figure 4 : connexion WebSocket avec le serveur C2 du skimmer
Brouillage du code
La Figure 5 illustre le code d'attaque réel tel qu'il a été obtenu depuis le serveur C2 après validation de l'URL. Le brouillage du code étant important, il est difficile de déterminer sa logique sous-jacente et la progression de l'attaque. Les skimmers de type Magecart utilisent souvent des techniques de brouillage pour compliquer la tâche des experts en sécurité qui cherchent à déchiffrer le code d'attaque et à comprendre l'ensemble de son déroulement.
Figure 5 : le code d'attaque brouillé envoyé par le serveur C2 via la connexion WebSocket
Clarification du code
L'utilisation d'un outil de clarification permet de clarifier la situation et de révéler l'intention de l'attaque. Comme le montre la Figure 6, le code contient un grand nombre de mots-clés conçus pour identifier les champs sensibles de la page ciblée et établir un faux formulaire de paiement sous le contrôle du pirate.
L'objectif final du pirate est de voler les informations personnelles des visiteurs peu méfiants qui interagissent avec la page infectée et remplissent le faux formulaire injecté par le code du pirate en question.
Figure 6 : code d'attaque après clarification
Insertion de faux formulaires pour les fournisseurs tiers
Certaines boutiques ciblées confient leur processus de paiement à un fournisseur tiers. Lorsque les clients transmettent des informations personnelles, ils sont redirigés vers le vendeur tiers pour saisir les informations de leur carte de crédit et terminer la transaction. Le skimmer ne peut pas accéder au fournisseur tiers pour obtenir les informations de la carte de crédit de l'utilisateur final.
Au lieu de cela, le skimmer génère un faux formulaire de carte de crédit sur la page avant de rediriger le client vers le vendeur tiers (Figure 7). Lorsque l'utilisateur clique sur le faux bouton « Paiement » ou « Valider le paiement », le skimmer transmet toutes les données collectées à son serveur C2 et permet à l'utilisateur de reprendre le flux de paiement légitime en le redirigeant vers la véritable page de paiement du vendeur tiers.
Figure 7 : formulaire factice créé par un skimmer
Si le site Web ciblé ne redirige pas vers une page de paiement tiers, le skimmer ne crée pas de nouveau formulaire. Au lieu de cela, il ajoute des fonctions d'écoute JavaScript à toutes les saisies d'informations personnelles sensibles sur la page de paiement et les formulaires de paiement. Lorsque l'utilisateur soumet les informations, le skimmer extrait les données et les envoie à son serveur C2 à l'aide de messages WebSockets.
Dans les deux cas, le skimmer chiffre les données extraites afin de compliquer la détection de toute activité réseau inhabituelle initiée par le skimmer pour les chercheurs et les services de sécurité (Figure 8).
Figure 8 : exemple de message chiffré du skimmer envoyé via une connexion WebSocket
Similitudes des attaques
Au cours de l'enquête, nous avons repéré plusieurs sites Web ayant été victimes de l'attaque. Nous ne pouvons pas confirmer qu'ils sont tous liés à la même campagne, mais des similitudes entre les cas suggèrent l'utilisation de la même structure de type Magecart. Dans certains cas, des indicateurs ont été découverts sur plusieurs sites Web victimes, notamment le chargeur en ligne de l'attaque déguisé en Google Tag Manager factice avec des paramètres codés qui dissimulaient tout signe du skimmer.
Les domaines utilisés par le pirate variaient d'un site Web à l'autre et, dans la plupart des cas, le code de l'attaque effective était récupéré par le code du chargeur sur les pages concernées, ce qui rendait l'attaque encore plus discrète et plus difficile à détecter.
Résumé des techniques et capacités des pirates
Usurpation d'un extrait de code d'un fournisseur connu comme Google Tag Manager
Utilisation de l'encodage Base64 pour masquer tout indicateur du pirate comme les URL et les domaines
Utilisation de WebSockets pour toutes les communications entre le navigateur et le C2 (extraction du code d'attaque et exfiltration des données)
Exécution du code d'attaque avec la fonction eval pour que le script ressemble à un script organique de base
Utilisation de techniques de brouillage pour compliquer la compréhension du code par les chercheurs
Injection de formulaires factices pour collecter des données avant de rediriger vers des pages légitimes de services de paiement tiers
Protégez-vous avec Akamai Page Integrity Manager
Notre équipe a testé la récente attaque de type Magecart contre Akamai Page Integrity Manager et l'attaque a été immédiatement reconnue et atténuée. Des informations détaillées ont été fournies pour le dépannage (Figure 9).
Page Integrity Manager est spécialement conçu pour protéger contre le web skimming, le détournement de formulaires (formjacking) et les attaques de type Magecart. Cette solution apporte une visibilité sur le comportement d'exécution des scripts d'une page Web et collecte des informations sur les différents scripts exécutés sur la page, y compris leurs actions et leurs relations avec d'autres scripts.
En combinant ces données avec une approche de détection multicouche (notamment l'heuristique, l'évaluation des risques, l'intelligence artificielle et d'autres facteurs), Page Integrity Manager est capable de détecter et d'atténuer rapidement les menaces côté client.
Figure 9 : informations détaillées de dépannage d'Akamai Page Integrity Manager
Conclusion
Les skimmers de type Magecart évoluent constamment et deviennent de plus en plus sophistiqués. L'utilisation de méthodes avancées d'évitement et de brouillage par le skimmer décrite dans cet article souligne les difficultés de détection de ces types d'attaques.
Ce jeu permanent du chat et de la souris exige une solution de sécurité complète pour détecter et empêcher les attaques. Ne pas mettre en œuvre une solution de ce type peut entraîner de graves préjudices pour les clients dont la vie privée risque d'être compromise, mais aussi causer des dommages importants à la réputation d'une entreprise et donner lieu à des amendes importantes.
Les nouvelles exigences contenues dans la dernière norme de sécurité des données de l'industrie des cartes de paiement (PCI DSS v4.0) font désormais de la sécurité des navigateurs une nécessité absolue pour toute entreprise qui traite des cartes de paiement en ligne.
En savoir plus
Akamai Page Integrity Manager peut vous aider à répondre à ces nouvelles exigences en vous fournissant un inventaire de tous les scripts exécutés sur votre site une visibilité sur le comportement des scripts et une défense contre les attaques les plus sophistiquées basées sur des scripts.
Indicateurs d'infection
Les indicateurs d'infection suivants sont destinés à faciliter la détection des activités malveillantes et des skimmers décrits dans le blog :
yachtbars[.]fun
app-stat[.]com
Magento-cdn[.]net
nebiltech[.]shop
Rithdigit[.]cyou
Antohub[.]shop
Okqtfc1[.]org
jquery-node[.]com
Découvrez plus d'informations sur l'obtention d'une visibilité du comportement des scripts et la protection contre les attaques côté client avec Akamai Page Integrity Manager.
