Bonjour à tous,

J'ai un serveur dédié depuis de nombreuses années tournant sous debian avec un serveur apache2 afin d'héberger les différents sites que je gère.

Je n'ai jamais eu de soucis pendant plusieurs années mais voici qu'il y 2 mois maintenant j'ai subis une attaque sur mes sites. 

En effet, j'ai des fichiers qui se sont ajoutés dans mes dossiers de mes sites tournant sur Wordpress et des modification de fichier sensibles qui redirigeai les visiteurs sur d'autres sites.

J'ai donc renforcer la sécurité du dédié dans tous les sens (limité les accès SSH, FTP par ip et autres) mais le pirate arrivait toujours à modifier ces fichiers. 

J'ai donc changé les droits d'écriture des fichiers de mes sites en 644 ou lieu de 664 pour les fichier PHP et 755 au lieu de 775 limitant l'user www-data d'apache d'avoir l'accès à la modification des fichiers et là le problème c'est réglé. 

Le problème étant que wordpress est du coup limité dans ces actions, je ne peux par exemple plus mettre à jour les plugins depuis le site sans modifier provisoirement les droits en écriture car l'utilisateur apache n'a plus l'accès.

Je cherche donc soit à comprendre comment il peut ajouter/modifier des fichiers aussi facilement avec un accès 775 et 664 (donc depuis l'utilisateur apache www-data donc) ou alors comment faire en sorte d'avoir des droits écritures depuis mes sites wordpress en gardant le droit d'écriture 644 et 755 et ainsi bloqué ces tentatives de modification.

Merci d'avance pour vos lumières car je sèche un peu sur la méthode.

Bonjour,

Je pense que ce qui voulu est impossible en l'état.

L'attaquant semble exploiter une ou plusieurs failles dans un ou plusieurs des sites internet hébergés avec WordPress. Tant qu'aucune remédiation ne sera appliquée pour patcher ces failles, l'attaquant prendra toujours le contrôle des sites web (voir à terme du serveur si ce n'est pas déjà le cas).

En bref, il faut traiter la cause du problème:

1. chercher des traces d'attaques et de compromissions sur le serveur

2. identifier exactement les vulnérabilités, les backdoors et les malwares potentiels

3. détruire les backdoors et les malwares s'ils ont été trouvés

4. remédier aux vulnérabilités (patches ou mitigations)

5. adapter la configuration des systèmes de protection et de détection d'intrusion.

6. Retour à l'étape 1.

Ce que tu peux faire en parrallèle:

Tu peux mettre à jour ton serveur (apt update && apt upgrade -y), si ta version de Debian est obsolète, je te conseille de monter vers la dernière version stable. Ce qui implique de mettre à jour Apache, PHP (et toutes les bibliothèques associées) et la base de données SQL.

Tu peux mettre à jour WordPress ainsi que tous les modules installés. Je crois qu'il existe des modules WordPress pour assurer une sécurité. je te conseille de te renseigner et d'installer les modules qui augmenteraient la sécurité de tes sites web.

