L'attaque informatique contre Segway expliquée

En bref : le skimmer Magecart de Segway dissimulé dans un favicon booctstrap

• Une charge dans un favicon : Un favicon devrait servir des pixels, pas une charge malveillante. Les attaquants de Segway ont dissimulé un skimmer Magento dans un fichier favicon pointant vers booctstrap[.]com, et tous les flux de menaces ont, une fois de plus, réagi trop tard.
• Inspection complète du payload : Le script malveillant s'affichait comme un faux texte de copyright dans le pied de page, tout en chargeant discrètement, depuis booctstrap[.]com, un skimmer hébergé dans un favicon pour capturer les champs de carte bancaire. cside inspecte la charge complète de chaque script tiers avant que le navigateur ne l'exécute.
• Vérifiez chaque domaine : Si votre boutique Magento charge un script nommé provenant d'un partenaire design ou d'un plugin, vérifiez chaque domaine dès aujourd'hui. Si vous ne pouvez pas tous les vérifier, mettez en place une analyse des scripts en temps réel devant la boutique avant que le prochain attaquant ne dissimule un skimmer dans un fichier image.

Peu de temps ? Découvrez le blocage de Magecart et de skimmers dans le navigateur de cside. Elle couvre tout ce qui suit en un seul déploiement.

En janvier 2022, la boutique en ligne de Segway a subi une attaque sur la chaîne d'approvisionnement web, souvent appelée attaque Magecart. Dans ce type d'attaque, du code JavaScript malveillant est ajouté et se charge côté client, sous forme de scripts tiers.

De nombreux outils courants sont des scripts tiers. Des éléments comme les outils d'analyse, les captchas, et bien d'autres. Mais ce vecteur peut aussi être exploité à des fins malveillantes, comme ce fut le cas ici.

Dans cette attaque contre Segway, leur boutique est hébergée sur Magento. Les attaquants ont ciblé des vulnérabilités dans le CMS lui-même ou dans l'un des plugins installés sur le site Segway. Après avoir compromis le système, ils ont ajouté du JavaScript qui semblait s'afficher comme le copyright du site, mais qui servait en réalité à charger un favicon externe.

À l'intérieur de ce fichier favicon se trouvait un domaine malveillant : « booctstrap[.]com ». Comme on peut le voir sur cette image publiée par Malwarebytes, qui a révélé l'attaque :

Ce domaine chargeait le code JavaScript tiers malveillant, qui visait à capturer les données de carte bancaire des utilisateurs.

Comme on l'a vu plus récemment avec l'attaque Polyfill de 2024.

La mauvaise façon de s'en protéger

Les flux de menaces (threat feeds) restent la solution la plus utilisée pour répondre à ce problème, mais nous estimons que ce n'est pas l'approche à privilégier. Fondamentalement, ils ne savent pas ce qu'ils ne savent pas. Les attaquants enregistrent un nouveau domaine et, sans avoir à réécrire une seule ligne de code, l'attaque repart. Pendant des jours, voire des semaines, jusqu'à ce qu'elle soit repérée à nouveau et que les flux de menaces mettent à jour leurs registres.

cside a été conçu pour arrêter ces attaques sur la chaîne d'approvisionnement web avant qu'elles ne se produisent.

En faisant transiter ces scripts tiers par un proxy et en analysant l'intégralité de la charge de code avant son chargement, nous détectons les codes malveillants comme dans cet exemple. Nous les bloquons, ce qui empêche tout impact sur l'utilisateur, et alertons le propriétaire du site de l'attaque potentielle.

Nous conservons également le code des scripts afin que le propriétaire du site puisse le consulter après l'incident et résoudre le problème sous-jacent.

Ces attaques côté client reçoivent trop peu d'attention. Si d'autres mesures de sécurité échouent, comme ce fut le cas chez Segway, cette attaque aurait tout de même pu être détectée. Surveiller précisément ce qui se passe dans le navigateur de l'utilisateur aurait permis de repérer et d'arrêter l'exfiltration de données.

Réglementation

Comme le montre ce cas, le e-commerce est souvent une cible. Et la réglementation rattrape son retard : avec PCI DSS 4.0, la surveillance des scripts tiers sur les pages de paiement est désormais obligatoire (d'ici mars 2025). Si nous saluons cette avancée, nous vous encourageons vivement à l'appliquer à toutes les pages de l'ensemble de votre site. En avril 2024, nous avons expliqué en détail pourquoi ne pas le faire expose encore votre site à un risque important.

Outre les autres problèmes évoqués dans cet article, des acteurs malveillants pourraient exploiter des scripts compromis sur votre site pour détourner des sessions utilisateur, usurper l'identité d'utilisateurs et effectuer des actions non autorisées, contournant potentiellement l'authentification à deux facteurs et, par ce biais, la protection de votre portail de paiement malgré tout.

Vous pouvez utiliser cside pour surveiller les scripts sur toutes les pages et être en conformité avec cette partie de PCI DSS 4.0. Et vous pouvez protéger votre site contre ce type d'attaques avec cside.

Démarrez en quelques minutes, gratuitement.