Joomla piraté : comment diagnostiquer les problèmes et les résoudre ?

Cet article concerne particulièrement le Google Results Defacing, ou comment résoudre le problème des résultats de recherche Google détournés au profit de sites tiers malveillants...

Quand votre identité numérique est volée au profit de hackers peu regardants...

Sommaire

1. Avant-propos sur Joomla!
2. Découverte du problème...
3. Qu'est-ce qui se passe ? Le diagnostic du problème...
4. Premiers réflexes...
5. Premières actions pour limiter les dégâts...
6. Trouver la source du problème...
7. Traitement du second cas : Les "liens de menu" détournés
8. Traitement du second cas : La balise "titre" détournée
9. Invoquer Google pour rafraîchir le référencement du site
10. En résumé...

#1. Joomla is free
#2. Joomla already includes the most common features
#3. Joomla Extensions Directory
#4. Joomla is supported by volunteers
#5. Joomla is international
#6. Joomla is well coded
Conclusion : Socially and technically this is the best software to build the future of the web.

Valentín García - Article"6 reasons why Joomla! is the best CMS"

Joomla!

Je suis assez friand du CMS grand public Joomla! et je le mets en œuvre pour moi-même et quelques clients depuis plusieurs années (depuis la version 1.5…) et je le trouve personnellement bien plus puissant que son plus célèbre concurrent Wordpress (30% de part de marché en 2018, soit environ 19 millions de site, contre 2,5 pour Joomla!)… Mais c'est surtout une histoire de goût et d'expériences personnelles, et d'habitudes....

Au fil du temps, j'ai pu apprécier ses atouts, sa simplicité d'usage au quotidien et la clarté de son interface administrateur bien plus précise et commode que celle de son rival (même si ce point est à relativiser bien évidemment)… et découvrir aussi ses faiblesses… Eh oui, victime de sa popularité, comme ses concurrents les plus utilisés, Joomla tombe assez régulièrement sous les coups de boutoir des hackers qui s'amusent à montrer leurs compétences en prenant la main sur leur administration et leur fonctionnement. C'est de bonne guerre et crée de l'émulation pour avancer : finalement, le piratage est une bonne chose… sauf pour ceux qui le subissent de plein fouet !

Un type particulier de piratage de votre site Joomla!

Je prendrai le cas particulier du Google Results Defacing... Bon, ce terme n'existe pas encore, mais c'est le meilleur que j'ai trouvé pour décrire le problème rencontré… En gros, il signifie "affichage de résultats de recherche détourné". Concrètement, dans le rendu des termes SEO retournés par la page de résultat Google, on remarque bien que les infos retournées ne correspondent plus du tout à votre propre contenu normalement mis en ligne… En gros, le résultat des votre site est volontairement détourné pour faire le promotion d'un site tiers, avec lequel vous n'avez aucun rapport : l'angoisse ! Le résultat est grossier mais il vous ruine immédiatement votre réputation… D'autant plus que les infos retournée ne renvoient pas au site malveillant désigné (il n'y a pas de lien réellement activés). Heureusement, désormais Google a bien bien repéré le problème, mais il ne peut pas y remédier tout seul…

Des liens de menus (sitelinks) renvoyant vers l'achat de produits exotiques...

Là, c'est carrément le "Titre" du site qui est détourné... Google fait une alerte, bien justifiée...

Là, on a vraiment un gros problème, et Google est de la partie... Et on se doute que ça ne va pas être simple...

Je tiens à préciser que je ne suis pas expert en sécurité réseaux, ni développeur, ni hacker du coup. Cet article vise simplement à vous faire prendre conscience des risques inhérents à l'utilisation d'un CMS comme Joomla! et à vous montrer comment réagir dans le cas de ce type de piratage - et des autres similaires - et comment remettre votre site d'aplomb sans avoir besoin de faire appel à un pro qui vous facturera la plupart du temps au prix fort car vous êtes dans l'urgence et que vous ne comprenez pas la mécanique mise en œuvre dans votre problème...

