[Résolu] Des clients o2switch ciblés par un hack WordPress insidieux – MAJ : L’hébergeur traite cela de manière exemplaire

Identification & causes : tout ce qu’il faut savoir 👇

La semaine dernière, je révélais sur LinkedIn un piratage à priori répandu chez les possesseurs de sites WordPress hébergés chez o2switch. En qualité d’expert sécurité WordPress et grâce à une investigation auprès de quelques confrères touchés et non touchés, nous avons pu en apprendre davantage.

MAJ 31/07/2024 – En résumé

Selon une source en interne, l’hébergeur ne serait vraiment pas en cause. L’hypothèse d’un entretien insuffisant des sites piratés resterait ainsi privilégiée. Toujours selon cette source interne, les moyens mis en place par l’hébergeur pour déterminer l’origine précise de ce souci sont remarquables (quelques exemples m’ont été donnés, j’approuve la stratégie). Enfin, même si le nombre de sites impactés peut sembler élevé, il faut mettre cela en perspective avec le parc important d’o2switch : l’impact réel resterait très limité en proportion et la vaste majorité des clients ne devrait pas être impactée par ce souci spécifique.

De plus, le soir du 30/07/2024, o2switch a fait un geste remarquable et très rare dans le monde des gros hébergeurs, en nettoyant le hack sur les sites impactés. Une réaction courageuse qui m’a surpris de la part d’un hébergeur. En effet, les plus gros hébergeurs ont plutôt tendance à avoir l’habitude inverse, c’est à dire de laisser les clients se débrouiller lorsque le souci vient des sites finaux en eux-même. L’investissement de l’hébergeur est réel ici et suscite mon plus grand respect.

On rappelle qu’en sécurité, le plus important est la prévention : faites la maintenance de votre site avec les mises à jour automatiques, de bonnes sauvegardes et n’oubliez pas de d’utiliser les dernières versions de PHP compatibles. Si besoin d’aide pour cela, c’est ma spécialité 😉

📄 Mode opératoire du hack

Le hack redirige les utilisateurs mobile vers des sites frauduleux, notamment en rapport avec la guerre Ukraine/Russie via un URL shortener hébergé aux Emirats Arabes Unis.

Techniquement il consiste en une injection de code JavaScript obfusqué dans tous les posts WordPress du site. Il est donc chargé dans les pages et articles et parfois dans d’autres plugins comme les plugins de cookies, les plugins d’avis utilisateurs, etc.

Voici un aperçu du code pirate après dé-obfuscation, qui permet même sans parler ce langage de comprendre que l’action a lieu lors du clic et qu’une URL aléatoire est sélectionnée en fonction du « UserAgent », c’est à dire du navigateur utilisé :

Info additionnelle 31/07/2024

La requête effectuant le hack pourrait être une simple requête POST sur le fichier index.php du site, comme un log le suggère, qui semble correspondre à un hack effectif depuis une IP américaine (IP et site masqués) :

Jul-2024:213287:199.195.252.[HIDDEN] - - [27/Jul/2024:20:10:59 +0200] "POST /index.php?s=captcha HTTP/1.1" 200 102292 "https://www.[HIDDEN].fr/index.php?s=captcha" "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; MS-RTC LM 8; InfoPath.3; .NET4.0C; .NET4.0E) chromeframe/8.0.552.224"

On voit ici une requête de 102292 bytes faite sur l’index, ce qui est 100x plus élevé par rapport aux requêtes habituelles de l’ordre de 1000 bytes. D’autant que ce site n’a pas de Captcha… Ce qui est troublant est que la requête résulte en un code 200, ce qui signifie que la requête est acceptée, traitée sans erreur, alors que la visite de cette URL devrait plutôt donner une erreur 404 (Not Found).

🔍 Identification

Le hack est parfois mal inséré dans les articles et s’affiche de manière textuelle dans le corps des pages au lieu de s’exécuter
La plupart du temps il est invisible, vous pouvez vérifier si votre site est impacté en recherchant « _0x365b », ou « 0x3023 », ou « function _0x », via l’inspecteur de votre console développeur à la visite du site, ou via une recherche dans phpMyAdmin
Les antivirus Eset et Avast bloquent l’accès aux sites touchés
Update 31/07/2024 – L’un des sites touchés ne se voit pas via la console développeur, il faut à la place utiliser l’outil en lignes de commandes « curl » pour observer le code malveillant. Il est possible que cela soit dû au cache du site.

Voici un exemple du code pirate tel que visible depuis la console développeur :

🌐 Répartition du hack

Grâce à une recherche du pattern du hack sur Google et Bing, j’ai trouvé de nombreux sites infectés. J’ai contacté l’ensemble des propriétaires des sites pour les alerter, leur conseiller de contacter leur prestataire et leur proposer mon aide si besoin.

