Le Comptoir Sécu

Parlons cybersécurité...autour d'un verre!

Le point sur MageCart

Actif depuis 2015 d’après la société RiskIQ qui le suit de près, les groupes qui composent les exploitations connues sous le nom de MageCart ne cessent de faire parler d’eux. Leur but est simple : s’introduire dans un système, le compromettre de la manière la plus discrète possible et ensuite dérober les données personnelles et bancaires saisies par les clients qui visitent ou achètent sur ces sites. Dans cet article, nous ferons le point sur les modes opératoires, ce qui distingue plusieurs groupes d’attaquants et ce qu’on peut faire pour s’en prémunir.

De (très) nombreuses victimes ?

Avant de rentrer dans les détails un peu plus techniques, jetons un coup d’oeil aux victimes les plus connues de MageCart :

Si le nombre de personnes touchées par le vol de données est communiqué pour British Airways (380 000 personnes concernées), il n’existe pas d’estimation précise en ce qui concerne les autres entreprises à l’heure de l’écriture de cet article. De plus, le mode opératoire ne laisse espérer aucun décompte fiable. Néanmoins, certains sites réalisant des audiences assez importantes, RiskIQ indique que leur nombre pourrait être du même ordre de grandeur que dans le cas de British Airways.

Concernant le nombre de sites touchés, les estimations des chercheurs sont impressionnantes. En trois ans, ce n’est pas moins de 110 000 sites qui auraient ont été compromis par ces campagnes de vol d’informations bancaires. La menace n’est par éradiquée, puisque certains sites sont réinfectés plusieurs dizaines de fois.

Récupération illégitime des données bancaires et personnelles

Principe général

À l’instar des distributeurs bancaires piégés pour récupérer les informations de votre carte bancaire, MageCart piège les sites web afin de récupérer les informations qui transitent via les formulaires que vous utilisez afin de réserver un billet d’avion, acheter du matériel informatique, etc. La façon dont les groupes opèrent est simple : altérer le contenu d’un site afin de modifier un script légitime et d’insérer quelques dizaines de lignes de code malveillant en fin de fichier. Cette opération reste discrète, puisque le site fonctionne « comme d’habitude », et le navigateur n’y voit rien d’anormal sauf à ce que les requêtes d’exfiltration violent les politiques CSP (on y reviendra plus tard). Il existe deux méthodes pour mener à bien ce type d’attaque :

Dans un récent rapport détaillé, RiskIQ et Flashpoint (Communiqué de presse – accès direct au rapport (PDF) sans le formulaire commercial), différents groupes utilisent différentes méthodes.

Compromission directe du service

Dans le cas de British Airways, c’est le script Modernizr.js présent sur le serveur de la société qui a été modifié. Il s’agit d’une bibliothèque présente sur tout le site et qui permet d’adapter le contenu au navigateur. Quand ce mode opératoire est utilisé, le groupe modifie son code, le nom du formulaire de paiement du site ciblé étant par exemple directement écrit dans le code. Cela permet à la fois de n’activer l’exfiltration que sur les pages intéressantes, et de déjouer une analyse antivirale par signature, car chaque compromission est différente (le code étant modifié, la signature du code malveillant n’est pas la même, et les URL de callback sont des domaines proches du domaine légitime, achetés pour l’opération).

Le piratage de BritishAirways a intrigué les chercheurs de RiskIQ. Lors de la communication sur la fuite de données par la société, celle-ci a indiqué que les utilisateurs du site et de l’application mobile étaient impactés, ce qui sortait du schéma de la compromission de sites web. Afin de comprendre comment l’application mobile avait pu être infectée, les chercheurs ont analysé les requêtes HTTP(S) qui sortaient de l’application et se sont vite rendu compte que le contenu de certaines pages était récupéré directement du site, qui lui était infecté. L’attaquant n’avait donc pas fait évoluer son mode opératoire.

Compromission de la supply chain

Dans d’autres cas, comme pour TicketMaster, c’est le fichier présent sur le site d’une tierce partie, à savoir Inbenta, qui a été modifié. L’avantage de cette seconde méthode est qu’elle permet de toucher un nombre plus important de sites. En effet, de nombreuses bibliothèques nécessitent que soit ajoutée une balise <script> qui pointe vers un fichier du serveur du fournisseur pour profiter des fonctionnalités. Pour éviter que la charge utile ne se déclenche sur toutes les pages, les scripts s’attachent à une série de noms de formulaires communément utilisés pour collecteur des coordonnées (pour récupérer le nom du porteur de la carte) et les numéros de carte.

Soit dit en passant, les chercheurs de RiskIQ ont détecté la compromission par MageCart de plusieurs tierces parties : PushAssist, Clarity Connect ou encore Annex Cloud.

Capture et préparation des données

Quel que soit le mode opératoire, quelques lignes de JavaScript suffisent à récupérer vos données.

La première étape de l’infection étant franchie, il ne reste plus qu’à collecter les données et à les exfiltrer. Le code JavaScript, affiné au fil des mois par ses développeurs, fait à peine une vingtaine de lignes et est d’une simplicité enfantine (une fois l’obfuscation retirée ;)) pour qui connaît un minimum le JavaScript. Voici le code utilisé dans le cas de British Airways :

extrait de code