Découvert et diagnostic du problème...

Dans le premier cas, on voit que ce sont les liens du menu de navigation qui sont impactés et détournés... OK.

Dans le second cas, c'est la balise "Titre" de description du site site qui est modifié : OK...

Bon, on se rend immédiatement dans l'administration du Joomla pour voir ce qui s'est passé... et évidemment, on ne voit rien de spécial...

Dans le cas d'un hébergement sur des serveurs mutualisés (OVH, 1and1, Amen, LWS...), ces hébergeurs sont bien sécurisés et disposent d'outils d'analyse et d'alerte permettant de bloquer certains comportements suspects issus du fonctionnement de votre site. Ici, c'est plus insidieux car ce n'est pas le fonctionnement du site qui est en cause, mais bien la manière dont il est référencé, et plus précisément dans la manière dont le Google le voit, ou l'interprète...

Dans le cas du second site piraté, ce n'est pas tant ce que VOUS voyez sur le site qui compte - car d'ailleurs on ne remarque rien de spécial quand on le visite, ni dans l'affichage visible de la page, que dans le code source... - que ce que Google voit via ses robots indexeurs... Et là, c'est le drame... et c'est bien cela qui remonte de manière automatique dans les résultats de recherche...

Voilà la page "visible" pour Google, celle que l'on trouve en l'état dans le cache, en encore, là, ce n'est que le haut de page...
Cliquez dessus pour voir l'étendue des dégâts...

De l'importance d'un hébergement de qualité

On ne le répètera jamais mais on ne fera jamais d'économie en choisissant un hébergement bas de gamme chez des prestataires qui proposeront certes des prix attractifs mais qui se révèleront à longue incapable d'assurer le sécurité de leur infrastructures et de monitorer efficacement les problème de piratage. 1and1 ou OVH par exemple peuvent réagir rapidement en cas d'attaque - en allant jusqu'à bloquer votre site ! - et même préciser le nom du ou des fichiers infectés qui pose(nt) problème... Ce n'est pas un luxe et cela a un prix, bien évidemment

Le message d'alerte de 1and1 indiquant la détection d'un fichier malveillant sur votre site...

De l'importance d'utiliser des outils capables de vous alerter en cas de la survenue de problème sur votre site

Google fait son job avec son service Google Search qui permet de lui donner accès aux données de trafic de votre site et qui réagit bien en cas d'activité anormale. C'est lui qui a alerté le client : mais encore fallait-il qu'il consulte ses mails pour le savoir...

Le message d'alerte de Google Search indiquant la présence suspecte d'un nouveau fichier activé sur votre site...

Premiers réflexes...

On sait que le site a été piraté... Si, comme dans nos cas présentés ici, l'admin est toujours active, on se dépêche de mettre le site en "mode maintenance" pour suspendre temporairement le problème pour vos visiteurs... et stopper le compteur de stats du site qui profite incidemment de votre détournement...

On regarde dans ses archives pour retrouver la dernière version de sauvegarde du site mis en ligne... Si vous n'en avez pas, vous pouvez solliciter votre hébergeur pour soit faire une restauration de fichiers à une date antérieur (bof...) mais surtout pour demander une copie de la sauvegarde la plus récente, et plus ancienne si possible. Bon, je sais, à ce stade, vous ne savez pas quand votre site a été piraté mais vous pouvez déjà faire la démarche pour vérifier si votre compte permet ce type de demande et pour voir comment cela se passe...

Généralement, votre hébergement de base ne propose pas ce service et c'est donc une bonne manière de comprendre pour vous - ou votre prestataire webmaster - que les sauvegardes sont essentielles car souvent les effets du piratage de votre site peut prendre plusieurs jours, voire plusieurs semaines, avant d'être visibles et impactants...