Sur 40 domaines impactés, trouvés en France et en Belgique, 2 seulement ne sont pas chez o2switch – update 30/07/2024 : Certains sites chez OVH, Hostinger et divers hébergeurs sont aussi touchés, mais plus rares pour le moment.
D’autres fournisseurs de serveurs étrangers sont touchés mais j’en ai trouvé moins qu’en France.
Cela laisse penser à une attaque ciblée des sites présents sur les IP o2switch, que le hacker aurait trouvé via des listes publiques qui référencent cela. Ce type d’attaques peut cibler n’importe quel hébergeur qui n’y peut strictement rien. C’est pour cela qu’il faut être pro-actif dans votre sécurité.

💡 Des causes toujours incertaines

Voici ce qu’on a pu voir et déduire en recoupant les infos entre confrères :

Comme le hack est insidieux, beaucoup ne sont pas diagnostiqués et détectés rapidement, mais la plus ancienne occurrence semble avoir eu lieu en Mai – update 30/07/2024 potentiellement plutôt en Juillet
Cela ne touche pas un plugin ou un thème spécifique
Le plugin Tiger d’o2switch ne semble donc pas non-plus être la cause du problème, car des sites sans ce plugin sont touchés
Les sites touchés semblent généralement moins entretenus que les autres, mais c’est le cas de la plupart des sites; et des sites assez bien suivis (peut-être pas assez) sont aussi touchés
La faille exploitée a pu provenir du core de WordPress lorsque non mis à jour assez rapidement
Il est possible que cela provienne de l’utilisation d’une version PHP obsolète définie par le gestionnaire de l’hébergement (client final)
Il est possible que la présence d’une seconde instance WordPress (une instance de dev par exemple) dans l’hébergement, qui elle, ne serait pas à jour, puisse déteindre sur l’instance principale, par manque d’isolation (c’est le même hébergement, le même utilisateur système, les mêmes droits, et il ne semble pas y avoir de règle open_basedir pour restreindre le répertoire au niveau de PHP chez o2switch)
Cela ne touche pas les clients d’un serveur spécifique d’o2switch, ils sont répartis sur de plusieurs serveurs mutualisés, et certains serveurs ne sont pas du tout touchés, laissant entendre un souci marginal (donc pas d’intrusion serveur ou hébergeur global)
Il y a une minuscule probabilité pour qu’une intrusion ou une faille hébergeur plus globale aie eu lieu (par exemple une faille dans un paquet système qui permet le hack), mais nous n’avons aucun élément pour le vérifier et dans la mesure où o2switch n’a rien signalé, il est plus raisonnable de penser que le souci provient de l’applicatif final (WordPress) ou de la version de PHP utilisée par le client final.
– Update 29/07/2024 Il est enfin possible qu’une faille du serveur web Apache aie été exploitée, soit lorsqu’elle n’était pas encore correctement corrigée, soit car o2switch a trop tardé à mettre à jour ses versions logicielles. Les dates semblent concorder pour les hacks les plus récents. Là encore aucune certitude sans une annonce officielle de l’hébergeur.
– Update 31/07/2024 Des failles dans des sous-versions de PHP, notamment dans certaines révisions de PHP 8.0 pourraient expliquer le piratage. Cela concorde avec les requêtes observées pouvant causer un buffer overflow et permettre un injection de code. Si les sous-versions de PHP 8.0 de l’hébergeur ne sont pas à jour, cela explique la possibilité du hack. Quoi qu’il en soit, le client est fautif si c’est la cause, car on rappelle que PHP 8.0 est dans tous les cas obsolète et ne devrait plus du tout être utilisé. Il n’est d’ailleurs plus disponible à la sélection sur les hébergements LRob.
Aucun hack à déplorer sur les hébergements LRob.

🔨 Réparation du hack

La réparation consiste à nettoyer la base de données en effaçant les lignes correspondant au pattern du hack. Avant toute opération, sauvegardez votre base de données. Les fichiers des sites web ne semblent pas impactés sur ce hack, mais une vérification manuelle complète est toujours recommandée comme pour tout hack. Pensez aussi à vider les différents caches pour que le code malveillant en soit également retiré.

Besoin d’aide pour réparer vos sites et rester sécurisé à l’avenir ? Découvrez mes services de réparation et sécurisation WordPress ainsi que mes hébergements WordPress sécurisés.

Si vous avez plus d’infos, partagez-les en commentaires ou MP !

Partager ce post

6 réponses à “[Résolu] Des clients o2switch ciblés par un hack WordPress insidieux – MAJ : L’hébergeur traite cela de manière exemplaire”

Romain

31/07/2024

Merci Robin pour ton enquête approfondie !

Il est temps de prier les dieux du « numérique » :
Ô grand Zeus, maître des clouds, toi qui contrôles nos données depuis tes serveurs célestes, nous te prions de ne pas laisser nos précieux selfies et documents compromettants tomber entre de mauvaises mains. Que ton trône en titane garde à jamais nos secrets bien au chaud et nos chats bien mignons.

