Defcon Skimming : Un nouveau lot d’attaques Web Skimming

Ces dernières années, les attaques de type Magecart ou Web Skimming sont devenues courantes. Elles opèrent par campagnes, en essayant de toucher autant de cibles que possible. Nous avons vu le modus operandi changer ou évoluer, les groupes cybercriminels cherchant des moyens inventifs de compromettre les cibles. Au cours de la semaine dernière, nous avons observé un nouveau modus operandi évident pour trois groupes de menaces.

Tribune par Pedro Fortuna, Pedro Marrucho et David Alves. Depuis la publication initiale de cet article, l’équipe de recherche a trouvé 343 autres victimes de cette attaque par écrémage.

La découverte de cette attaque par « skimming » (attaque par écrémage) souligne l’importance d’une bonne « hygiène » de sécurité côté client. La plupart des applications web sont un mélange complexe d’éléments tirant parti du code de la chaîne d’approvisionnement web. La plupart des équipes de sécurité n’ont pas de visibilité sur ce code tiers exécuté sur leur site web. Elles ne savent pas s’il se comporte comme il le devrait ou non – que ce soit par accident ou par malveillance. Cet angle mort de la sécurité peut créer un faux sentiment de confiance dans l’évaluation du risque. En effet, il est difficile de mesurer ce que vous ne pouvez pas voir.

Groupe X

Mode Opératoire

Cette première opération d’écrémage web que nous avons découverte utilise une méthode que nous n’avions jamais observée auparavant. Les cybercriminels ont exploité une bibliothèque JavaScript tierce appelée Cockpit. Ce nom désignait initialement un service gratuit de marketing et d’analyse web qui a été abandonné en décembre 2014 (voir la figure A). Cependant, les hackers ont acquis le nom de domaine qui hébergeait la bibliothèque et l’ont utilisé pour servir un script d’écrémage via la même URL. En réenregistrant le domaine éteint et en le configurant pour distribuer du code malveillant, les attaquants ont pu compromettre plus de 40 sites de e-commerce. Les données collectées sur les sites ont été encodées, cryptées puis envoyées à un serveur d’exfiltration basé en Russie.

Malgré l’avis de fin de service émis par Cockpit, plusieurs années auparavant, les sites concernés n’avaient pas supprimé le script de leurs pages. Ce ne sont pas des cas isolés. En effet, de nombreux sites ne suppriment pas les bibliothèques obsolètes, ce qui peut conduire à des liens « morts » pouvant être facilement compromis, en raison d’un manque de visibilité ou de mauvaises pratiques de sécurité.

L’exemple ci-dessous contient un extrait de la manière dont cette bibliothèque tierce est généralement incluse dans un site web. Il s’agit d’un script qui charge le script principal du Cockpit. Le contenu du script chargé dépend de la valeur de l’en-tête « referrer », c’est-à-dire de la page web d’où il est récupéré. Nous avons observé que différents scripts sont renvoyés en fonction du « referrer ». Il s’agit là d’un comportement courant chez les pirates du Web, qui tentent de ne charger le code malveillant qu’en cas de nécessité, ce qui le rend plus difficile à détecter.

Le « Skimmer »

Différents scripts sont chargés en fonction du « referrer ». Si le script est demandé sans en-tête de « referrer », il ne renvoie aucun script (réponse vide). Pour les « referrer » inconnus, un « skimmer » par défaut est servi. Pour un « referrer » spécifique, l’attaquant charge un « skimmer » spécifique. Cela peut être résumé comme suit :

• Pas de référent : pas de script
• Référent inconnu : « skimmer » par défaut
• Référent spécifique : « skimmer » spécifique

Même si le domaine “tracker.web-cockpit.jp” renvoie une page vide pour le moment, nous pouvons voir que le fichier “favicon.ico” contient une copie de l’un des « skimmers ».

Le « skimmer » par défaut

Le « skimmer » par défaut, qui est chargé pour les « referrer » inconnus, ressemble à un « skimmer » Web typique avec quelques aspects distincts. Lorsque le chargement de la page est terminé, le « skimmer » ne s’exécute que dans deux pages web spécifiques, la page de commande et la page d’enregistrement. Pour ce faire, il vérifie l’emplacement de la page par le biais de document.location.href, comme le montre l’extrait ci-dessous (Figure B) :