Pensez aussi du coup à vérifier votre base de données et ses sauvegardes : dans le cas d'un site piraté par des processus de mail bombing, sa taille croît de manière anormal de manière continue (1and1 par exemple vous alerte dans ce cas en indiquant que le site enregistre un nombre anormal d'enregistrements d'envoi de mail... après avoir suspendu le service).

1and vous alerte en cas d'activités anormales sur site, et notamment pour l'envoi massif de mails...

Premières actions pour limiter les dégâts...

On est dans l'urgence et on ne sait pas ce qui s'est passé... Est-ce un piratage à l'aveugle, des robots qui ont pu investir votre site d'une manière ou d'une autre ? Vos infos confidentielles (code d'accès ftp, compte de votre compte client chez votre hébergeur, votre propre ordinateur...) ont peut-être été récupérés et utilisés...

01 - Changez vos identifiant et mot de passe de Joomla!

Retrouvez ce codes et commencez par modifier votre identifiants et mot de passe de votre CMS Joomla : ce sera l'occasion de voir s'ils n'ont pas déjà été modifié (mais vous le savez déjà si vous avez suivi l'étape précisée juste avant...).

02 - Changez vos identifiant et mot de passe de votre compte d'hébergement !

03 - Changez vos identifiant et mot de passe de votre base de données SQL !

Oui, je sais, c'est lourd... mais au moins cela de voir si c'est l'un de ces comptes qui a été piraté, volé ou cracké... Et de repartir sur de bonnes bases pour la suite, et plus sereinement

Comment trouver la source du problème ?

Comme je n'ai rien vu dans l'admin, c'est donc ailleurs que je dois chercher... et donc dans les innombrables fichiers du Joomla que je vais devoir chercher la source du problème... Et des fichiers dans le Joomla, il y en a des milliers !

On se tourne donc alors vers l'arborescence du site via son Dreamweaver ou son client FTP pour voir ce qu'il se passe en ligne sur le serveur d'hébergement...

Et on se doute bien que ce sont les fichiers eux-mêmes (plus rarement la base de données SQL) qui ont été tripotés d'une manière ou d'une autre : soit des fichiers importés par contrebande, soit les fichiers eux-mêmes qui ont été modifiés ou réécrits pour y mettre quelque chose de plus... Oui, c'est ça le terme : un script malveillant !

Mais comment et où le trouver ?

On peut commencer par un truc tout simple pour voir si quelqu'un, ou quelque chose à bien piraté votre site en faisant une simple recherche dans les fichiers du site sur le terme "hacked"... et on a rapidement trouvé un fichier "txt" avec la signature du pirate car ce sont des gens qui aime bien la publicité - sous un pseudo bien évidemment - et qu'il signent pas conséquence souvent leur crime !

Pour le premier cas, on a trouve "Hacked By MuhmadEmad" dans un fichier texte tout simple ("1998.txt").

Le second dans l'une des variables d'un des fichiers PHP infecté : else{echo "Uploader By Psyco!";}

Bon, donc le site a bien été visité et piraté en son sien : on peut passer aux choses sérieuses...

1^ère méthode : La date des fichiers

La première méthode est la plus simple, mais elle peut s'avérer vite fastidieuse (si on ne touche pas sa bille en lignes de commande via SSH...). Oui, le fichier ajouté dans l'arborescence du Joomla, ou celui modifié, doit dans la majorité des cas indiquer une date de création ou de modification différente de celle des autres fichiers statiques (oui, il y a des fichiers qui eux changent et sont modifiés en permanence comme les fichiers de cache ou les fichiers de logs... et en fonction aussi des autres surcouches utilisés pour votre Joomla comme les Frameworks T3 ou Sparky...).

On regarde donc scrupuleusement les dates des fichiers dans le schéma d'arborescence via votre client FTP :

Ici, les fichiers du répertoire des modules... tout est OK et colle avec la date de déploiement officiel du site

Ici, Bingo ! La date des fichiers est plus récente... Trop d'ailleurs, surtout si vous n'avez pas fait de mise à jour du CMS ou des contenus...