Voyons ce code un peu plus en détail :

  1. La première ligne du code, window.onload = function() { permet d’enregistrer une fonction qui sera exécutée lorsque la page aura fini son chargement. En JavaScript, et cela a son importance pour la suite, nous avons la possibilité d’écouter les différents événements utilisateurs déclenchés sur la page (frappe clavier, clic souris, etc.).

  2. La seconde ligne du code jQuery("#submitButton").bind permet d’ajouter un « écouteur » sur l’élément submitButton présent sur la page. En HTML, il existe des moyens de donner des identifiants uniques à des éléments. Dans notre exemple, il est probable que le code HTML du site de British Airways contienne du HTML qui ressemble à <input type="submit" id="submitButton" />. Lorsque que le client cliquera (mouseup) ou touchera sur sa tablette (touchend) cet élément, alors les instructions définies dans la fonction de rappel seront exécutées.

  3. Les lignes 3 à 9 vont permettre de construire une variable n (n = {}) qui contiendra la valeur des champs du formulaire. Les éléments ciblés par le code malveillant sont des balises HTML ayant pour identifiant personPaying et paymentForm. À ce stade, n contient donc tous les champs sous forme "nom dans le formulaire" = "valeur".

  4. Les lignes 10 et 11 vont récupérer les données présentes dans n et les formater au format Json (var t = Json.stringify(n)), qui ressemblera à quelque chose de la sorte (exemple fictif) : {"cardNumber": "21333424324", "cvv" : "843", "person": {"name" : "Doe", "firstname" : "John"}}

  5. Enfin, les lignes 13 à 19 sont chargées d’envoyer, de manière asynchrone, les données précédemment formatées à l’attaquant à l’aide de la fonction ajax de la bibliothèque jQuery.

Exfiltration des données

Comme nous l’avons vu plus haut, les données sont envoyées via une requête Ajax sur un serveur contrôlé par les attaquants.

Dans le premier cas, les attaquants ont réservé des noms de domaine relativement proche de ceux de leurs victimes pour que le trafic paraisse légitime à quiconque regarderait les requêtes HTTP(S) partant du site :

Du côté TLS, alors que Let’s Encrypt est généralement utilisé par les pirates (mais pas que, Let’s Encrypt reste une excellente initiative) pour générer gratuitement un certificat X.509, MageCart a choisi d’acheter, dans certains cas dont les exemples ci-dessus, des certificats auprès de Comodo. Cela renforce leur camouflage.

Dans d’autres cas, les attaquants ont utilisé directement d’autres sites compromis. En n’exploitant pas leur propre infrastructure, ils rendent les opérations de take down difficiles, car le site de Command & Control héberge aussi une activité légitime. Il faut alors que le propriétaire désinfecte son site (et il faut dans un premier temps réussir à le joindre…).

Différents groupes réunis sous une même bannière ?

L’appellation MageCart provient des analystes. L’analyse détaillée des méthodes d’attaque, mais aussi du réseau de blanchiment utilisé pour écouler les cartes, a conduit à l’identification de sept groupes, dont certains ont été fusionnés par la suite au fil de l’enquête. Nous vous recommandons vivement le rapport détaillé (PDF) pour comprendre l’analyse.

L’analyse du cas Umbro Brasil par le laboratoire de MalwareBytes montre, quant à lui, que la concurrence peut faire rage entre deux groupes qui avaient infecté ce site. Ainsi, l’un des deux codes malveillants vérifiait la présence d’un autre code malveillant. Si la détection était positive, le numéro de carte bancaire était volontairement falsifié afin que ce dernier récupère un numéro de carte invalide.

Un cas riche d’enseignements

Avec le développement de l’utilisation du JavaScript ces dernières années, ce type de pratique risque de se populariser et de se perfectionner. Depuis début 2015, on voit que le groupe tente de modifier ses pratiques afin de rendre plus compliquée la détection (pour les solutions de sécurité et les chercheurs en sécurité), et continue, peut-être grâce à cela, à accumuler des victimes. Alors que les distributeurs bancaires piégés continuent de faire de nombreuses victimes, en sera-t-il de même pour son homologue dématérialisé ?

Les sites web sont un patchwork de bibliothèques, souvent externes et non maîtrisées, ajoutées par les développeurs au fil des features requests. Leur sécurisation est complexe.

Les Content Security Policies (CSP) permettent d’indiquer quelle ressourcer peut faire quoi et où. On peut indiquer quelles URL servent les scripts, où les formulaires ont le droit d’être envoyés. D’expérience, c’est aussi difficile à écrire, à tester qu’à maintenir. Si vous avez réussi à vous en sortir avec les CSP, n’hésitez pas à nous partager votre expérience ! Akamai en parle dans une série de pbulications.

Les subresource integrity (SRI) précisent la somme de contrôle (le hash) des scripts. Si le script téléchargé ne correspond pas, le navigateur refusera de l’exécuter. Cela protège contre la compromission de la supply chain. Si c’est pratique pour les frameworks qui ont une version fixe (comme jQuery), c’est inutilisable si votre fournisseur change son script toutes les semaines sans vous prévenir (ce qui peut être le cas des outils de chatbot (qui sont aussi présents sur vos pages de paiement, n’est-ce pas ?)).

L’obfuscation. Il semble que Troy Hunt et Jonh Elliott discutent de l’intérêt de l’obfuscation de ses scripts pour rendre l’insertion d’un attaquant plus complexe, dans un module de formation Pluralsight (que nous n’avons pas suivi).

Il est aussi possible de grapher les interactions d’un site avec des outils comme Lookyloo pour vérifier qu’il n’y a que des domaines légitimes. Ou encore de surveiller les vulnérabilités publiées sur vos dépendances avec des outils tels que Snyk (qui vont pousser les correctifs en automatique dans votre dev branch dans certains cas).

Enfin, ce sujet rappelle qu’il ne faut pas sous-estimer les besoins organisationnels pour garder ses sites à l’abri. Même si les développeurs font attention, une supervision active et avancée paraît de plus en plus nécessaire.

 

Sources diverses (en plus des liens de l’article) :