Si les vérifications de l’emplacement de la page sont réussies, le code d’écrémage est exécuté en suivant le flux typique d’exfiltration de données. Le « cloneur » saisit tous les éléments de saisie, de sélection et de zone de texte de la page qui ne sont pas cachés ou vides. Ces données sont ensuite encodées et cryptées, puis envoyées à un serveur d’exfiltration basé en Russie (voir la figure C).

Cependant, le « skimmer » ne s’arrête pas là. Après avoir exfiltré les données des éléments originaux de la page, il injecte ensuite ses propres éléments factices en imitant un formulaire de saisie de carte de crédit (figure D). Toutes les données insérées par l’utilisateur continueront à être collectées et à être exfiltrées à chaque fois qu’il y aura un clic sur la page.

Le « skimmer » utilise deux cookies pour contrôler l’état de ses opérations. Le premier cookie, nommé “lastva1ue“, stocke le dernier morceau de données qui a été exfiltré et est vérifié pour éviter d’envoyer les mêmes données à plusieurs reprises au serveur d’exfiltration. Le second cookie, nommé “ga_csrf“, est défini lorsque les éléments factices sont ajoutés à la page et est vérifié pour ne pas ajouter d’éléments en double.

Le skimmer spécifique

Nous avons confirmé que certains sites web n’ont pas reçu le « skimmer » par défaut décrit précédemment, mais plutôt une version personnalisée d’une fausse intégration Google Analytics (GA) (Figure E). Cette version personnalisée est très similaire au script légitime. Cependant, l’utilisation de chaînes encodées en Base64 a attiré notre attention car cela ne se produit pas dans le script GA légitime. De plus, l’URL légitime de GA que nous pouvons observer dans la version malveillante n’est jamais utilisée et ne sert que de déguisement.

Dans ce cas, si vous voulez demander le « skimmer », il ne suffit pas d’avoir un référent valide. Le référent doit correspondre au site infecté associé pour que le bon « skimmer » soit servi, sinon vous recevrez un script d’apparence bénigne (Figure F).

Si l’en-tête du « referrer » correspond effectivement au site web infecté correct, le skimmer est servi. Toutes les victimes n’ont pas reçu le même script. Nous avons trouvé au moins trois versions distinctes, mais les différences entre elles sont simples. Certaines visaient uniquement la page de paiement, d’autres cherchaient d’autres cibles. L’utilisation du chiffrement pour le processus d’exfiltration était un facteur distinctif, car tous les scripts ne l’avaient pas mis en œuvre. Le serveur d’exfiltration, bien que sous un domaine différent, était hébergé par la même adresse IP que celui vu précédemment.

Le skimmer a stocké les données non chiffrées dans un cookie nommé “phpssidcache“, avec un simple encodage Base64 (Figure G). De cette façon, il peut vérifier quelles données ont été envoyées et empêcher l’envoi de données en double.

Une fois encore, ce cookie est codé en Base64. Si nous le décodons, nous pouvons voir tous les éléments d’information que le skimmer a collectés et stockés. Dans le tableau ci-dessous (Figure H), nous en présentons quelques-uns :

L’un des sites de e-commerce savait que le script tiers était compromis. Au lieu de le supprimer, il a ajouté un petit avis sur la page de paiement (figure I) :

Il est évident que ce « skimmer » n’est pas conçu spécifiquement pour cette page, mais il s’agit plutôt d’une version générique qui le rend plus flexible. Mais dans certains cas, il peut alerter les utilisateurs que quelque chose ne va pas puisqu’il injectera le faux formulaire de carte de crédit dans des pages qui ne devraient pas en avoir, comme les pages où l’utilisateur a choisi les méthodes “Virement bancaire” ou “PayPal”.

Il est également possible que certains sites aient utilisé un service de génération de sites Web ou un système de gestion de contenu (CMS) qui injectait le script tiers dans leurs pages. Dans ce cas, il se peut qu’ils ne soient pas en mesure de supprimer la bibliothèque de leurs sites en raison de permissions restreintes ou d’un manque de connaissances.

Groupe Y

Mode opératoire

