Renvoi site wordpress vers des sites pornographiques

bonjour,
A 4 reprises (en l’espace d’un an), des visiteurs du site https://lesradiosfrancas.fr qui héberge une webradio éducative m’ont informé que le site les avaient renvoyés vers des pop up et des sites pornographiques.
Je dispose de leurs captures d’écrans. Mais pour ma part, alors que je suis très régulièrement sur ce site avec différents ordinateurs ou téléphones, différents navigateurs je n’ai jamais constaté ce problème.
Merci à toutes et à tous de m’aider car c’est un problème qui s’il n’est pas résolu va nous conduire à mettre la webradio en maintenance.
Hervé.

Bonjour Hervé,

ça ressemble à des soucis de plugins (il y en a plus de 50000 pour Wordpress) et certains sont des vrais passoire de sécurité.
Idéalement, il faudrait pourvoir lister ici tous les plugins actifs sur le site des webradios.
En allant dans l’interface et avec une capture par exemple ?

à suivre.
Librement
LauwCost

1 « J'aime »

Oui, @LauwCost a tout à fait raison !

WP est le CMS le plus répandu, donc le plus attaqué, ce qui rend sa maintenance « lourde » afin d’avoir toujours une version du CMS, des plugins et des thèmes à jour.

Perso, je gère deux sites WP et je m’oblige à en faire la maintenance (mettre tout à jour), une fois par semaine et, en 3 ans : zéro PB. C’est le prix à payer…

J’ai pas mal navigué sur le site et je n’ai pas rencontré les PBs que tu mentionnes. Néanmoins je suis tombé sur 2 erreurs, voir illustrations ci-dessous. Bon courage.

Bonjour,

Une rapide analyse avec wpscan montre effectivement qu’aucun plugin n’est à jour.

Du coup, je plussoie les conseils de mes petits camarades. Mettre à jour. (même si ça ne solutionnera pas tous les problèmes si ils sont déjà installés :confused: )

Peut-être un chaton avec plus de compétence et de temps pour aider nos ami·es des Francas ?

Bonjour HPREVOST, la redirection ne se fait que sous certaines conditions :

  • l’utilisateur n’est pas loggué sur le Wordpress (pas de cookie wordpress)
  • l’utilisateur est arrivé sur le site depuis un moteur de recherche (présence d’un header Referer)
  • check sur le User Agent et l’adresse IP
  • d’autres règles arbitraires, dont du hasard

Ces conditions ont été ajoutées pour les attaquants afin de passer sous les radars des administrateurs/contributeurs du site web qui sont 1) toujours connectés 2) accèdent à leur site web depuis une URL directe.

Voilà quelques ressources qui peuvent t’aider pour en apprendre plus :

C’est très courant ce genre de Wordpress compromis, y compris dans nos cercles libristes. Et c’est toujours un combat de faire accepter aux admins du Wordpress que leur CMS est compromis bien qu’eux n’expérimentent pas les redirections. Je ne citerai pas de nom ^^

Le seul moyen viable de se débarrasser de la backdoor, à mon avis, c’est de faire un export de la BDD, copier les downloads un à un en les passant au peigne fin (vérifier l’extension ET le contenu du fichier), et ensuite réinstaller Wordpress, les plugins, et les thèmes dans leur dernière version (en faisant du ménage) pour enfin réinjecter le contenu. Parce que la backdoor a mis du code partout dans l’install Wordpress pour réinfecter ton installation même si tu enlèves une partie de ses fichiers.

Avant de se lancer là dedans, il me semble nécessaire quand même de valider une bonne fois pour toute qu’il y a bien une backdoor et que ce ne sont pas les utilisateurs qui ont leur ordinateur perso infecté. Pour ça, les billets de blogs ci-dessus donne les techniques et référencent des outils pour facilement trouver des bouts de code appartenant à la backdoor.

Parti pris - Wordpress est un écran de fumée : il te fait croire que tu peux gérer ton site web comme une application, sans avoir à comprendre le fonctionnement du web, et en pensant que tout est disponible facilement, au mépris de tous les problèmes que ça cause. Ça a créé un écosystème avec beaucoup de code de mauvaise qualité, sans que personne ne soit dédié clairement à la maintenance, avec des failles de sécurité permanentes, dont il est difficile de se prémunir, tout en devenant rapidement lent et gourmand en ressource. Wordpress est l’incarnation de la dette technique : derrière la promesse de se lancer vite et seul, se cache une bombe à retardement qui va faire payer à ses utilisateur-ices très cher leurs choix de départ.

2 « J'aime »

WP est le CMS le plus répandu, donc le plus attaqué […]

C’est un CMS très répandu, certes, et très attaqué, mais c’est aussi le CMS dont le code est particulièrement vulnérable, d’une part, et l’absence de mécanisme de cache oblige à utiliser un des quelques plugins de caches… pas toujours compatibles avec le reste.