Cette méthode est la plus simple, mais elle demande une attention visuelle qui n 'est pas toujours évidente et surtout elle vous demandera de scruter TOUS les fichiers à l'intérieur de TOUS les répertoires... Y'en a pour plusieurs minutes et cela n'est pas toujours pertinent car de nombreux fichiers sont ajoutés ou modifiés régulièrement lors du fonctionnement normal de votre Joomla, et notamment les fichiers de logs, errors, cache... et d'autres en fonction de l'architecture de votre site (upload de pièce jointe de formulaire, fichier de compilation CSS, fichiers JS dynamiques...)

2^de méthode : Rechercher des fichiers au nom "exotique"

Pour la première méthode, on regardait les fichiers distants, ceux qui sont en ligne et actifs : ceux qui fonctionnent une fois le visiteur arrivé pour consulter vos pages...

Là, on va devoir plutôt rapatrier tous les fichiers du site, en local, pour mieux les examiner... Si vous avez déjà une version du site, vous la mettez de côté, pour archivage, et au pire, pour comparaison...

On lance son client FTP - en ayant auparavant créé un répertoire/dossier vide - et on récupère tout à cet endroit. Il faut qu'il reçoivent TOUS vos fichiers transférés...

NB : la plupart du temps, cette manip redonne une nouvelle date à vos fichiers (celle du jour, heure et seconde du fichier récupéré), ce qui rend caduque la méthode de détection des fichiers malveillants précédente (par date)...

Première remarque

Si votre logiciel anti-virus est assez puissant et malin, il vous indiquera qu'il a rencontré un fichier malveillant lors du transfert : ça, c'est cool ! Mais, si c'est le cas, passez outre cette alerte pour valider son acquisition en prenant bien soin de noter son nom, et son emplacement (son chemin dans l'arborescence du site).

Une fois fait, nous allons pouvoir disséquer l'objet de nos inquiétudes... On fait une recherche au hasard sur des termes précis... On peut commencer sur le nom des fichiers par exemple... Le type d'injection de fichier malveillant se caractérise par leur nommage "exotique" : effectivement, générés de manière aléatoire, on peut les repérer assez facilement, lors de l'examen visuel : "x.php", "test49.php", "view35.php", "functions60.php", "b3z5fy.php"...

Mais attention, cela n'est pas satisfaisant car des fichiers nommés "c.php", ou "empty.php"sont des fichiers réguliers et même obligatoires pour votre Joomla... Surtout, ces fichiers peuvent se retrouver implantés à peu près n'importe où dans l'architecture de votre site... Donc, on peut faire un examen visuel rapide pour voir si on en trouve mais cela ne peut rester que superficiel...

Il est intéressant quand même de faire cette recherche empirique juste pour voir si vous n'en trouvez pas 20 en quelques minutes... Et surtout pour voir, si vous en trouvez un, de regarder ce que renferme ce fichier et découvrir le type d'infection qu'il provoque, comme ceux-ci :

Voilà, on y est... C'est d'la bonne, enfin, bon, ç'est du rustique, mais c'est déjà assez efficace pour vous flinguer un Joomla...

Là, on est pas mal ! On a trouvé le source du problème, en tout cas dans le cas d'un Hack classique de Joomla... Oui, ces fichiers renferment des lignes de code utilisant du "encrypt", du "encode", "64_decode", du "$GLOBAL",... bref des directives et des variables PHP classiques que tout bon développeur maîtrise et peut mettre en œuvre, et qui suffisent à prendre la main sur votre site, plus ou moins insidieusement, et surtout de manière entièrement automatique pour lui faire faire des choses que l'on ne souhaite bien.

NB : Souvent, ces fichiers sont inopérants car mal écrits ou mal implémentés et se retrouve donc inactif... Il n'empêche qu'ils sont bien là, montrant qu'une faille de sécurité qui a été exploitée, ce qui n'est pas rassurant pour la suite...

