Tous les piratages de WordPress ne sont pas bruyants. Certains attaquants ne veulent ni d\u00e9figurer votre site ni le prendre en otage. Ils veulent d\u00e9tourner en silence l’autorit\u00e9 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\u00e9taire ignore souvent qu’elles ont lieu.<\/p>\n\n\n\n
Cet article d\u00e9crit exactement comment fonctionne une v\u00e9ritable attaque de cloaking SEO, \u00e0 partir d’une \u00e9tude de cas r\u00e9cente d’une agence de Sydney o\u00f9 chaque fichier et chaque aiguilleur a \u00e9t\u00e9 identifi\u00e9 lors d’un audit forensique. Si vous g\u00e9rez un site WordPress, ce qui suit est le sch\u00e9ma que vous devriez savoir reconna\u00eetre.<\/p>\n\n\n\n
Le cloaking consiste \u00e0 servir aux moteurs de recherche un contenu diff\u00e9rent de celui pr\u00e9sent\u00e9 aux visiteurs humains. Une page peut montrer \u00e0 Googlebot un long article bourr\u00e9 de mots-cl\u00e9s sur des sujets commerciaux sans rapport, tout en affichant \u00e0 un visiteur normal une page d’atterrissage g\u00e9n\u00e9rique ou une redirection. Le but est de tromper les moteurs de recherche pour qu’ils classent le contenu masqu\u00e9 sous l’autorit\u00e9 d’un domaine \u00e9tabli.<\/p>\n\n\n\n
Google a des r\u00e8gles contre cela. Le cloaking enfreint les consignes aux webmasters et peut valoir \u00e0 un domaine des p\u00e9nalit\u00e9s d’action manuelle ou un effondrement complet du classement s’il est d\u00e9tect\u00e9. L’attaquant s’en moque, car le domaine n’est pas le sien.<\/p>\n\n\n\n
Le cas de Sydney utilisait une version particuli\u00e8rement propre de l’attaque. L’attaquant avait cr\u00e9\u00e9 cinq nouveaux r\u00e9pertoires \u00e0 la racine du site, chacun nomm\u00e9 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.<\/p>\n\n\n\n
La raison de nommer les dossiers d’apr\u00e8s de vraies pages \u00e9tait simple. Lorsqu’une requ\u00eate arrivait pour \/about\/ sur le site, le serveur web v\u00e9rifiait d’abord le syst\u00e8me de fichiers. Un dossier nomm\u00e9 about existait, avec un index.php \u00e0 l’int\u00e9rieur. Le serveur web r\u00e9solvait ce fichier avant que le propre routage d’URL de WordPress n’intervienne. Chaque requ\u00eate vers ces URL atteignait le code de l’attaquant plut\u00f4t que la page WordPress l\u00e9gitime.<\/p>\n\n\n\n
Le fichier index.php de chaque dossier \u00e9tait un petit bout de PHP qui ne faisait qu’une seule chose. Il inspectait l’en-t\u00eate HTTP User-Agent de la requ\u00eate entrante et aiguillait en cons\u00e9quence. 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\u00eatait.<\/p>\n\n\n\n
Le m\u00eame fichier \u00e9tait d\u00e9ploy\u00e9 dans les cinq dossiers, identique octet pour octet. L’attaquant a utilis\u00e9 une seule charge utile et une seule r\u00e8gle de d\u00e9cision. Tout le reste n’\u00e9tait que donn\u00e9es.<\/p>\n\n\n\n
Les fichiers wp-log.php, malgr\u00e9 l’extension .php, contenaient du HTML pur. Ils \u00e9taient \u00e9normes, allant d’environ 1,3 Mo \u00e0 plus de 4 Mo. Chacun \u00e9tait une page HTML compl\u00e8te dans une langue \u00e9trang\u00e8re, en l’occurrence l’indon\u00e9sien, avec du contenu de spam couvrant les jeux d’argent, le commerce en ligne et le suivi de produits Samsung. Les pages \u00e9taient truff\u00e9es de donn\u00e9es structur\u00e9es, de scripts de suivi tiers int\u00e9gr\u00e9s et de liens con\u00e7us pour surclasser le contenu l\u00e9gitime sur les mots-cl\u00e9s vis\u00e9s.<\/p>\n\n\n\n
Pourquoi l’appeler wp-log.php ? Camouflage. Pour un propri\u00e9taire jetant un \u0153il \u00e0 la liste des fichiers, cela ressemble \u00e0 un fichier journal de WordPress, pas \u00e0 une charge utile suspecte.<\/p>\n\n\n\n
Les fichiers user.php \u00e9taient de plus petites pages HTML servies aux vrais visiteurs humains. C’\u00e9taient des pages satellites (doorway pages) provenant de sites tiers sans rapport, elles aussi d\u00e9guis\u00e9es avec une extension .php alors qu’elles ne contenaient aucun code PHP. Quiconque atteignait l’une de ces URL depuis un r\u00e9sultat de recherche, ou naviguait vers \/about\/ sur le site, voyait un contenu sans aucun rapport avec l’agence.<\/p>\n\n\n\n
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\u00e9 de domaine de l’agence et envoie les vrais utilisateurs vers user.php, qui d\u00e9livre une exp\u00e9rience satellite totalement diff\u00e9rente. La tromperie fonctionne dans les deux sens.<\/p>\n\n\n\n
L’audit forensique n’a pas pu identifier le vecteur d’entr\u00e9e exact \u00e0 partir des donn\u00e9es disponibles, mais le suspect le plus probable \u00e9tait une extension de gestionnaire de fichiers obsol\u00e8te, toujours install\u00e9e et active. La famille d’extensions en question a un long passif de vuln\u00e9rabilit\u00e9s d’ex\u00e9cution de code \u00e0 distance, avec de multiples avis publi\u00e9s au fil des ann\u00e9es. Avec un acc\u00e8s en \u00e9criture via cette extension, un attaquant peut d\u00e9poser des fichiers arbitraires n’importe o\u00f9 dans la racine du document.<\/p>\n\n\n\n
Point crucial, l’audit a confirm\u00e9 que le c\u0153ur de WordPress, wp-config.php, la base de donn\u00e9es et le th\u00e8me actif \u00e9taient tous propres. Aucune porte d\u00e9rob\u00e9e dans l’application, aucun utilisateur administrateur pirate, aucun eval PHP obscurci. La compromission se trouvait enti\u00e8rement dans ces cinq dossiers. C’est ce qui la rendait si discr\u00e8te. La plupart des scanners de s\u00e9curit\u00e9 examinent les fichiers WordPress, pas la racine du document \u00e0 la recherche de r\u00e9pertoires inattendus.<\/p>\n\n\n\n
Les attaques de cloaking SEO nuisent de trois fa\u00e7ons. D’abord, le contenu de spam est index\u00e9 sous votre domaine, repoussant vos vraies pages vers le bas ou hors des r\u00e9sultats de recherche. Ensuite, Google peut appliquer des p\u00e9nalit\u00e9s d’action manuelle ou une r\u00e9trogradation algorithmique lorsqu’il d\u00e9tecte le cloaking, dont il faut souvent des semaines ou des mois pour se remettre, m\u00eame apr\u00e8s la suppression des fichiers malveillants. Enfin, les scripts tiers et les pixels de suivi int\u00e9gr\u00e9s dans les pages de spam peuvent exposer vos visiteurs \u00e0 des logiciels malveillants ou au phishing.<\/p>\n\n\n\n
Le propri\u00e9taire d’un site victime de cloaking ne remarque souvent rien jusqu’\u00e0 ce que le trafic s’effondre ou qu’un client mentionne avoir vu un contenu \u00e9trange en cliquant sur un r\u00e9sultat de recherche. \u00c0 ce moment-l\u00e0, des semaines ou des mois de d\u00e9g\u00e2ts ont d\u00e9j\u00e0 \u00e9t\u00e9 caus\u00e9s.<\/p>\n\n\n\n
Quelques v\u00e9rifications rapides attraperont la plupart des variantes de cette attaque. Consultez votre page d’accueil en tant qu’utilisateur normal. Puis lancez une requ\u00eate curl depuis un serveur avec un en-t\u00eate User-Agent de Googlebot et comparez. Si vous voyez un contenu diff\u00e9rent, quelque chose ne va pas.<\/p>\n\n\n\n
V\u00e9rifiez les rapports Couverture et Performances dans Google Search Console pour rep\u00e9rer des URL index\u00e9es que vous ne reconnaissez pas, en particulier celles associ\u00e9es \u00e0 des requ\u00eates en langue \u00e9trang\u00e8re. Examinez la racine du document via SFTP \u00e0 la recherche de dossiers ou de fichiers que vous ne pouvez pas expliquer. Lancez une analyse compl\u00e8te des logiciels malveillants avec une extension de s\u00e9curit\u00e9 fiable et lisez le rapport au lieu de vous contenter d’effacer les alertes.<\/p>\n\n\n\n
La pr\u00e9vention repose sur les m\u00eames habitudes qui pr\u00e9viennent la plupart des compromissions de WordPress. Maintenez le c\u0153ur, les th\u00e8mes, les extensions et PHP \u00e0 jour. Supprimez les extensions que vous n’utilisez pas activement, en particulier les gestionnaires de fichiers et les outils d’acc\u00e8s shell. Bloquez l’ex\u00e9cution de PHP dans les r\u00e9pertoires qui ne devraient jamais contenir de PHP. Auditez la racine du document chaque mois. Utilisez une extension de s\u00e9curit\u00e9 qui surveille l’apparition de nouveaux fichiers dans des emplacements inattendus et alerte d\u00e8s qu’il en appara\u00eet un.<\/p>\n\n\n\n