Il y a beaucoup de plugins pour compenser les nombreux problèmes d’architecture, et ces plugins sont généralement pensés et orienté vers les fonctionnalités plutôt que la sécurité.

J’ai hébergé du WP, ça bouffe plein de CPU et de ram pour pas grand chose.

1 « J'aime »

Voilà ma supposition :

  • Il y a un formulaire de contact généré par le plugin Contact Form 7 (vous utilisez ce plugin) quelque part sur le site web où on peut envoyer un fichier attaché (j’ai pas trouvé la page, la page contact a un formulaire sans upload).
  • L’attaquant a utilisé la CVE-2020-35489 (cette faille a été corrigée dans la version 5.3.2 publiée en décembre 2020 mais vous utilisez la version 4.9 publiée en décembre 2017) pour envoyer une pièce jointe au format .php, plus exactement un Remote Access Trojan type phpsploit. Je montre dans ce vieil article à quoi ça ressemble un RAT PHP.
  • Le RAT est alors accessible à une URL qui ressemble à ça https://lesradiosfrancas.fr/wp-content/uploads/rat.php par exemple. Parce que vous n’avez probablement pas désactivé l’exécution de PHP, votre serveur Apache/PHP interprète votre pièce jointe comme un fichier PHP normal. Il suffit de l’ouvrir pour avoir un accès complet à tout votre site web et faire ce qu’on veut. Par exemple aller voir les infos de connexion à la base de données dans wp-config.php ou encore modifier/insérer/supprimer n’importe quel fichier du site web.
  • L’attaquant a probablement patché certains fichiers de Wordpress pour faire ses redirections ET pour se maintenir dans le système si la faille venait a être corrigée.
1 « J'aime »

Moi j’en ai pas mal sous le coude mais j’utilise David / wp-cli-isp · GitLab une surcouche à wp-cli pour parser arborescence ISPconfig pour :

  • Mettre à jour (de force) tout les wordpress toutes les semaines (problème à la charge de l’utilisateur)
  • Installer+configurer (si ce n’est pas fait, de force toujours) w3-total-cache. Avec lui de bien configurer tu peux désactiver le PHP et le site continue de tournée… (les pages sont générés en static, un htaccess redirige l’utilisateur vers celle-ci… j’avais fais quelques tests : Héberger un WordPress : sécurité, optimisation, économie d’énergie – David Mercereau )

Les utilisateurs sont prévenu, c’est le jeux pour que j’accepte d’héberger un wordpress.

David

1 « J'aime »

Chez Gozmail nous avions eu un soucis similaire sur notre bugtracker flyspray (bien heureusement bien moins fréquenté que les WPs), à cause d’une faille laissée ouverte de notre fait lors de la mise en place.

Et malheureusement, je suis d’accord que dans ce genre de cas l’export-réinstallation-réimport est la seule manière sûre de corriger le problème.

C’est aussi l’occasion de rappeler les bonnes pratiques. Par défaut, si on n’isole pas ses applications, une seule application compromise peut donner les privilèges suffisants pour compromettre toutes les autres.

Donc : on fait des VMs pour chaque application, ou à défaut des conteneurs, ou à défaut on exécute chaque application avec un utilisateur distinct et différent de www-data, par exemple pour le PHP on utilise php-fpm et pas un module apache, et on utiise des pools spécifiques à chaque application.

Sekil

2 « J'aime »

Hello toutes et tous !

D’abord Waouh. On se rend compte (et comme moi, on appréhende plutôt de loin quand on est pas technicien/informaticien) avec cette petite question porno-anodine, tout ce qui peut se jouer dans ce genre de situation.

Et on comprend bien aussi combien ça peut être difficile d’aider des associations dans ce cas là : comme je connais un peu Hervé, je peux me permettre d’écrire ici qu’il n’a pas du comprendre plus de 50 % des 10 % de choses que j’ai comprises à la lecture. :)…

Néanmoins, ce fil est intéressant pour le projet Emancip’Asso pour illustrer ce décalage qu’il peut y avoir entre tous les soucis techniques sous-jacents et la réalité associative. Je n’ai pas de solution mais déjà, vos nombreux retours et explications sur ce fil, même s’ils sont parfois très techniques, permettent au moins de prendre conscience des choses. C’est déjà une première étape. C’est clairement de l’éducation populaire :).

Ça va sans doute encourager Hervé à chercher (il a peut-être déjà trouvé) une personne / une structure sérieuse susceptible de considérer le problème et de le résoudre.

Bref, merci à tous et toutes pour vos retours ! Ça doit nous aider à continuer réfléchir dans le cadre d’Emancip’Asso pour affiner les capacités de réponses concrètes (et financées) pour des situations qui s’approchent de celle-ci…

Librement,
LauwCost

2 « J'aime »