Seconde remarque

Dans ce cas, il vous suffit de faire une recherche sur ces termes ("encrypt", "$GLOBAL" et surtout le "64_decode"...) pour repérer vos fichiers infectés... Et normalement, ce sera la révélation !

Attention cependant, d'autres fichiers réguliers utilisent ces "$GLOBAL" et surtout le "64_decode", et il faut donc faire des comparaisons avec vos fichiers archivés - si vous les avez - pour vérifier et valider leur nocivité...

Traitement du premier cas : Les "liens de menu" détournés

Ce premier type de piratage est assez incongru mais de toute façon catastrophique :

Des liens de menus (sitelinks) renvoyant vers l'achat de produits exotiques...

Ici, ce sont les liens du menu principal de navigation qui ont été détournés... mais ils ne sont pas activés... c'est un moindre mal mais c'est quand gênant et même catastrophique pour l'image et la crédibilité de l'entreprise...

Dans ce cas, nous avons commencé par regarder le code source sans rien y voir de spécial même si Google ne voit en l'occurrence pas la même chose que nous.

D'ailleurs, Google a bien fait son job en fait - via son service Google Search - car c'est lui qui a alerté le client : mais encore fallait-il consulter ses mails pour le savoir ! Google n'est pas le seul a générer ce type d'alerte et 1and1 ou OVH par exemple peuvent réagir aussi en cas d'attaque et même préciser le nom du fichier infecté qui pose problème..

Le message d'alerte de Google Search...

Puis nous sommes allé voir dans l'administration du Joomla, dans les Modules et les Plug-ins... mais rien de spécial non plus n'est apparu...

Puis, après avoir récupérer les fichiers du site - en ayant mis de côté la dernière version que vous aviez en local sur votre poste - on fait une recherche anodine sur le terme "hacked"... et on a rapidement trouvé un fichier "txt" avec la signature du pirate "Hacked By MuhmadEmad". Bon, c'est déjà pas mal... On a pu voir du coup la date du jour où tout s'est produit...

On pourrait alors regarder visuellement toute l'arborescence du site visuellement mais c'est trop fastidieux : on oublie cette méthode même si elle peut se révéler riche en enseignement via les dates des répertoires et des fichiers... et si vous avez un utilitaire pour effectuer des recherche par ce critère de dates...

Dans notre cas, une recherche à "64_decode" a suffit trouver rapidement des fichiers infectés :

Ça, c'est déjà assez efficace pour vous flinguer un Joomla...

Mais dans ce cas, aussi, il y en avait d'autres qui ne contenaient pas cette instruction...

Là, par contre, on a droit à un peu de tout...

On est donc obligé de revisiter toute l'arborescence du site, et testant d'autres types de variables critiques, ou tout simplement en scannant le site via un logiciel anti-virus...

En combinant plusieurs méthodes, empiriques et automatiques, on peut généralement trouver et supprimer les fichiers et les scripts malveillant !

Traitement du second cas : La balise "titre" détournée

Ce second type de piratage et de détournement concerne donc le renommage de la balise de "Titre" de votre site internet via les résultats fournis par Google !

01 - Éradiquer la source du problème

On a regardé le code source en ligne et là c'est l'angoisse car on ne voit rien de particulier dans le code source restitué !

Là, c'est carrément flippant... mais sachez que beaucoup de choses sont flippant sur le net et que là, c'est carrément magique ! C'est regardant dans la page conservée en cache par Google que l'on voit toute l'étendue des dégâts : on y retrouve directement les contenus d'un autre site web complètement incrusté dans ma propre page d'accueil... En même, en faisant une recherche sur les autres pages en cache enregistrées, on voit que ce sont TOUTES les pages du site qui ont été infestées, et que même d'autres pages sont générées automatiquement et référencées : et elles sont des milliers ! La loose, quoi !

