Vols de données CB : les skimmers tiennent toujours la forme

Un déficit médiatique préjudiciable

Félix Aimé, analyste du sein du Great de Kaspersky, s’intéresse de plus en plus à la menace de ce que l’on appelle les skimmers, les implants logiciels qui permettent justement d’assurer le vol de ces données de CB : « je scanne de l’ordre de 50 000 sites Web par jour, à la recherche d’anomalies, de redirections qui ne devraient pas être, etc. Tous les deux ou trois jours, je récupère des alertes ». Lesquelles, accessoirement, ne se limitent pas à des skimmers, mais concernent aussi « de la redirection publicitaire, des waterholes d’états, etc. ». C’était en fait même le point de départ de ses recherches, avant qu’il n’ajoute à ses outils d’analyse des sites d’e-commerce.

Et régulièrement, sur Twitter, il partage certaines de ses trouvailles. Il n’est pas le seul dans ce cas : Benoît Ancel, de CSIS Security, fait de même. Tout récemment, il a ainsi découvert la présence d’un skimmer sur la boutique en ligne des Fatals Picard, ou encore celle de la Compagnie des Artistes. Lesquels sont, selon lui, toujours infectés au moment où sont publiées ces lignes – ce que confirme d’ailleurs le service Site Check de Sucuri pour le second site Web.

Le store des Fatals Picards est injecté par un skimmer magecart, attention si vous avez commandé du merch recemment
store.fatalspicards\.com/ pic.twitter.com/7uyNhXL4Wu

— Benkøw moʞuƎq (@benkow_) May 31, 2020

Félix Aimé, de son côté, a averti fin mai Bureau Vallée. L’enseigne a réagi très vite, à la surprise du chercheur : « ils ont compris ce qui se passait, mais c’est excessivement rare que non seulement j’ai une réponse, mais celle-ci montre que mon alerte a été comprise ».

C’est d’ailleurs là qu’il identifie un problème grave : le déficit de sensibilisation, de compréhension de la menace : ouvrir une boutique en ligne peut être fait rapidement et relativement aisément, notamment avec un Shopify, par exemple. Dès lors, il n’est pas rare que ceux qui opèrent un site d’e-commerce ne comprennent pas ce qui s’est passé lorsque son site est compromis par un skimmer… ni ne sachent comment gérer l’incident, ne serait-ce que vis-à-vis de leurs clients.

Une menace très dynamique…

Mais les deux analystes ne sont pas les seuls à se pencher sur cette menace. Il faut aussi compter avec Malwarebytes et RiskIQ, notamment, mais également de nombreux chercheurs indépendants. Et il y a une bonne raison à cet intérêt : « le marché des kits de skimmer JavaScript est à la mode », explique Benoît Ancel. Avec des prix autour de 1 300 $, support inclus, illustre-t-il d’un exemple trouvé sur un forum… public, accessible sans authentification.

Selon Félix Aimé, la menace « est très répandue ». Et de distinguer deux types d’attaquants : « les premiers mènent des opérations ciblées », comme sur British Airways ou NewEgg en 2018, donc, visant des sites affichant des volumes de transactions élevés. Les seconds, moins sophistiqués, « peuvent compromettre des sites via des plug-ins par exemple », dans le cadre de campagnes massives. Parce que « même si un site ne compte que quelques dizaines de commandes par jour, leur nombre de sites Web compromis vient compenser ». Et donc assurer la collecte de données de cartes bancaires en masse.

Modestement, Félix Aimé indique ne finalement repérer que les compromissions les plus triviales, notamment lorsque les cyberdélinquants font des erreurs. Surtout, « comme dans tout domaine de la cybersécurité, plus on avance dans la détection, plus les acteurs trouvent des éléments pour contourner la détection ». D’où un effort d’adaptation en continu : « certains commencent à réaliser qu’ils sont facilement détectés et mettent en place des mesures, par exemple en essayant de limiter la présence de leur code malveillant aux seules pages liées au paiement, etc. ».

… Et complexe à traiter

Mais par où entrent les attaquants ? Via des webshells déposés par d’autres qu’eux au préalable ? Non, explique Benoît Ancel : « il existe bien un marché des webshells, depuis longtemps, mais ce que je vois, les acteurs ne l’utilisent pas vraiment pour infecter des boutiques. Ce marché des webshells est plutôt utilisé par des acteurs qui souhaitent des sites compromis pour héberger des charges [malveillantes] ou des scripts pour envoyer des pourriels ». La rédaction avait eu l’occasion d’enquêter sur un tel cas début 2018.

Alors selon Benoît Ancel, les skimmers en JavaScript « sont plutôt déployés via des vulnérabilités identifiées sur les sites de e-commerce, des botnets attaquant en force brute, ou des campagnes de vol de mots de passe visant les administrateurs de ces sites ». À moins qu’il ne s’agisse d’un script tiers, chargé à partir d’un autre site Web, qui aura été compromis, par exemple.

Pour Félix Aimé, la situation est assurément difficile au niveau des opérateurs de sites Web de commerce électronique : « c’est une plaie technique pour eux ». Des outils sont toutefois disponibles, à l’instar des plug-ins Wordfence et Web File Changes Monitor qui permettent de surveiller d’éventuelles altérations illégitimes de fichiers hébergés sur le site Web ; des modifications pouvant éventuellement trahir une attaque et un détournement. Une aide, donc, même s’il n’y a pas non plus à en attendre une solution sans faille.

Des approches techniques et une vigilance continue

Car malheureusement, un attaquant parvenu à s’inviter sur l’hôte du site Web et en particulier dans son interface d’administration dispose en fait de toutes les clés du royaume. Et cela vaut pour toute solution technique basée sur l’hébergement du site Web lui-même.

Par exemple, les mécanismes de Content Secure Policy (CSP) permettent de réduire le risque d’attaque par injection de contenu – dont les fameuses XSS, ou Cross Site Scripting – en spécifiant les domaines à partir desquels une page est autorisée à charger des scripts. « Mais les en-têtes correspondants peuvent être modifiés par les attaquants », relève Félix Aimé.

Autre possibilité, mais toujours avec le même bémol : héberger directement les composants chargés par les pages du site – ce qui permet au passage d’éviter de faire « fuiter des adresses IP de visiteurs » vers les sites hébergeant les composants externes… ou de permettre aux assaillants de « faire un strike » sur tous ceux qui utilisent le même composant compromis.

À l’automne dernier, dans le cadre d’un épisode du podcast Darknet Diaries de Jack Rhysider, Yonathan Klijnsma, chez RiskIQ, formulait quelques recommandations additionnelles : limiter l’appel de scripts sur les pages de paiement, les isoler dans un iframe. Et pourquoi ne pas déléguer le traitement des données bancaires à des tiers, ne serait-ce que Paypal… De quoi déporter le risque et la charge associée à son traitement.