Le pixel 1x1 qui vole les cartes : la nouvelle attaque de Magecart à Magento

Une opération de vol de données a mis en danger une centaine de magasins en ligne qui travaillent avec la plate-forme Magento : le code malveillant qui supprime les numéros de carte est caché dans un pixel et déguisé en élément Scalable Vector Graphics (SVG). L'enquête qui a mis en lumière cette campagne a été publiée par la société de sécurité eCommerce Sansec, dont les techniciens détaillent comment les attaquants parviennent à injecter et à exécuter l'écume sans laisser de références externes que beaucoup d'outils de détection font marquer.

La technique est apparemment simple et en même temps ingénieuse : le skimmer vit entièrement en ligne à l'intérieur d'un SVG 1 × 1 pixel qui comprend un attribut chargement. Ce gestionnaire contient la charge utile codée en base64, décodée avec()et ensuite exécuté par un minuteur; ainsi les étiquettes sont évitées< script >et la plupart des scanners automatisés ne le détectent pas facilement. Sansec décrit cette tactique comme un moyen de garder tous les logiciels malveillants "encapsulés" dans un seul attribut, sans références aux fichiers en dehors du site.

Dans la pratique, lorsqu'un acheteur légitime appuie sur le bouton de paiement dans un magasin compromis, un JavaScript malveillant intercepte cette action et affiche une fenêtre émergente qui simule un processus de paiement sécurisé. Le chevauchement comprend les champs habituels pour les données de carte et la facturation et fait des vérifications en temps réel - par exemple la vérification avec l'algorithme de Luhn - pour valider que les chiffres présentés semblent corrects. Les données capturées sont emballées dans JSON, elles sont obfuscanes avec base64 et en outre des opérations simples telles que XOR sont appliquées avant qu'elles soient envoyées à l'attaquant.

Sansec a suivi l'exfiltration dans six domaines recevant l'information et a constaté que tous étaient logés dans IncogNet LLC (AS40663) aux Pays-Bas, chaque domaine recevant des données de dix à quinze victimes confirmées. Dans les campagnes connexes, les attaquants avaient même utilisé WebRTC comme canal de sortie pour éviter les détections basées sur les requêtes HTTP classiques.

Les chercheurs croient que la porte d'entrée de cette vague était des fonds de la vulnérabilité connue comme PolyÉchelle, publié à la mi-mars ; cet échec affecte les installations de Magento Open Source et d'Adobe Commerce dans des versions stables 2.x et permet l'exécution de code non authentifié et la prise de comptes. Pour l'instant, Adobe n'a inclus la correction que dans une version pré-release (2.4.9-alpha3 +), tant de magasins de production restent potentiellement vulnérables. Pour un contexte sur la gravité et le fond de ces attaques de type "Magecart", voir l'entrée générale sur le phénomène. dans Wikipedia.

Sansec indique un certain nombre de signaux et d'actions spécifiques pour les gestionnaires de magasins qui peuvent aider à détecter et à atténuer cette attaque. Parmi les pistes les plus directes figure la présence de balises SVG avec un attributchargementqui invoque(); cette chaîne est un bon point de départ pour rechercher des injections. Un autre point d'engagement à examiner dans le navigateur est l'existence de la clé_ mgx _ cvdans local, puisque votre présence peut indiquer que les données de paiement ont été stockées par la charge malveillante. Il est également recommandé de surveiller et de bloquer les demandes sur des routes inhabituelles telles que/ fb _ métriques.phpou des domaines qui passent par les services d'analyse et, si nécessaire, filtrent le trafic vers IP 23.137.249.67 et les domaines connexes.

Outre ces détections spécifiques, des mesures opérationnelles devraient être mises en œuvre sans délai. Si le site est vulnérable à PolyShell, il est essentiel d'appliquer immédiatement toutes les mesures d'atténuation disponibles et, dans la mesure du possible, de mettre à jour la version qui inclut la correction ou le déplacement vers une succursale sécuritaire. Les gestionnaires devraient examiner l'intégrité des fichiers sur le serveur en comparant avec des copies connues propres, des comptes de vérification et des références administratives, forcer le mot de passe et le changement de clé de l'API, et appliquer des règles dans le WAF pour bloquer les schémas d'injection en ligne. Il est également de bonne pratique d'informer les fournisseurs de paiement et de préparer un plan de réponse du client si le vol de données est confirmé; les lois PCI et la protection des données exigent certaines réponses coordonnées.

Pour les acheteurs réguliers, il y a des précautions simples qui réduisent les risques: utiliser des méthodes de paiement externes lorsque c'est possible (par exemple des services qui touchent la carte), préférer les cartes virtuelles ou à usage unique pour les achats en ligne et surveiller les mouvements dans l'extrait de banque après l'achat. Si une fenêtre pop-up qui redemande les données de la carte semble être "étrange" dans le flux du magasin apparaît lors du paiement, il est approprié de fermer l'opération et de contacter le trade sur un autre canal avant d'essayer de payer à nouveau.

Au niveau institutionnel, cet incident souligne la nécessité pour les fournisseurs de plates-formes d'agir rapidement face à des vulnérabilités critiques et pour les équipes opérationnelles de maintenir des processus de détection qui ne dépendent pas uniquement de signatures dans des fichiers externes. Les outils qui inspectent les scripts en ligne, les contrôles d'intégrité du serveur et une stratégie de déploiement qui limitent les changements directs dans la production aident à réduire la surface d'attaque.

Si vous voulez entrer dans le rapport technique original, la publication Sansec contient les échantillons et les diagrammes de la charge utile: Sansec - SVG en charge Écumeur Magecart. Pour mieux comprendre l'algorithme que les skimmers utilisent pour valider les numéros de carte en temps réel, l'explication de l'algorithme Luhn est disponible dans Wikipédia. Et pour vérifier la version et les notes de documentation d'Adobe Commerce, voir la section des notes de sortie de la plateforme à Notes de diffusion d'Adobe Commerce.

Cet épisode est un rappel que les menaces dans le commerce électronique ne sont pas toujours cachées dans des fichiers évidents ou dans des appels vers des domaines externes; parfois la menace est dans un pixel et dépend de la rapidité avec laquelle les administrateurs et les fournisseurs appliquent des correctifs et des contrôles afin que le pixel ne soit plus un piège.