Site WordPress piraté : les 24 premières heures

Le signal arrive rarement par l’entreprise elle-même. C’est un client qui écrit que le site le redirige vers une pharmacie en ligne. C’est Google qui affiche un avertissement rouge avant d’ouvrir la page. C’est l’hébergeur qui suspend le compte pour envoi massif de courriels. Dans les minutes qui suivent, la tentation est de tout effacer et de tout réinstaller, le plus vite possible. C’est la réaction la plus compréhensible, et souvent la plus coûteuse.

Cet essai décrit ce qu’il faut faire, heure par heure, pendant les vingt-quatre premières heures, et ce qu’il ne faut surtout pas faire. Il s’applique à WordPress, qui équipe une large part des sites de PME, mais la séquence vaut pour n’importe quel site. Il ne constitue pas un avis juridique sur la partie Loi 25.

Heure 0 à 1 — Isoler, et préserver les traces

Mettez le site hors ligne ou en mode maintenance. Un site compromis continue d’agir pendant qu’on hésite : il redirige les visiteurs, héberge des pages frauduleuses, envoie du pourriel depuis le serveur. L’arrêter protège les visiteurs et limite l’étendue des dégâts.

Notez l’heure de la découverte et ce qui a été constaté, avec des captures d’écran. Ces éléments serviront à l’hébergeur, au prestataire, et à l’évaluation d’incident que la Loi 25 impose plus loin.

Demandez à l’hébergeur de conserver les journaux d’accès. Ce sont eux qui permettront de savoir par où l’attaquant est entré, quand, et à quoi il a accédé. Sur certains hébergements mutualisés, ces journaux ne sont conservés que quelques jours.

Ne supprimez rien au hasard. Effacer les fichiers suspects dans la première heure détruit précisément les traces dont on aura besoin pour répondre à deux questions : comment c’est arrivé, et quelles données ont été exposées.

Heure 1 à 4 — Couper tous les accès

L’attaquant est peut-être encore là. Tant qu’il garde un accès, tout ce qui suit est inutile.

1. Changez tous les mots de passe, sans exception : comptes administrateurs du site, compte de l’hébergeur, base de données, accès FTP ou SFTP, compte courriel associé au site.
2. Passez en revue les comptes administrateurs. Un compte inconnu, créé récemment, est la signature la plus fréquente d’une intrusion. Supprimez-le, mais notez d’abord son nom et sa date de création.
3. Renouvelez les clés de sécurité de WordPress dans le fichier de configuration. Cela invalide toutes les sessions ouvertes, y compris celles de l’attaquant.
4. Activez l’authentification à deux facteurs sur l’hébergeur et sur l’administration du site.

Si personne dans l’entreprise n’a ces accès, le problème est antérieur au piratage. La démarche pour les récupérer est décrite dans l’essai sur la reprise d’un site dont le webmestre a disparu.

Heure 4 à 12 — Restaurer plutôt que nettoyer

Un nettoyage retire ce qu’on voit. Une restauration propre retire aussi ce qu’on ne voit pas.

Les intrusions laissent presque toujours des accès dérobés discrets : un fichier au nom anodin dans un répertoire d’extensions, une tâche planifiée qui réinstalle le code malveillant, un utilisateur caché. Un nettoyage manuel qui retire les symptômes visibles laisse souvent ces portes ouvertes, et le site est réinfecté quelques jours plus tard.

La bonne séquence est la restauration d’une sauvegarde antérieure à l’intrusion, fichiers et base de données, suivie immédiatement de trois gestes :

• mettre à jour le cœur de WordPress, le thème et toutes les extensions ;
• supprimer les extensions désactivées ou abandonnées par leur auteur, qui restent exploitables même désactivées ;
• vérifier qu’aucun compte administrateur inconnu n’est revenu avec la sauvegarde.

Encore faut-il identifier la date de l’intrusion pour choisir la bonne sauvegarde, d’où l’importance des journaux préservés à la première heure. Et encore faut-il qu’une sauvegarde saine existe, hors de l’hébergement compromis. Le nettoyage n’est la bonne option que lorsqu’il n’y en a pas.

La porte d’entrée est le plus souvent connue d’avance : une extension ou un thème qui n’était plus à jour. L’arbitrage entre les mises à jour urgentes et celles qui peuvent attendre fait l’objet d’un essai dédié.

Heure 12 à 24 — La question que la Loi 25 impose

Une fois le site rétabli, une question reste ouverte, et elle n’est pas technique : l’attaquant a-t-il pu accéder à des renseignements personnels ?

Un site de PME en contient souvent plus qu’on ne le pense. Les demandes reçues par le formulaire de contact, parfois conservées dans la base de données. Les comptes clients et l’historique des commandes d’une boutique. La liste des abonnés à l’infolettre. Les candidatures reçues par une page carrière.

La loi définit l’incident de confidentialité comme tout accès non autorisé à un renseignement personnel, toute utilisation ou communication non autorisée, ou sa perte¹. Un attaquant qui a eu accès à la base de données d’un site qui stocke les demandes de formulaire a eu accès à ces demandes. Dès lors, trois obligations s’enchaînent.

Prendre des mesures raisonnables pour diminuer les risques de préjudice et éviter qu’un incident semblable se reproduise. Les étapes précédentes en font partie.

Consigner l’incident dans le registre des incidents de confidentialité, qu’il présente ou non un risque de préjudice sérieux. Le registre doit être conservé au moins cinq ans après la découverte de l’incident, et communiqué à la Commission sur demande.

Évaluer le risque de préjudice sérieux, selon trois facteurs : la sensibilité des renseignements, les conséquences appréhendées de leur utilisation, et la probabilité qu’ils soient utilisés à des fins préjudiciables. Des noms et des adresses courriel ne pèsent pas comme des numéros d’assurance sociale ou des renseignements de santé. Le préjudice n’a pas à s’être produit ; il suffit qu’il soit susceptible de se produire.

Si le risque est sérieux, l’entreprise doit aviser avec diligence la Commission d’accès à l’information et les personnes concernées. La Commission publie un formulaire de déclaration à cet effet². Les obligations générales du site au regard de la loi sont détaillées dans l’essai consacré à la Loi 25.

Après les 24 heures

Deux dernières tâches ferment l’incident.

Du côté de Google, si des pages frauduleuses ont été indexées ou si un avertissement de sécurité s’affiche, la Search Console signale le problème dans sa section consacrée à la sécurité. Une fois le site assaini, on y demande un réexamen. Les pages de pourriel créées par l’attaquant doivent renvoyer une erreur, pour sortir de l’index.

Du côté de l’entreprise, la question utile n’est pas « qui est responsable », mais « qu’est-ce qui aurait empêché ça ». La réponse tient presque toujours en trois lignes : des mises à jour appliquées, une sauvegarde hors de l’hébergement dont on a vérifié la restauration, et quelqu’un dont c’est le travail de surveiller le site. C’est exactement le contenu d’un contrat de maintenance, qui coûte moins cher qu’une seule de ces journées.

---

Footnotes

1. Commission d’accès à l’information du Québec, Incidents de confidentialité et mesures de sécurité : cai.gouv.qc.ca. Cet essai ne constitue pas un avis juridique. ↩

2. Commission d’accès à l’information du Québec, Formulaire de déclaration d’un incident de confidentialité : cai.gouv.qc.ca. ↩