Skimmer sur Wordpress

[Juanito]

Un nouveau type de skimmer de carte bancaire cible les sites WordPress

Une campagne de skimming récemment découverte s’attaque aux sites WordPress en utilisant une méthode innovante et difficile à détecter. Contrairement aux approches classiques qui insèrent du code malveillant dans les fichiers du site, cette nouvelle méthode repose sur l’injection de scripts dans les bases de données, échappant ainsi aux outils de sécurité traditionnels.

Une méthode d’attaque discrète
 Les cybercriminels exploitent les bases de données des sites WordPress, notamment la table "wp_options", où ils insèrent du code JavaScript malveillant dans les entrées liées aux widgets. Cette approche leur permet d’intégrer leur script directement dans le fonctionnement du site sans modifier les fichiers sources, rendant leur présence presque invisible.En ciblant spécifiquement les pages de paiement, ces attaquants s’assurent que leur skimmer n’intervient que lorsque les utilisateurs saisissent leurs informations de carte bancaire, évitant ainsi d’attirer l’attention.

Fonctionnement

• Activation conditionnelle : Le code malveillant analyse l’URL pour détecter des termes tels que "checkout", activant le skimmer uniquement sur les pages où des transactions financières sont effectuées.
  
• Création de faux formulaires : Le script génère un formulaire frauduleux imitant les passerelles de paiement légitimes comme Stripe ou intercepte les informations saisies dans les formulaires réels.
  
• Vol de données : Les informations sensibles, telles que les numéros de carte, les dates d’expiration, les CVV et les coordonnées de facturation, sont capturées à mesure que l’utilisateur les entre.
  
• Exfiltration sophistiquée : Les données volées sont codées en Base64, chiffrées avec l’algorithme AES-CBC, puis transmises à des serveurs contrôlés par les attaquants, comme "valhafather[.]xyz" et "fqbe23[.]xyz".
  

 Mesures de protection pour les administrateurs de sites WordPress

• Inspecter régulièrement la base de données : Les administrateurs doivent surveiller les tables comme "wp_options" et identifier les entrées suspectes, en particulier celles liées aux widgets.
  
• Mettre à jour régulièrement WordPress : Les mises à jour du CMS, des plugins et des thèmes corrigent souvent des vulnérabilités exploitées par ce type d’attaque.
  
• Implémenter un pare-feu d’application web (WAF) : Un WAF permet de bloquer les requêtes malveillantes avant qu’elles n’atteignent le serveur.
  
• Effectuer des analyses de sécurité fréquentes : Des outils comme Sucuri ou Wordfence permettent de détecter et d’éliminer les logiciels malveillants, y compris les scripts injectés dans la base de données.
  

J'ai trouvé pertinent de poster une new sur ça, étant donné que beaucoup travaillent sur WordPress pour leur Portofolio!

Sources:
https://thehackernews.com/2025/01/wordpr...on-by.html
https://securityaffairs.com/173010/malwa...press.html
https://blog.sucuri.net/2025/01/stealthy...ction.html

[EnZ0]

J'avais eu la news, j'espérais que quelqu'un en parle

Évidemment, bonne idée d’avoir partagé cette actu, surtout que WordPress est souvent utilisé pour des projets pro et perso, notamment pour vos portfolios, donc ça concerne directement tout le monde ici.

En creusant un peu, il semblerait que cette technique de skimming soit en forte augmentation, notamment avec l’émergence de l’exploitation des vulnérabilités des plugins populaires de WordPress (ils prennent assez cher en ce moment). Beaucoup de sites ne surveillent pas assez leurs bases de données, ce qui permet aux attaquants de passer sous le radar des scans classiques qui se concentrent principalement sur les fichiers du site.

Un autre point intéressant : certains outils comme WP-CLI peuvent aider à automatiser la surveillance de la base de données pour détecter des modifications suspectes. Pour ceux qui gèrent plusieurs sites, ça peut être une bonne piste à explorer.

Par contre, ce qui est particulièrement inquiétant ici, c’est que cette attaque est difficile à repérer pour un utilisateur lambda qui ne regarde pas souvent sa base de données. Ça montre bien l’importance d’une surveillance proactive, même pour des petits sites persos ou des portfolios... même si le risque reste limité qu'on s'en prenne à 'nous'.