Ce que vous voyez dans le code source en haut, et ce que voit et restitue Google dans ses résultats de recherche...
カルビ丼のたれ 2kg【日本食研】【業務用】 Ici, du japonais… Bol de riz salé 2 kg [Nippon Shoken] [pour usage professionnel]

Le pirate se sert de votre site pour générer artificiellement du trafic vers des produits qu'il promotionne et pour lequel il est rémunéré d'une manière ou une autre...

C'est évidemment une catastrophe : et voilà comment traiter le problème...

C'est avec - mauvaise - surprise que l'on a repéré dès le départ un nouveau fichier "google1adfa2ebabbe531e.html" à la racine du site... C'est un fichier de validation de site Google, qui permet de permettre l'exploration du site par les bots de Google et de générer des audits (via son service Google Search) et des stats (via son service Google Analytics).

On a repéré dans l'arborescence du site l'endroit où se trouve la source de l'infection : c'est le répertoire "mod_tags_cloudbt"... On voit bien que sa date diffère de celles de autres répertoires et qu'elle colle avec le commencement des problèmes...En faisant quelques recherches sur le net, on trouve bien des mentions à un module nommé"mod_tags_cloud", mais pas le nôtre spécifiquement...

Ici, le répertoire du module "mod_tags_cloudbt" piraté vue via le client FTP...

Même si l'on voit qu'il n'est pas activé ("publié"), on serait tenté de le supprimer directement... mais ce serait un peu hâtif : on ne sait pas immédiatement si ce module est "indépendant" et s'il n'est pas relié à d'autres fonctionnalités réparties ailleurs dans l'arborescence du site... De toute façon, il est certainement présent dans l'un des champs de la base de données...

Là, le module piraté vue dans le panneau d'administration...

NB : Autre indice, on voit que ce module montre un nommage particulier avec ses "_"... Et si on clique sur ce module, on remarque aussi que les expressions de traduction ne sont pas traduites : "MOD_SEARCH_XML_DESCRIPTION", "MOD_SEARCH_FIELD_LABEL_TEXT_LABEL"...

On supprime alors le module directement depuis le panneau d'administration !

On clique sur le petit menu contextuel "Statut" à gauche du nom du module et clique sur "Corbeille"...

On doit alors allez dans la colonne du menu de droit pour -"Sélectionner un statut" -... et on clique sur "Corbeille"...

On voit alors le module dans la liste... On le sélectionne en cochant la case... et on remonte en haut pour cliquer sur le bouton "Vider la corbeille" !

Apparaît alors un message dans un cadre vert : "Message 1 - module supprimé avec succès"

Et l'on ressent un petit soulagement ! Mais ce n'est pas fini !

Eh oui, si on retourne sur le FTP et l'arborescence du site, on voit que le répertoire existe toujours... et les fichiers nocifs aussi ! Ah !

Par contre, le champ de la base de données a bien été supprimé... Quand même !

Là, on s'embête pas, on supprime tous les fichiers pourris directement !

Ici, via Filezilla, on supprime définitivement le répertoire incriminé !

Là, on pense que c'est définitivement fait, ce qui est loin d'être le cas !

Pour la cause du piratage, elle sont multiples mais la première est le fait que le Joomla n'était pas à jour et qu'avec le temps, la faille potentielle a bien été trouvée et exploitée par des petits malins...

Ici, c'est un module qui est le point de passage par lequel le piratage s'est produit. Maintenant, la porte d'entrée - backdoor - est fermée, et même supprimée...

Il est connu que les points faibles des CMS et donc de Joomla sont des modules - ou extensions - qui sont vulnérables et en tout premier lieu les "portes ouvertes" qui se trouvent sur en front site comme les formulaires de contact ou les modules de recherche... La technique la plus connue et la plus néfaste - au-delà des simples techniques de spamming automatiques qui font déborder vos boîtes mail - est l'injection de code...

