De la sécurité des extensions selon WordPress

WordPress

Encore un coup de gueule, j’aimerais bien de temps en temps remplir un peu plus souvent les autres catégories que celle-là sous peine finalement de passer pour un éternel râleur (même si je le suis quand même un peu).

Depuis quelque temps sur ce site présentait un défaut, le texte des articles, ne s’affichait plus, ce qui sur le principe ne facilite pas la lecture. Je décidai donc de prendre le problème à bras le corps, prodiguant à moi-même les (bons) conseils que je donne aux autres sur le forum de support francophone WordPress. J’identifie assez rapidement l’extension à l’origine du problème et là, je me rends compte, par hasard, d’une petite subtilité.

Dans la page de gestion des extensions, au niveau de l’extension en question, je n’ai pas la mention « Afficher les détails » mais « Aller sur le site de l’extension » qui pointe sur une page 404. Pour ceux qui ne le sauraient, « Afficher les détails », permet, comme son nom l’indique d’aller sur le dépôt officiel WordPress des extensions pour obtenir des informations. Logiquement, lorsque vous achetez une extension sur un site quelconque, comme elle n’est pas dans le dépôt officiel WordPress, on vous propose d’« Aller sur le site de l’extension ». Sauf que… Toutes mes extensions proviennent du dépôt officiel WordPress, je n’en prends pas ailleurs. Vous commencez à voir où je veux en venir…

Donc en clair, on retire du site WordPress une extension – généralement il faut une bonne raison comme une faille de sécurité non corrigée et après vérification c’est bien le cas – vous n’êtes pas informé du retrait. Pire que cela, son retrait du dépôt ne lève aucune alarme d’aucune sorte et passe même inaperçue puisque cela apparaît simplement comme une extension externe au dépôt.

On nous rebat les oreilles – ce que je fais d’ailleurs moi-même – sur la sécurité des extensions et thèmes, qu’il faut les choisir avec attention, ne pas les prendre n’importe où et surtout les mettre à jour. Et les développeurs WordPress, pourtant à la pointe de la sécurité, virent discrètement des extensions avec des vulnérabilités sans même informer des risques les utilisateurs qui l’utilisaient. D’un point de vue sécurité, oui, ça me fait vraiment râler, j’aurais bien aimé le découvrir autrement, un mail par exemple. Le dépôt WordPress est capable de quantifier le nombre d’utilisateurs utilisant une extension, est aussi capable de pousser une mise à jour de faille de sécurité sur une extension largement utilisées mais est incapable de signaler le retrait d’une extension aux utilisateurs chez qui elle est installée !

Donc, pour conclure, afin de maintenir votre la sécurité sur votre site, ne choisir que les extensions du dépôt officiel de WordPress n’est pas suffisant. Il vous faut les inspecter une à une régulièrement pour rechercher la disparition de la mention « Afficher les détails ». Vous voilà averti.

Installation Windows 10 & Ubuntu Gnome 16.04 LTS

Logo Windows

Suite à un problème technique impromptu, sur mon PC un peu trop ancien, j’ai dû le renouveler en catastrophe en profitant d’une promotion fort opportune. Le problème, c’est que dans ce cas de figure, on a pas trop de choix, c’est Windows 10… À partir de ce moment, il est proposé chez ce constructeur, le remboursement du système d’exploitation, mais il faut retourner le PC au support et attendre une bonne semaine ; plutôt pénible lorsque votre PC est hors service. J’ai donc pris la décision comme la fois précédente, un double boot Windows / Linux, c’était sans savoir à quoi je serai confronté.

Les premiers écueils s’appellent « Bios UEFI » et « Secure Boot ». Les désactiver empêche l’installation Windows par défaut de démarrer, et toutes les versions d’Ubuntu (Ubuntu Gnome) ne gèrent pas cette configuration (seules les dernières versions le peuvent). Cerise sur le gâteau, il n’était pas possible de désactiver ces fonctions sans avoir mis à jour le Bios.

Une fois ces problèmes réglés, l’installation Linux peut enfin se faire, et Grub, permet de tout faire démarrer correctement. Sauvé !

Enfin presque. Au fur et à mesure que j’utilise l’ordinateur, je lève de nouveaux loups. Impossible, par exemple, sous Linux de lire des partitions Windows, ce qui ne posait aucun problème auparavant. En cherchant un peu, je découvre la « bidouille » des ingénieurs Microsoft pour améliorer le démarrage de Windows : ne plus arrêter les disques durs ! Il ne reste plus qu’à trouver dans le fouillis des paramètres celui gérant le démarrage rapide, dans la gestion des boutons de la gestion de l’alimentation. Encore un exemple ? Chaque fois que je démarre sous Windows, je me retrouve systématiquement avec 2 heures de retard. Encore quelques recherche pour découvrir que l’un se base sur l’heure GMT et l’autre sur l’heure UTC. Encore des modifications à faire dans la base de registre Windows.

Windows 10 le meilleur Windows jamais construit ? Euh… Non, mais c’est vraiment celui qui m’a fait perdre le plus temps pour faire un simple double boot. D’une certaine façon, ils ont gagné, la prochaine fois je ne ferai pas de double boot, je prendrai un ordinateur sans système d’exploitation et y installerai Linux et me contenterai de subir Windows… au bureau.

Faux-positifs d’alerte d’infection du site

Quelques jours auparavant, j’ai reçu un mail provenant du moteur de recherche Bing, m’informant de la présence d’un script malveillant sur mon site construit à l’aide de WordPress. Ce n’était certes pas la première fois que ce moteur de recherche m’informait de ce type d’événement, sans qu’il y ait eu d’infection ; un faux-positif. Premier réflexe, les outils de webmestre Google… Rien… Une petite analyse sur différents sites d’analyse en ligne… Rien…

