Des chercheurs de la société de sécurité applicative Jscrambler viennent de publier un récit édifiant sur les attaques de la chaîne d'approvisionnement…

… c'est aussi un puissant rappel de la longueur des chaînes d'attaque.

Malheureusement, c'est long simplement en termes de fiable, peu en termes de complexité technique ou de nombre de maillons de la chaîne elle-même.

Il y a huit ans…

La version de haut niveau de l'histoire publiée par les chercheurs est simplement racontée et se déroule comme suit :

• Au début des années 2010, une société d'analyse Web appelée Cockpit proposait un service gratuit de marketing et d'analyse Web. De nombreux sites de commerce électronique ont utilisé ce service en se procurant du code JavaScript à partir des serveurs de Cockpit, incorporant ainsi du code tiers dans leurs propres pages Web en tant que contenu de confiance.
• En décembre 2014, Cockpit a fermé son service. Les utilisateurs ont été avertis que le service serait mis hors ligne et que tout code JavaScript importé depuis Cockpit cesserait de fonctionner.
• En novembre 2021, des cybercriminels ont racheté l'ancien nom de domaine de Cockpit. Pour ce que nous ne pouvons que supposer être un mélange de surprise et de plaisir, les escrocs ont apparemment découvert qu'au moins 40 sites de commerce électronique n'avaient toujours pas mis à jour leurs pages Web pour supprimer tout lien vers Cockpit, et appelaient toujours à la maison et acceptaient tout JavaScript. code qui était proposé.

Vous pouvez voir où va cette histoire.

Tous les anciens utilisateurs malheureux de Cockpit qui n'avaient apparemment pas vérifié correctement leurs journaux (ou peut-être même pas du tout) depuis la fin de 2014 n'ont pas remarqué qu'ils essayaient toujours de charger du code qui ne fonctionnait pas.

Nous supposons que ces entreprises ont remarqué qu'elles ne recevaient plus de données d'analyse de Cockpit, mais parce qu'elles s'attendaient à ce que le flux de données cesse de fonctionner, elles ont supposé que la fin des données était la fin de leurs problèmes de cybersécurité concernant au service et son nom de domaine.

Injection et surveillance

Selon Jscrambler, les escrocs qui ont repris le domaine défunt, et qui ont ainsi acquis une voie directe pour insérer des logiciels malveillants dans toutes les pages Web qui faisaient encore confiance et utilisaient ce domaine désormais relancé…

… a commencé à faire exactement cela, en injectant du JavaScript non autorisé et malveillant dans un large éventail de sites de commerce électronique.

Cela a permis deux principaux types d'attaque :

• Insérez du code JavaScript pour surveiller le contenu des champs de saisie sur des pages Web prédéterminées. Données en input, select ainsi que textarea (comme on peut s'y attendre dans un formulaire Web typique) ont été extraits, encodés et exfiltrés vers une gamme de serveurs "call home" exploités par les attaquants.
• Insérez des champs supplémentaires dans les formulaires Web sur les pages Web sélectionnées. Cette astuce, connue sous le nom Injection HTML, signifie que les escrocs peuvent corrompre les pages auxquelles les utilisateurs font déjà confiance. Les utilisateurs peuvent vraisemblablement être amenés à saisir des données personnelles que ces pages ne demanderaient normalement pas, telles que des mots de passe, des anniversaires, des numéros de téléphone ou des détails de carte de paiement.

Avec cette paire de vecteurs d'attaque à leur disposition, les escrocs pourraient non seulement siphonner tout ce que vous avez tapé dans un formulaire Web sur une page Web compromise, mais également rechercher des informations personnelles identifiables (PII) supplémentaires qu'ils ne pourraient normalement pas voler.

En décidant quel code JavaScript servir en fonction de l'identité du serveur qui a demandé le code en premier lieu, les escrocs ont pu adapter leur logiciel malveillant pour attaquer différents types de sites de commerce électronique de différentes manières.

Ce type de réponse sur mesure, facile à mettre en œuvre en examinant les Referer: En-tête envoyé dans les requêtes HTTP générées par votre navigateur, il est également difficile pour les spécialistes de la cybersécurité de déterminer la gamme complète des «charges utiles» d'attaque que les criminels ont dans leurs manches.

Après tout, à moins que vous ne connaissiez à l'avance la liste précise des serveurs et des URL que les escrocs recherchent sur leurs serveurs, vous ne pourrez pas générer de requêtes HTTP qui libèrent toutes les variantes probables de l'attaque que les criminels ont programmées dans le système.

Au cas où vous vous poseriez la question, le Referer: header, qui est une faute d'orthographe du mot anglais "referrer", tire son nom d'une erreur typographique dans l'internet d'origine Normes document.

Que faire?

• Examinez les liens de votre chaîne d'approvisionnement sur le Web. Partout où vous comptez sur des URL fournies par d'autres personnes pour des données ou du code que vous servez comme s'il s'agissait des vôtres, vous devez vérifier régulièrement et fréquemment que vous pouvez toujours leur faire confiance. N'attendez pas que vos propres clients se plaignent que « quelque chose semble cassé ». Premièrement, cela signifie que vous comptez entièrement sur des mesures de cybersécurité réactives. Deuxièmement, il se peut que les clients eux-mêmes n'aient rien d'évident à remarquer et à signaler.
• Vérifiez vos journaux. Si votre propre site Web utilise des liens HTTP intégrés qui ne fonctionnent plus, il est clair que quelque chose ne va pas. Soit vous n'auriez pas dû faire confiance à ce lien auparavant, parce que ce n'était pas le bon, soit vous ne devriez plus lui faire confiance, parce qu'il ne se comporte plus comme avant. Si vous n'allez pas vérifier vos journaux, pourquoi s'embêter à les collecter en premier lieu ?
• Effectuez régulièrement des transactions de test. Maintenez une procédure de test régulière et fréquente qui passe de manière réaliste par les mêmes séquences de transactions en ligne que vous attendez de vos clients, et suivez de près toutes les demandes entrantes et sortantes. Cela vous aidera à repérer les téléchargements inattendus (par exemple, votre navigateur de test aspire du JavaScript inconnu) et les téléchargements inattendus (par exemple, les données sont exfiltrées du navigateur de test vers des destinations inhabituelles).

Si vous vous procurez toujours du JavaScript à partir d'un serveur qui a été retiré il y a huit ans, surtout si vous l'utilisez dans un service qui gère des PII ou des données de paiement, vous ne faites pas partie de la solution, vous faites partie du problème …

… alors, s'il vous plaît, ne soyez pas cette personne !

Remarque pour les clients Sophos. Le domaine web "revitalisé" utilisé ici pour l'injection JavaScript (web-cockpit DOT jp, si vous voulez rechercher vos propres journaux) est bloqué par Sophos en tant que PROD_SPYWARE_AND_MALWARE ainsi que SEC_MALWARE_REPOSITORY. Cela indique que le domaine est connu non seulement pour être associé à la cybercriminalité liée aux logiciels malveillants, mais également pour être impliqué dans la diffusion active de code malveillant.

• Contenu propulsé par le référencement et distribution de relations publiques. Soyez amplifié aujourd'hui.
• Platoblockchain. Intelligence métaverse Web3. Connaissance Amplifiée. Accéder ici.
• La source: https://nakedsecurity.sophos.com/2022/12/08/credit-card-skimming-the-long-and-winding-road-of-supply-chain-failure/