L'autre source du problème, qui très connue et bien documentée, sont les modules d'édition de contenus WYSIWYG natif de Joomla dont Tiny MCE (présentant déjàce type de piratage en 2009...).

Évidemment, si vous utilisez des Frameworks ou des modules complémentaires, vous multipliez les risques de piratages...

02 - Nettoyer le site infecté

On avait fait des recherches sur des fonction PHP et cela s'était avéré concluant mais pas suffisant. On aurait déjà pu faire une première recherche sur les caractères japonais - et chinois - qui surchargent les pages en contenus indésirable : ici, c'est facile ! Dans le répertoire de votre site, on recherche par exemple le caractère "中"... Et là, bingo !

J'ai retrouvé non seulement le fichier infectant mais aussi ses petits copains dans un répertoire nommé "managera"... qui effectivement montre les bonnes dates de modification...

J'ai aussi trouvé un autre fichier au format html lui qui m'a permis de mieux de comprendre la mécanique du détournement... Sans entrer dans les détails - qui me dépassent car je ne suis par un développeur -, on peut voir que c'est une mécanique de remplacement de code source via une technique de formatage de type Smarty qui est en œuvre : des variables sont injectées via des shortcodes présent dans la page html et qui se substituent à certaines données présentes dans la page normale... Je vous l'ai dit, c'est magique !

Évidemment, on s'empresse de supprimer ce répertoire !

Ici, les différents aspects de ce hacking très vicieux sont vraiment flippants :

• Il a installé un module "mod_tags_cloudbt" qui n'avait pas été voulu par l'administrateur
• Il a installé un répertoire"managera" contenant les instructions orientant l'affichage du contenu (en fonction du statut de l'utilisateur User-Agent, d'un visiteur des fichiers du site : homme ou bot)
• Il contient des instructions détectant le User-Agent pour montrer ce qu'il veut : votre navigateur = une page normale / un bot indexeur Google = la page détournée
• Il a installé un fichier d'identification de site Google à la racine du site pour permettre son exploration par les robots indexeurs de Google
• Il a ensuite créé un fichier sitemap - arborescence du site au format xml - contenant ici plus de 8800 entrées (pages) dont la grande majorité ne sont pas voulues
• Il a ensuite invoqué les bots Google pour référencer toutes ces pages virtuelles
• En bonus, il contient aussi un mapping de votre URL qui masque une URL de destination pour montrer la publicité indésirable...

Bref, des milliers de pages créées artificiellement - que l'on peut voir dans le fichier sitemap lui-même impacté par cette mécanique - et des pages qui sont bien référencées infine par Google Search...

Invoquer Google pour rafraîchir le référencement du site

Il vous faut bien sûr un compte Google !

Vous avez bien évidemment un compte Google... que vous avez activé au moins pour recueillir des stats via son service Google Analytics. Du coup, il vous faut y revenir pour activer le service complémentaire qui vous permet d'auditer et surtout de "piloter" de manière assez simple la manière dont Google travaille pour analyser le contenu de votre site et l'indexer de manière efficace pour le rendre accessible aux réponses des internautes lorsqu'il font une recherche Google...

Si nous avions regardé de plus près cet outil puissant de monitoring Google, nous aurions été alerté très rapidement de la survenue d'un problème sur le site...

Tous les messages et les alertes sont visibles dans la partie "Messages" de Search Console

Et surtout, qu'un invité non prévu s'est rendu maître de certaines fonctionnalités de mon compte en activant le droit d'accès au site via un fichier de validation :

Tiens, le voilà donc mon pirate ! Mister ...

Regénérer un fichier Sitemap propre pour la nouvelle indexation

Le site est nettoyé de ses fichiers infectés... On demande donc de générer un nouvel audit du fichier sitemap sur le site via des outils comme le module OSMap Free que j'utilise depuis longtemps... Une fois activée, c'est ce fichier sitemap au format xml qui sera soumis à Google pour lui demander de réindexer le contenu du site :