Une petite visite sur les outils de webmestre Bing s’impose donc. 69 pages « infectées » mais impossible dans l’interface d’identifier le nom du fameux script malveillant ni même de voir le code en question. Pour analyser le problème, autant prendre une boule de cristal, cela ira plus vite… J’avoue d’ailleurs m’être demandé un instant, si ce n’était pas là non plus, leur méthode de traque. En attendant, mon site se voit, dans ce moteur de recherche, marqué du sceau de l’infamie informant les utilisateurs de la dangerosité du site et des risques de se voir infecter par quelque logiciel malveillant. Heureusement, ce moteur n’est pas celui qui draine le plus de trafic sur Internet, le mal est donc moindre.

Je mets quand même dans l’interface de gestion une remarque, soulignant le manque de pertinence de l’information d’une infection en l’absence de toute indication permettant de l’identifier lorsqu’ils sont les seuls à l’identifier, et que ce ne serait pas la première fois qu’un faux-positif soit découvert par le site. Autant dire que la remarque est gentillette au vu de l’angoisse ressentie à la réception du mail, du temps passé à se battre avec l’interface pour essayer de trouver des informations, du temps passé pour recouper les analyses sur différents sites et à tenter de diagnostiquer un problème dont on en vient à douter de son existence. Inutile de revenir l’immense joie, de voir son site affublé d’un avertissement dissuadant même les plus inconscients à visiter le site et de l’impact sur l’image du site. Pas besoin d’expliquer non plus que Microsoft étant une multinationale des plus sérieuses et particulièrement réputée pour la gestion de la sécurité, on bloque d’abord et on discute pas, sans même se poser la question de la pertinence de l’analyse.

Je laisse donc tomber.

Peu après, ayant publié un nouvel article, voulant vérifier le bon fonctionnement du cache, il me vient l’idée de vérifier la date de génération de la page récemment modifié. Je m’aperçois dans le pied de page, un peu par hasard, un script en JavaScript non crypté et ne correspondant pas à celui gérant les statistiques du site ou un autre que je connaisse. Je fais bien sûr immédiatement le lien avec le mail reçu quelque jours plus tôt et me demande donc si finalement, ce script ne pourrait pas être la fameuse « infection ».

Je tape les premières lignes de code dans Google et tombe sur un rapport d’analyse du site sucuri.net sur un autre site WordPress, faisant état d’un « Website Malware » nommé « malware-entry-mwanomalysp8 ». Sucuri.net étant un site que j’utilise régulièrement, et plutôt fiable, je commence à prendre cette fois les choses un peu plus au sérieux.

Vraiment au sérieux, parce que justement, cette fois, contrairement à l’outil précédent, on a un lien explicatif (même s’il est en anglais) sur la détection que je m’empresse de consulter. Je lis les explications qui me disent qu’un bloc de JavaScript ou de code dans une iframe a été identifié sur le site et que cela chargerait un code (potentiellement malicieux) d’un autre site. La conclusion du étant que le signalement de ce code ne résulte pas de l’identification d’une signature issue d’une base de virus mais d’un comportement anormal du site. Globalement, c’est probablement la même analyse qui a été faite avec les outils Bing, mais faite cette fois de manière un peu plus professionnelle (désolé je ne trouve pas d’autre mot) en indiquant le mode de détection et la menace détectée permettant d’initier des investigations. À partir de là, même si aucun virus n’a été formellement identifié (on peut donc légitimement se demander si ça valait bien le coup de bloquer le site), on doit cette fois prendre cette fois la menace au sérieux.

Je pousse un peu plus loin mes investigations et découvre finalement que ce code JavaScript est utilisé par mon extension de cache (HyperCache) pour gérer la mise en cache des commentaires et leurs auteurs sur mon site (fonctionnalité dont je ne me sert d’ailleurs plus). Tout cela pour ça. La désactivation de l’option a suffi à faire disparaître le fameux script suspect.

Je dois avouer que, n’utilisant pas les commentaires, je ne m’étais – à tord – pas intéressé suffisamment à cette fonctionnalité apparemment mal comprise par certains systèmes de sécurité un peu trop chatouilleux, ce qui m’a fait finalement perdre beaucoup de temps et quelques visiteurs.

Pour conclure, en cette période de questionnement sur une éventuelle position dominante de Google, on comprend que cette position repose quand même sur une qualité du travail fourni par rapport à ses concurrents. Depuis les nombreuses années d’existence de mon site, et de mon expérience dans le support de site WordPress, je ne suis rarement arrivé à le prendre en défaut sur ce type d’analyse au contraire de son concurrent qui m’a déjà fait plusieurs frayeurs dont je me serait bien passé. Ceux qui me connaissent, savent pourtant que l’on ne peut guère m’accuser de sympathie vis à vis de la firme de Mountain View et que je désespère de voir que cette entreprise à quel point, la firme a mis la barre très haut pour ses concurrents.

Il faut aussi arrêter d’avoir une confiance aveugle dans la technologie au point de bloquer inutilement à l’aide de messages anxiogènes sans s’inquiéter de la pertinence du travail d’un algorithme aussi intelligent soit-il et de crier « Au loup ! » avant même d’avoir réellement identifié la menace. L’humain a toujours sa place dans les processus technologiques, il faudrait voir à ne pas l’oublier.

Merci pour le blocage du site au passage sur une menace qui n’est pas identifiée, belle illustration sans doute de l’application aveugle du principe de précaution.

1 2