Skimmers à 25 $ : exploitation et exfiltration de l'IA

L'IA améliore le retour sur investissement des attaquants. Il est nécessaire de changer la donne. 

En l'espace de cinq jours en septembre dernier, un seul pirate a utilisé trois systèmes d'IA enchaînés contre une centaine de détaillants en ligne, en pénétrant les systèmes d'au moins deux douzaines d'entre eux pour un coût moyen d'environ 25 dollars par entreprise, et est reparti avec les données de paiement de centaines de milliers d'acheteurs. 

Ce chiffre de 25 dollars est révélateur. Gambit Security, la société de renseignement sur les menaces qui a découvert la campagne après que le serveur de préparation de l'attaquant a été exposé, l'affirme sans détour : il s'agit de « l'un des abus d'IA les plus graves jamais observés ». Gambit a qualifié la rapidité de l'attaque d'« étonnante pour un laps de temps aussi court ». La conclusion du rapport mérite une attention particulière, plus encore que le titre : à un coût très faible, les outils d'IA ont fait preuve d'une patience et d'une persévérance que la plupart des attaquants humains n'auraient pas pour une attaque de ce type, et ils ont obtenu des résultats bien supérieurs, et bien plus rapidement, qu'une campagne menée par des humains. Le rapport préconise que les équipes de sécurité adoptent une approche axée sur la résilience et une infrastructure capable de suivre la vitesse de l'IA, et non pas simplement de meilleures solutions de sécurité. 

Que s'est-il réellement passé? 

Depuis juillet, un attaquant a exploité successivement trois outils d'intelligence artificielle open source : un pour la reconnaissance, un pour l'exploitation autonome et un pour l'orchestration. Durant la période la plus courte observée (du 10 au 15 septembre), ce pipeline a lancé 105 projets d'attaque et compromis au moins 27 organisations (Forbes, selon un rapport indépendant, avance le chiffre d'« au moins 30 »). Le serveur de l'attaquant contenait des données relatives à 618 000 cartes de crédit, dont environ 488 000 appartenant à des Américains. Overwatch Data, une société indépendante d'analyse de la fraude, a vérifié que ces données étaient réelles et uniques, et non falsifiées ou réutilisées. Des dispositifs de skimming de type Magecart ont été détectés sur au moins 19 pages de paiement. 

La liste des victimes couvre tout le spectre des problèmes qui devraient préoccuper un RSSI. On y trouve une entreprise hôtelière et une compagnie aérienne réalisant un chiffre d'affaires annuel de plus de 10 milliards de dollars, une enseigne de mode dont le chiffre d'affaires dépasse le milliard de dollars, mais aussi une armurerie du Minnesota et une chaîne de magasins de cosmétiques de l'Illinois. Si votre premier réflexe en lisant un titre comme celui-ci est de penser « c'est un problème typique des entreprises du Fortune 500 », la campagne elle-même défend une position différente. 

Les victimes reçoivent un dispositif de skimming de paiement 

Les méthodes d'intrusion varient d'une entreprise à l'autre : injection SQL, panneau d'administration exposé, clé cloud divulguée, plugin vulnérable. Cette diversité est précisément le point crucial : grâce à la vitesse et au coût maîtrisés par l'IA, le vecteur d'entrée cesse d'être un facteur déterminant.  

Ce que la plupart des victimes ont en commun, c'est l'étape de monétisation. Une fois le logiciel malveillant infiltré, il doit atteindre la page de paiement et les données volées doivent quitter le site. C'est l'étape commune à toutes les victimes, quelle que soit la méthode utilisée par l'attaquant pour accéder au système ; c'est donc l'étape que nous pouvons aborder directement. 

Nous ne prétendons pas que l'application App Hardening for Web: Browser aurait empêché l'injection SQL ou la mauvaise configuration du cloud qui ont permis à ces attaquants d'accéder au système. En revanche, nous pouvons nous prononcer sur l'injection et l'exfiltration elles-mêmes, la partie de la chaîne qui reste identique dans presque toutes les campagnes de skimmer, y compris celle-ci. 

Se défendre contre la prochaine attaque 

Cette histoire, ainsi que d'autres parues récemment dans l'actualité, véhiculent le même message : les IA exploitent de nombreuses failles pour s'infiltrer. La suite dépendra des protections mises en place. 

Deux fonctionnalités de renforcement de la sécurité des applications Web s'y intègrent directement. La première, la surveillance de l'intégrité des scripts et du DOM des pages de paiement (dans notre produit, Web App Integrity Guard), détecte l'ajout ou la modification de scripts ou d'URL sur une page protégée. La seconde, la liste blanche des requêtes sortantes (In-App Firewall Guard), surveille la destination des requêtes en arrière-plan d'une page et signale ou bloque toute requête ne figurant pas sur la liste des requêtes autorisées. 

Nous ne voulions pas nous fier uniquement à notre documentation concernant le comportement de ces dispositifs. Nous avons donc réalisé le test nous-mêmes : une petite page protégée avec un script statique légitime déjà en place, puis une injection de skimmer simulée (une nouvelle balise script ajoutée à l'exécution) et une tentative d'exfiltration simulée (une requête vers un domaine jamais autorisé). Le script statique, présent lors de l'application de la protection, n'a rien déclenché. Dès l'ajout de la balise script dynamique, Web App Integrity Guard s'est activé. Dès l'exécution de la tentative d'exfiltration, In-App Firewall Guard s'est activé. Chaque variante de skimmer utilisée dans cette campagne, quelle que soit sa méthode d'implantation, aboutit de la même manière : un appel vers une infrastructure contrôlée par l'attaquant. C'est précisément cette étape que ce système détecte, indépendamment du mode d'implantation du skimmer. 

Défense en profondeur, et non en une seule couche. 

Cela ne résout qu'un maillon de la chaîne : l'injection et l'exfiltration. C'est un bon début, mais insuffisant. Bloquer les points d'entrée des attaquants est une tâche distincte : les failles d'injection SQL, les panneaux d'administration exposés et les clés cloud divulguées qui ont permis à plusieurs victimes d'accéder au système. Si une clé API ou un identifiant cloud codé en dur est actuellement exposé dans votre code source ou votre application mobile, il s'agit d'un contrôle différent ; consultez notre article connexe sur la campagne de collecte de secrets de ShinyHunters. Ces mesures ne remplacent pas l'autre ; ensemble, elles constituent l'architecture de résilience préconisée par le rapport, couvrant différentes étapes d'une même attaque. 

Les plats à emporter 

Le point d'entrée dans un environnement de vente au détail variera constamment ; c'est ce qui fait de cette campagne un aperçu et non un cas isolé. L'étape d'exfiltration, en revanche, restera la même. Si votre page de paiement ne fait pas la différence entre le script que vous y avez intégré et celui ajouté par un agent IA cinq minutes plus tôt, une attaque à 25 $ sera négligeable comparée au coût réel de la fraude et des mesures correctives. Je serais ravi de vous expliquer concrètement ce que cela implique pour votre propre processus de paiement.