L’anatomie d’une attaque de cloaking SEO sur WordPress

Les attaques de cloaking SEO sont discrètes, lucratives et de plus en plus fréquentes sur WordPress. Voici comment elles fonctionnent, à partir d’un audit réel sur le site d’une agence de Sydney.

A person at a computer investigating a WordPress SEO cloaking attack

Tous les piratages de WordPress ne sont pas bruyants. Certains attaquants ne veulent ni défigurer votre site ni le prendre en otage. Ils veulent détourner en silence l’autorité de recherche de votre domaine et l’utiliser pour positionner leur propre contenu dans Google. Ces attaques s’appellent des attaques de cloaking SEO, et elles comptent parmi les compromissions les plus dommageables qu’un site d’entreprise puisse subir, car le propriétaire ignore souvent qu’elles ont lieu.

Cet article décrit exactement comment fonctionne une véritable attaque de cloaking SEO, à partir d’une étude de cas récente d’une agence de Sydney où chaque fichier et chaque aiguilleur a été identifié lors d’un audit forensique. Si vous gérez un site WordPress, ce qui suit est le schéma que vous devriez savoir reconnaître.

Ce que signifie le cloaking

Le cloaking consiste à servir aux moteurs de recherche un contenu différent de celui présenté aux visiteurs humains. Une page peut montrer à Googlebot un long article bourré de mots-clés sur des sujets commerciaux sans rapport, tout en affichant à un visiteur normal une page d’atterrissage générique ou une redirection. Le but est de tromper les moteurs de recherche pour qu’ils classent le contenu masqué sous l’autorité d’un domaine établi.

Google a des règles contre cela. Le cloaking enfreint les consignes aux webmasters et peut valoir à un domaine des pénalités d’action manuelle ou un effondrement complet du classement s’il est détecté. L’attaquant s’en moque, car le domaine n’est pas le sien.

Le schéma des cinq répertoires

Le cas de Sydney utilisait une version particulièrement propre de l’attaque. L’attaquant avait créé cinq nouveaux répertoires à la racine du site, chacun nommé pour reproduire une vraie page WordPress. Des dossiers portant des noms comme about, contact, good-to-know, services et work apparaissaient sur le disque. Chacun contenait exactement trois fichiers. Un aiguilleur index.php. Un fichier HTML user.php. Un fichier HTML wp-log.php.

La raison de nommer les dossiers d’après de vraies pages était simple. Lorsqu’une requête arrivait pour /about/ sur le site, le serveur web vérifiait d’abord le système de fichiers. Un dossier nommé about existait, avec un index.php à l’intérieur. Le serveur web résolvait ce fichier avant que le propre routage d’URL de WordPress n’intervienne. Chaque requête vers ces URL atteignait le code de l’attaquant plutôt que la page WordPress légitime.

L’aiguilleur

Le fichier index.php de chaque dossier était un petit bout de PHP qui ne faisait qu’une seule chose. Il inspectait l’en-tête HTTP User-Agent de la requête entrante et aiguillait en conséquence. Si le User-Agent contenait Googlebot, Googlebot-Mobile ou Googlebot-News, il servait le contenu de wp-log.php. Sinon, il incluait user.php et s’arrêtait.

Le même fichier était déployé dans les cinq dossiers, identique octet pour octet. L’attaquant a utilisé une seule charge utile et une seule règle de décision. Tout le reste n’était que données.

La charge utile pour Googlebot

Les fichiers wp-log.php, malgré l’extension .php, contenaient du HTML pur. Ils étaient énormes, allant d’environ 1,3 Mo à plus de 4 Mo. Chacun était une page HTML complète dans une langue étrangère, en l’occurrence l’indonésien, avec du contenu de spam couvrant les jeux d’argent, le commerce en ligne et le suivi de produits Samsung. Les pages étaient truffées de données structurées, de scripts de suivi tiers intégrés et de liens conçus pour surclasser le contenu légitime sur les mots-clés visés.

Pourquoi l’appeler wp-log.php ? Camouflage. Pour un propriétaire jetant un œil à la liste des fichiers, cela ressemble à un fichier journal de WordPress, pas à une charge utile suspecte.

La charge utile pour humains