Répondre
1. Robin Labadie (LRob)
  
  31/07/2024
  
  Haha, merci à toi aussi pour l’aide apportée et les infos très utiles !
  Si tu souhaites être crédité dans l’article ce sera avec plaisir. 👍
Odile

31/07/2024

Merci Robin pour ton aide sur mef74.fr
l »antivirus avast a bloqué très efficacement le malware.
Apparemment certains ont eu des pop-up de pubs indésirables.
Sur IPAD(safari) j’ai pu ouvrir le site mais je n’ai rien remarqué de particulier.
Quant à la version PHP, il semble que Romain ait la version 8.1.29
faut-il passer à la 8.3.9 ? Si WordPress est compatible?
Si le hack vient d’un POST sur index.php, est-ce que un ou des comptes sont compromis
et faut-il changer les passwords ?
En tout cas j’ai découvert ton site et l’ai trouvé très intéressant.
Odile

Répondre
1. Robin Labadie (LRob)
  
  01/08/2024
  
  Avec plaisir Odile, remercie surtout ton prestataire qui a été exemplaire dans sa prise en charge. Extrêmement sympa et intéressant qui plus est.
  
  Merci pour l’info d’Avast, je vais l’ajouter à l’article.
  
  Je n’ai pas vu de popups de mon côté mais des redirections. L’effet est quasiment le même (du contenu indésirable s’affiche), mais la terminologie est importante : dans le cas d’un popup, c’est dans une nouvelle fenêtre ou un nouvel onglet, dans le cas d’une redirection, c’est la fenêtre actuelle qui change de site en arrivant sur le site de destination indésirable. Donc pour être 100% exact, on parle ici de redirection.
  
  Le hack vérifiait s’il était sur smartphone (plutôt iPhone à priori, mais potentiellement aussi Android), donc l’iPad n’est pas concerné car c’est une tablette. Là aussi cela peut sembler subtile mais la différence compte.
  
  PHP 8.1 est encore supporté en termes de sécurité. Pour sûr si ton site est parfaitement à jour avec uniquement des scripts bien supportés, vous devriez pouvoir passer à PHP 8.2 ou 8.3 sans problème. Les différences sont relativement minimes et la plupart des scripts sont compatibles. Attention simplement en cas de e-commerce, il faut vérifier plus en détails, et plutôt passer de version en version et vérifier calmement si tout est OK (en examinant notamment les logs du site et en testant les fonctionnalités). N’hésite pas à faire le changement, et en cas de souci quelconque il est facile de revenir en arrière, au pire vous aurez une page ou un plugin qui ne fonctionnera pas mais pas d’impact long terme sur une version de PHP trop récente, je n’ai jamais vu ça en 10 ans d’hébergement.
  
  Enfin, de ce que je sais, le hack précis n’a du tout compromis les données des sites ou leurs compte utilisateurs (et administrateurs). Il a simplement ajouté un vilain bout de code qui faisait cette redirection lors de la visite via un smartphone. Par bonne mesure, le seul mot de passe à changer serait le mot de passe MySQL (intervention technique). Car potentiellement le hacker peut le connaître, celui-ci semblant nécessaire pour prodiguer le hack. Le risque est limité car o2switch ne permet pas la connexion distante aux bases de données, mais cela permet quand même d’exploiter des failles si le hacker le connaît et le garde en mémoire.
  
  Au plaisir d’échanger.
Cécile

26/08/2024

Bonjour Robin,
Super boulot !
J’ai moi-même été impactée et pas trop aidée par o2. Je me suis un peu débrouillée toute seule d’autant que j’étais dans les premières avec une version PHP à jour (depuis longtemps) et un site régulièrement mis à jour, protégé par Wordfence, avec des mp très forts… J’ai fait appel à un dev de ma connaissance (mais pas fan de WP) qui avait effectivement réussi à trouver ce bout de code mal inséré puisque visible en dur sur les pages semble-t-il. J’ai restauré le site a une version assez ancienne pour être sûr de ne rien embarquer dans la restauration mais j’avoue que c’est assez stressant. Aujourd’hui un comportement étrange sur un autre de mes sites sur un autre serveur me fait craindre un nouveau piratage (mon site était à la poubelle !!!!). Je suis en train de tout vérifier à nouveau mais je ne sais pas comment ils ont fait les première fois pour entrer donc difficile de faire plus surtout que je ne suis vraiment pas tech.
Voilà, je partage mon expérience pour d’autres si jamais et je suis dispo si tu souhaitais des infos complémentaires sur ce qui s’est passé de mon côté.

Répondre
1. Robin Labadie (LRob)
  
  26/08/2024
  
  Hello Cécile,
  Merci pour ton commentaire.
  Le code était parfois visible, parfois non (il fallait ouvrir la console développeur).
  Pour le 2e site, il faut voir si le souci est le même ou différent.
  Je t’envoie un email pour en discuter en privé