Le deuxième « skimmer » que nous avons trouvé, identifié comme le groupe Y, est très similaire au groupe X, bien que la méthode de distribution soit très différente. Au lieu d’attaquer un service tiers, il attaque chaque victime individuellement, en injectant le script Google Analytics dans leur page d’accueil. Cette fois, la vérification de l’emplacement est effectuée à partir du script du « loader » plutôt que du « skimmer » lui-même, ce qui signifie que le code du « skimmer » n’est chargé que si son « loader » est exécuté sur la page de paiement. L’extrait ci-dessous illustre le contenu du script du « loader » (Figure J). Notez que le script Google Analytics légitimer contient une chaîne nommée “Google Analytics Object” et non “Google Analytics Objects”, ce qui est facilement négligé.

Nous pouvons supposer que cette version moins évolutive ait pu apparaître en premier et que le groupe X a évolué à partir de celle-ci puisqu’ils partagent quelques similitudes.

Le skimmer

Le premier script malveillant est presque identique au “skimmer spécifique” que nous avons décrit précédemment, mais au lieu d’être dans un script tiers, il semble injecté dans les pages Web de chaque victime.

Il s’agit d’une autre version personnalisée d’une fausse intégration Google Analytics. Nous repérons immédiatement les similitudes avec l’autre version dont nous avons parlé précédemment :

• Elle contient également des chaînes encodées en Base64 et utilise atob ().
• Montre également l’URL légitime de Google Analytics mais ne l’utilise pas,
• Injecte également un nouveau script lorsque l’utilisateur atteint la page de paiement.

Parmi les principales différences, nous constatons que la fonction anonyme peut désormais recevoir jusqu’à 8 arguments et que des expressions régulières ont été introduites, ce qui modifie la façon dont l’URL de la page actuelle est vérifiée. Lorsqu’elle se charge sur la page de paiement, elle va chercher l’étape suivante, le « skimmer » lui-même, qui est configuré pour voler toutes les informations accessibles et injecter un iframe malveillant pour les détails du paiement (figure K). L’exfiltration se produit vers un terminal différent sous le même domaine.

Groupe Z

Mode opératoire

Le troisième groupe, appelé Z, semble tirer parti de la même méthodologie que celle utilisée par les groupes Y et X en ce qui concerne « le skimmer », mais nous pouvons constater certaines modifications dans la façon dont la structure du script et la structure du serveur fonctionnent.

Les modifications apportées aux structures de script sont visibles dans les phases de la première et de la deuxième étape. La première étape consiste à injecter un initiateur Javascript malveillant déguisé en Google Tag Manager dans les pages, une approche similaire à celle du groupe Y et du groupe X. La différence ici est la mise en œuvre de la concaténation de chaînes de caractères afin d’éviter la détection.

La phase 2 présente également quelques modifications dans la structure du serveur où les URL de « Skimmer » suivent un modèle différent des deux autres groupes. Ici, elles identifient le service utilisé pour se déguiser et le fichier script contient le nom du site web cible. Une autre différence est la façon dont le script est construit ; il n’est pas en texte clair et il utilise une couche d’obfuscation pour entraver la lisibilité du script.

Le Skimmer

Dans ces campagnes, le groupe cible directement des sites web et injecte un script malveillant initiateur similaire à celui utilisé par le groupe Y (figure L).

• L’image d’exemple montre une charge utile malveillante déguisée en Google Analytics. Elle est similaire aux versions exposées par les groupes X et Y, à l’exception de l’implémentation d’une couche de concaténation de chaînes, [‘Google’+’Analytics’+’Objects’].
• La principale différence entre eux est apparente lorsque nous analysons les étapes suivantes. Nous pouvons voir que le code du « skimmer » a subi de sérieux changements. Certaines modifications ont été apportées à la structure du serveur où les URL du « skimmer » suivent un modèle différent des deux autres groupes. Ici, elles identifient le service utilisé pour se déguiser et le fichier script contient le nom du site cible (Figure M).

https://{{STAGE2_DOMAIN}}/www.google-analytics.com/{{TARGETED_WEBSITE}}

Comme nous pouvons le constater, le script utilise des techniques d’obscurcissement pour nuire à sa lisibilité (figure M).

Après avoir inversé l’obscurcissement, nous pouvons identifier les comportements du « skimmer », l’un de ces comportements est l’injection d’un nouveau formulaire (Figure O) dans la page pour voler les informations du client. Le style du formulaire peut varier en fonction de la page où il est injecté. Il a également été possible d’identifier la présence du formulaire légitime sur la page.

