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 !
Laisser un commentaire