Les fichiers user.php étaient de plus petites pages HTML servies aux vrais visiteurs humains. C’étaient des pages satellites (doorway pages) provenant de sites tiers sans rapport, elles aussi déguisées avec une extension .php alors qu’elles ne contenaient aucun code PHP. Quiconque atteignait l’une de ces URL depuis un résultat de recherche, ou naviguait vers /about/ sur le site, voyait un contenu sans aucun rapport avec l’agence.

C’est la partie cloaking. Google voit le spam de jeux d’argent dans le contenu de wp-log.php, le classe sous l’autorité de domaine de l’agence et envoie les vrais utilisateurs vers user.php, qui délivre une expérience satellite totalement différente. La tromperie fonctionne dans les deux sens.

Comment l’attaquant est entré

L’audit forensique n’a pas pu identifier le vecteur d’entrée exact à partir des données disponibles, mais le suspect le plus probable était une extension de gestionnaire de fichiers obsolète, toujours installée et active. La famille d’extensions en question a un long passif de vulnérabilités d’exécution de code à distance, avec de multiples avis publiés au fil des années. Avec un accès en écriture via cette extension, un attaquant peut déposer des fichiers arbitraires n’importe où dans la racine du document.

Point crucial, l’audit a confirmé que le cœur de WordPress, wp-config.php, la base de données et le thème actif étaient tous propres. Aucune porte dérobée dans l’application, aucun utilisateur administrateur pirate, aucun eval PHP obscurci. La compromission se trouvait entièrement dans ces cinq dossiers. C’est ce qui la rendait si discrète. La plupart des scanners de sécurité examinent les fichiers WordPress, pas la racine du document à la recherche de répertoires inattendus.

Pourquoi ce type d’attaque est si dommageable

Les attaques de cloaking SEO nuisent de trois façons. D’abord, le contenu de spam est indexé sous votre domaine, repoussant vos vraies pages vers le bas ou hors des résultats de recherche. Ensuite, Google peut appliquer des pénalités d’action manuelle ou une rétrogradation algorithmique lorsqu’il détecte le cloaking, dont il faut souvent des semaines ou des mois pour se remettre, même après la suppression des fichiers malveillants. Enfin, les scripts tiers et les pixels de suivi intégrés dans les pages de spam peuvent exposer vos visiteurs à des logiciels malveillants ou au phishing.

Le propriétaire d’un site victime de cloaking ne remarque souvent rien jusqu’à ce que le trafic s’effondre ou qu’un client mentionne avoir vu un contenu étrange en cliquant sur un résultat de recherche. À ce moment-là, des semaines ou des mois de dégâts ont déjà été causés.

Comment le détecter sur votre propre site

Quelques vérifications rapides attraperont la plupart des variantes de cette attaque. Consultez votre page d’accueil en tant qu’utilisateur normal. Puis lancez une requête curl depuis un serveur avec un en-tête User-Agent de Googlebot et comparez. Si vous voyez un contenu différent, quelque chose ne va pas.

Vérifiez les rapports Couverture et Performances dans Google Search Console pour repérer des URL indexées que vous ne reconnaissez pas, en particulier celles associées à des requêtes en langue étrangère. Examinez la racine du document via SFTP à la recherche de dossiers ou de fichiers que vous ne pouvez pas expliquer. Lancez une analyse complète des logiciels malveillants avec une extension de sécurité fiable et lisez le rapport au lieu de vous contenter d’effacer les alertes.

Comment le prévenir

La prévention repose sur les mêmes habitudes qui préviennent la plupart des compromissions de WordPress. Maintenez le cœur, les thèmes, les extensions et PHP à jour. Supprimez les extensions que vous n’utilisez pas activement, en particulier les gestionnaires de fichiers et les outils d’accès shell. Bloquez l’exécution de PHP dans les répertoires qui ne devraient jamais contenir de PHP. Auditez la racine du document chaque mois. Utilisez une extension de sécurité qui surveille l’apparition de nouveaux fichiers dans des emplacements inattendus et alerte dès qu’il en apparaît un.

Besoin d’un coup de main ?

Si vous craignez que votre site WordPress héberge du contenu masqué à votre insu, Smart Coding peut mener un audit forensique et vous dire exactement ce qui se trouve sur votre serveur. Si vous voulez un partenaire pour veiller à ce que votre domaine ne se positionne que sur ce qu’il devrait, contactez l’équipe de Defyn.

Avatar de Claire Smith
Sponsored Loved this story? Defyn turns articles like this into the websites your competitors wish they had. Talk to us → defyn.com.au