Tu peux renforcer la sécurité du serveur web en lançant chaque site WordPress dans des containers séparés avec Docker (nécessite d'apprendre à utiliser Docker). Sachant que WordPress est un des containers officiel dans les dépôts de Docker. Que chaque site soit dans un container séparé permet de s'assurer que seul le site vulnérable peut être compromis et de rendre beaucoup plus difficile toutes tentatives de mouvement latéral ou élévation de privilège par l'attaquant (la menace sera isolée).

Tu peux mettre place des solutions IPS et IDS comme Crowdsec qui permettront de te protéger et de détecter certaines intrusions sur ton serveur en temps réel.

Tu peux mettre en place un WAF (Web Application Firewall) comme ModSecurity pour bloquer les attaques les plus communes.

Tu peux lancer des scans antivirus régulier avec ClamAV.

-
Edité par KoaTao 18 juillet 2023 à 20:18:44

Bonjour KoaTao,

Merci pour ton retour rapide et complet

Par contre, je suis toujours perplexe, en effet la sécurité sur le serveur, je l'ai renforcé en mode psycho car à la base, je pensais que celui-ci avait piraté le serveur mais après analyse des différents logs du serveur, aucune trace d'une effraction ou autre. J'avais bien des tentatives de connexion au SSH du serveur mais en limitant à mon ip l'accès au serveur, celle-ci sont complètement bloqués. De plus, à part mes sites wordpress, rien d'autre n'est touché et seulement quand j'accorde des droits d'écritures à www-data sur mes sites wordpress, donc il n'a pas accès au serveur mais à un exploit que je n'arrive pas à comprendre et je deviens paranos.

Le serveur est à jour, apache également et php, il est vrai que j'utilise encore la version 7.4 mais avec Wordpress, php 8.0 n'est pas toujours comptabilite. J'ai installer Clamscan, Rkhunter et Chkrootkit, rien n'a été détecté. J'ai mis en place un WAF sur le dédié aussi mais le problème persiste.

Pour mes sites, ceux-ci sont à jour et même en installant un nouveau site, j'ai fait un test sur une installation vierge de wordpress, celui-ci arrive aussi à se faire pirater avec ces fameux droits . Pourtant j'ai installé sur chaque site Wordfence pro qui protège et analyse le site en temps réel (cela me permet d'être prévenu dès qu'il y a modification et de corriger rapidement les fichiers en défauts).

Franchement je coince, je ne comprends pas comment il parvient à aussi facilement insérer ces fichiers sur mes sites wordpress dès que le droit en écriture est ouvert à www-data d'apache. 

Avez-vous une autre idée d'où cela peut venir? Ou si vous connaissez un professionnel dans le domaine que je pourrais faire intervenir pour m'aider (contre rémunération bien sûr). J'ai déjà cherché un pro de mon coté mais c'est dur à trouver des personnes vraiment compétente dans ce domaine et OVH (mon hébergeur)  n'a aucun service à ce niveau là à proposer.

Merci pour votre aide

Bonjour,

XavierT a écrit:

De plus, à part mes sites wordpress, rien d'autre n'est touché et seulement quand j'accorde des droits d'écritures à www-data sur mes sites wordpress, donc il n'a pas accès au serveur mais à un exploit que je n'arrive pas à comprendre et je deviens paranos.

www-data est un utilisateur du serveur. Lorsque l'attaquant est www-data, c'est très souvent indicateur que le serveur web est vulnérable et exploité. Si en plus l'attaquant peut charger des fichiers PHP sur dans l'arborescence de WordPress, alors il peut executer des commandes sur le serveur par un web shell ou un remote shell. C'est largement suffisant comme accès pour faire de ton serveur un bot.

XavierT a écrit:

Le serveur est à jour, apache également et php, il est vrai que j'utilise encore la version 7.4 mais avec Wordpress, php 8.0 n'est pas toujours comptabilite. 

PHP 7.4 est EOL (End of Life) depuis novembre 2022. Donc le serveur n'est pas vraiment à jour. En regardant un peu, je vois que dans le docker officiel de WordPress se construit avec PHP 8.1 et PHP 8.2 est en beta. Le blog des dév de WordPress montre que PHP 8 est utilisé depuis deux ans maintenant.

Loin de moi l'envie d'appuyer où cela fait mal mais le serveur n'est pas à jour. On ne peut pas dire « À jour sauf... ». Les bibliothèques dont dépend PHP ne le sont donc pas non plus. Peut-être même que WordPress ne l'est pas. À partir de là, le champs des possibilités s'ouvre. Et vu que l'installation de paquet et la mise-à-jour fonctionne sur un système de dépendance avec APT, laisser certains paquets en l'état peut empêcher la mise-à-jour d'autres paquets.

Comment installes-tu WordPress exactement ?

XavierT a écrit:

Pour mes sites, ceux-ci sont à jour et même en installant un nouveau site, j'ai fait un test sur une installation vierge de wordpress, celui-ci arrive aussi à se faire pirater avec ces fameux droits . Pourtant j'ai installé sur chaque site Wordfence pro qui protège et analyse le site en temps réel (cela me permet d'être prévenu dès qu'il y a modification et de corriger rapidement les fichiers en défauts).

Franchement je coince, je ne comprends pas comment il parvient à aussi facilement insérer ces fichiers sur mes sites wordpress dès que le droit en écriture est ouvert à www-data d'apache. 

Unrestricted File Upload | OWASP Foundation

Avec ce type de faille, l'attaquant peut upload autant de fichier qu'il souhaite dans l'arborescence des sites web. De plus, si l'accès l'interface de WordPress est compromis, l'attaquant peut upload des fichiers directement depuis l'interface.

Autres possibilités, l'attaquant a compromis autre chose dans la chaine des logiciels utilisés pour déployer tes sites webs, comme un module WordPress par exemple.

Normalement, avec des logs d'Apache assez verbeux et une timeline pas trop longue, il doit être possible de retrouver les méthodes utilisées par l'attaquant pour exploiter le serveur web/site web.

XavierT a écrit:

En effet, j'ai des fichiers qui se sont ajoutés dans mes dossiers de mes sites tournant sur Wordpress et des modification de fichier sensibles qui redirigeai les visiteurs sur d'autres sites.

Une autre solution est d'essayer "d'identifier" l'attaquant. Chaque attaquant a souvent un modus operandi, avec assez de traces et si l'attaquant a réalisé de nombreuses attaques de la même manière, il y a fort à parier qu'on puisse retrouver des informations sur les tactiques, techniques et procédures (TTP) utilisées par l'attaquant et ainsi déterminer la faille ou les failles exploitées chez toi.

On pourrait commencer par les fichiers laissés par l'attaquant et les sites webs contrôlés par l'attaquant. Si tu peux nous les fournir, on pourra essayer de les analyser.

XavierT a écrit:

Ou si vous connaissez un professionnel dans le domaine que je pourrais faire intervenir pour m'aider (contre rémunération bien sûr). J'ai déjà cherché un pro de mon coté mais c'est dur à trouver des personnes vraiment compétente dans ce domaine et OVH (mon hébergeur)  n'a aucun service à ce niveau là à proposer.

Non, enfin, pas dans ton budget je pense. Les presta dans ce domaine coutent excrément cher (plus de 200 € de l'heure) 

Tu peux fouiller sur le site de l'ANSSI: En cas d’incident | Agence nationale de la sécurité des systèmes d'information (ssi.gouv.fr).

EDIT: J'ai oublié de préciser, l'attaquant peut avoir déjà établit une persitence sur ton serveur. C'est-à-dire que même si tu supprimes les fichiers malicieux, il pourra toujours les recréer automatiquement ou recréer un accès au serveur ou contacter un serveur de commande et de contrôle (C2) pour éxecuter de nouvelles actions. Par exemple, il peut avoir défini une tâche programmée dans le cron de l'utilisateur www-data.

-
Edité par KoaTao 21 juillet 2023 à 15:25:25

Merci pour tes éclaircissement, je vais encore investiguer à tout cela et en effet, forcer le passage à php 8.0 , il est temps, il faut juste que je règle quelques problèmes de comptabilité.

Ah si tu as tout de même un contact mais dans les budgets que tu annonces, tu peux m'envoyer par message, j'ai trois activités professionnel, je peux bien investir un peu dans la sécurité car c'est pas évident de trouver des personnes compétentes facilement, pour le budget après c'est normal, j'ai pas de soucis avec cela.

Bonjour,

KoaTao a écrit:

Non, enfin, pas dans ton budget je pense. Les presta dans ce domaine coutent excrément cher (plus de 200 € de l'heure) 

Tu peux fouiller sur le site de l'ANSSI: En cas d’incident | Agence nationale de la sécurité des systèmes d'information (ssi.gouv.fr).

C'était une façon de dire que tu sembles être un trop petit poisson dans un océan remplis de gros poissons qui périssent eux-aussi déjà.

Je te conseille de vraiment suivre les recommandations de l'ANSSI.

Contact ton CSIRT: https://www.cert.ssi.gouv.fr/csirt/csirt-regionaux/. Ils t'orienteront vers les presta adaptés.

-
Edité par KoaTao 22 juillet 2023 à 6:00:17