On active les fonctions d'audit et de validation du site via Google Search

Et ici, via son service Google Search, on demande à Google de faire repasser ses bots indexeurs sur toutes les pages du site :

Eh voilà... le processus est lancé... Google va lancer ses bots rapidement et explorer de nouveau le site et toutes ses ramification internes. On peut aussi lui indiquer directement via un formulaire que l'on a traité le problème pour accélérer les choses (oui, on peut dompter Google, parfois...).

Vous verrez alors rapidement dans vos fichiers de logs les requêtes venant de Google qui vont croître de manière parfois ahurissantes ! (oui, dans la base de données les sessions explosent, et dans le module "Redirections de liens" de Joomla, vous verrez les erreurs s'accumuler...).

Et on surveille tout ça !

Vérifiez régulièrement ce qui se passe dans Google Search, et si tout se déroule bien, vous verrez votre notoriété sur Google revenir à la normale après quelques jours d'attente...

En résumé...

Mettre systématiquement à jour votre site Joomla!

Toujours suivre les instructions de mise à jour des versions Joomla pour ne pas rompre la fiabilité et la sécurité de votre site !

Oui, c'est la moindre des choses et j'ai souvent du mal à faire comprendre à mes clients et mes amis pour qui je travaille que c'est la première chose à faire, presque même avant l'ajout de nouveaux contenus sur votre site. Je sais que c'est pénible : copier en local la version actuelle en ligne (enfin, le transfert des fichiers se fait automatiquement une fois lancée...) et sauvegarder la base de données (ce qui demande quand même un peu de connaissance pour accéder et exporter la BDD) mais une fois fait, vous verrez que ces opérations sont simples et rapides...

Il en va de même d'ailleurs des mises à jour des plug-in et des modules de Joomla du site qui sont bien évidemment - après ce que je viens d'exposer ici - plus urgentes que les MAJ des simples fichiers de langue...

Quand faire ces mises à jour ?

Joomla est bien fait pour ses administrateurs et des alertes automatiques apparaissent directement lorsque vous vous connecter à votre admin lors de la diffusion des MAJ :

Astuce :

Vous pouvez demander à recevoir une notification par mail en activant le plug-in dédié :

A vous de jouer !

En suivant les directives listées ci-dessus, vous pourrez résoudre votre problème de piratage en quelques heures (en tout cas ceux de ce type)... et rétablir votre notoriété sur Google après quelques jours d'attente, et auprès de vos clients !

Infos spécifiques à Joomla :

Les sites officiels de Joomla : www.joomla.org (en.) / www.joomla.fr (fr.)
Le blog dédié à la sécurité de Joomla : www.joomla.org (en.) /www.joomla.fr (fr.)
Les Release - mises à jour - officielles : www.joomla.org/announcements/release-news.html (en.)

Des exemples de failles de sécurité Joomla :

https://www.joomla.fr/actualites/joomla-3-4-6-est-disponible-mise-a-jour-de-securite-critique (fr.)
https://blog.ripstech.com/2017/joomla-takeover-in-20-seconds-with-ldap-injection-cve-2017-14596/ (en.)

Des infos de Google pour comprendre et régler le problème :

https://support.google.com/webmasters/answer/9044101?visit_id=638041365562362426-1042826439&rd=1#hacked-url-injection&zippy=%2Cpiratage-injection-durl (fr.)
https://developers.google.com/web/fundamentals/security/hacked/clean_site (en.)
http://www.arobasenet.com/2018/03/relancer-indexation-google-4511.html (fr.)

Des infos pour auditer et sécuriser votre site web :

5 outils en ligne pour tester la sécurité d'un site web (fr.)
https://www.nosyweb.fr/astuce-joomla/comment-securiser-et-proteger-joomla-3-contre-les-hackers.html (fr.)
https://blog.sucuri.net/2015/12/remote-command-execution-vulnerability-in-joomla.html (en.)

Erwan Corre - Septembre 2020