Le code éclairci, nous informe également de l’utilisation de deux domaines d’exfiltration qui sont utilisés simultanément pour collecter les informations (Figure P) :

– gxmod[.]pics/g.php

– gymorning[.]cyou/g.php

Les données exfiltrées contiennent des informations comme :

• Le domaine où le skimmer collectait des informations – {{TARGETED_DOMAIN}}.
• Les données de l’industrie des cartes de paiement (PCI) – {{CC_NUMBER}},{{CVV}}, {{EXPIRE_DATE}}
• Informations personnelles identifiables (PII) – {{NOM}}, {{CVV}}, {{ADDRESS}},

L’image ci-dessous montre comment les informations collectées sont structurées (Figure Q).

Conclusions

L’équipe de recherche Jscrambler a découvert une nouvelle technique utilisée par les attaquants pour obtenir davantage de cibles. Elle consiste à prendre le contrôle de domaines désactivés qui hébergeaient autrefois des bibliothèques JavaScript populaires. Dans la campagne observée, les attaquants ont réussi à prendre le contrôle d’une bibliothèque et ont ciblé des sites de e-commerce. Nous ne savons pas si les attaquants avaient un intérêt particulier pour ces sites. Les groupes de cybercriminels de Magecart cherchent surtout à exfiltrer davantage de données de paiement.

Les sites web victimes avaient des années pour supprimer le lien mort exploité par les attaquants, mais ils ne l’ont pas fait – probablement en raison d’un manque de visibilité des scripts tiers exécutés sur leurs sites et d’une mauvaise hygiène de sécurité.

Les groupes Magecart continueront à trouver des moyens nouveaux et créatifs pour faire tourner des codes malveillants sur les sites de e-commerce. Les entreprises d’e-commerce ont besoin d’une défense proactive pour protéger leurs clients. Cela inclut la surveillance automatisée et en temps réel des scripts et la mise en place de politiques de risque pour limiter considérablement ce que les scripts peuvent faire.

Indicateurs de compromission (IOC) Domaines malveillants :

• tracker.web-cockpit[.]jp  193.3.19.36 – SELECTEL-MSK (Russia)
• passenger210[.]bar  193.3.19.36 – SELECTEL-MSK (Russia)
• bus527[.]cfd  193.3.19.36 – SELECTEL-MSK (Russia)
• follow707[.]cloud  193.3.19.36 – SELECTEL-MSK (Russia)
• war740[.]engineer  193.3.19.36 – SELECTEL-MSK (Russia)
• block714[.]mobi  193.3.19.36 – SELECTEL-MSK (Russia)
• bind853[.]me  193.3.19.36 – SELECTEL-MSK (Russia)
• temple321[.]bar  193.3.19.36 – SELECTEL-MSK (Russia)
• earn454[.]live  193.3.19.36 – SELECTEL-MSK (Russia)
• heavy689[.]immo  193.3.19.36 – SELECTEL-MSK (Russia)
• door111[.]network  193.3.19.36 – SELECTEL-MSK (Russia)
• blind227[.]boutique  193.3.19.36 – SELECTEL-MSK (Russia)
• salt204[.]me  193.3.19.36 – SELECTEL-MSK (Russia)
• dig159[.]digital  193.3.19.36 – SELECTEL-MSK (Russia)
• gymorning[.]cyou  5.188.62.10 – PINDC-AS (Russia)
• hovr[.]monster  5.188.62.10 – PINDC-AS (Russia)
• strimmr[.]buzz  5.188.62.10 – PINDC-AS (Russia)
• lynxer[.]monster  5.188.62.10 – PINDC-AS (Russia)
• 7raven[.]uno  5.188.62.10 – PINDC-AS (Russia)
• 2blu[.]cloud  5.188.62.10 – PINDC-AS (Russia)
• depth305[.]digital  5.188.62.10 – PINDC-AS (Russia)
• slavery588[.]biz  5.188.62.10 – PINDC-AS (Russia)
• reduction925[.]cc  5.188.62.10 – PINDC-AS (Russia)
• supper728[.]gifts  5.188.62.10 – PINDC-AS (Russia)
• mn-vps[.]art  194.169.218.49 – CENTRALNIC LTD (United Kingdom)
• literature539[.]space  194.169.218.51 – CENTRALNIC LTD (United Kingdom)
• gxmod[.]pics  141.98.82.244 – FLYSERVERS-ASN (Panama)