J’ai besoin d’une solution pour nettoyer mon dossier d’hébergement.
L’un de mes sites a quasi sûrement été piraté, car, en FTP :
Des dossiers ressemblant au nommage de ceux de WordPress sont apparus (wp-content, par exemple).
Le dossier racine est passé des droits d’accès 755 à 555 et refuse de revenir à 755
à l’intérieur de ce dossier racine, j’ai pu passer certains fichiers ou dossiers à 777 indiqué, mais, après que j’ai demandé leur suppression, FileZilla affiche « 550 accès denied »
Dans un certain nombre de dossiers dont les noms n’ont pas de rapport avec SPIP, des fichiers sont ineffaçables et d’autres réapparaissent après avoir disparu (je support que parmi les fichiers que je ne peux effacer, il y en a un qui contient un script malveillant qui recrée ces fichiers)
Pour info, voilà ce que m’a répondu le support technique:
Citation Nous avons constaté que le dossier www, situé sous le répertoire /home/www, se recrée automatiquement après sa suppression, avec des fichiers suspects à l’intérieur. Cela peut indiquer la présence d’un script malveillant ou d’un processus automatisé agissant depuis un autre emplacement. Nous vous recommandons de vérifier l’ensemble du contenu du répertoire /home, notamment les fichiers et dossiers susceptibles de contenir des scripts ou tâches planifiées. Voici quelques actions à envisager : Inspecter les fichiers exécutables ou récemment modifiés dans /home. Rechercher des fichiers suspects avec des noms inhabituels ou des permissions anormales. N’hésitez pas à faire appel à un spécialiste pour faire le nécessaire.
C’est bien joli cette réponse de l’hébergeur, mais comment je supprime des fichiers qui refusent d’être supprimer et qui refuse de changer leur droits d’accès? Et comment est-ce possible depuis l’extérieur extérieur?
Je viens de changer le mot de passe ftp.
Pensez-vous que ce sera suffisant?
Existe-t-il d’autres moyens n’utilisant pas le mot de passe FTP pour qu’un pirate accède en écriture au fichier d’un site?
Il faudrait donc redémarrer apache.
Pour cela, changer la version de PHP peut suffire.
Donc :
changer la version de PHP
tout déplacer dans un sous-dossier pour que le hackeur n’ait plus les bons chemins
remettre en place le SPIP progressivement à la racine (par une installation propre avec spip_loader.php, puis IMG/ en l’ayant nettoyé, puis les plugins par SVP, puis le squelettes/ en l’ayant nettoyé)
Mais, avant cela j’aimerais avoir confirmation que les fichiers qui sont présent à la racine de mon espace d’hébergement sont des fichiers et des dossiers qui sont tous nécessaires à l’hébergement ou si je peut les supprimer sans risque.
Dans www il y a les dossier des 2 sites spip hébergés.
l’un des 2 s’appelle aussi « www » ce qui devait être le premier dossier par défaut et c’est celui du site piraté (il vaudrait mieux qu’il porte un autre nom.)
Sachant que le service technique de l’hébergeur à déplacé la majorité des fichiers qui étaient dans le dossier « www/www », où se trouvait le site piraté, vers le dossier « quarantaine » à la racine de l’hebergement, il ne reste que peu de fichiers et dossier s dans le dossier « www/www » (voir capture d’écran, ci-dessous)
Parmi ces fichiers qui déclenchent un « 550 index.php: Permission denied » quelle que soit l’action qu’on veut y appliquer, il y a un .htaccess qui contient des instructions qui me semblent très suspectes.
DirectoryIndex index.php index.html
<FilesMatch '.(py|exe|phtml|php|PHP|Php|PHp|pHp|pHP|pHP7|PHP7|phP|PhP|php5|suspected)$'>
Order allow,deny
Deny from all
</FilesMatch>
<FilesMatch '^(goods.php|buy.php|special.php|click.php|edit.php|pages.php|product.php|shop.php|item.php|search.php|brand.php|wp-configs.php|install.php|plugin.php|plugins.php|admin.php|index.php|wp-login.php|wp-log1n.php|about.php|defaults.php|function.php|mah.php|networks.php|options.php|amp.php)$'>
Order allow,deny
Allow from all
</FilesMatch>
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
j’ai tenté de remplacer ce fichier .htaccess par un .htaccess vide mais FileZilla renvoi :
Commande : STOR .htaccess
Réponse : 550 .htaccess: Permission denied
Erreur : Erreur critique lors du transfert du fichier
Par ailleurs, j’ai pu suivre quelques uns des conseils de @RealET, mais pas tous.
J’ai changé la versions PHP et j’ai même cliqué sur « Redemarrer » dans l’adminitration de mon hébergementre mutualisé.
Quand à déplacer le contenu du dossier « www/www », comme le changeement des droit du dossier est refusé et reste bloqué à 555, je suis bloqué sur ce point.
Je commence à désespérer d’arriver à nettoyer le dossier « www/www ».
Je peux toujours créer un nouveau dossier « www/bidule » pour y installer un nouveau site spip, mais ça m’embête de laisser ce dossier « www/www » qui conteint de fichiers dont je ne suis pas sûr qu’ils seraient sans conséquence sur le nouveau dossier « www/bidule » et son contenu.
Ces fichiers ne sont pas bloqués automatiquement par notre antivirus pour éviter le risque de faux-positifs, nous vous invitons donc à vérifier leur contenu.
il y a aussi, à la racine de l’hébergement, un fichier « clamscan.txt » (sans doute un fichier produit par l’antivirus Linux ClamAV) et qui contient ce qu’indique le mail:
Le problème est que la plupart des dossiers et fichiers contenus dans le dossier « www/www » ne sont ni effaçables, ni remplaçables et que les fichiers qu’on peut supprimer reviennent tout seuls.
Pas sur
Les hackers parient sur la presence d’un WP et laissent des fichiers adaptés à ce CMS
Lors d’un hacking (mises à jours non suivi) le probleme avait été résolu par effacement des dit fichiers WP par SSH par propriétaire dz l’hébergement
Sachant que la mise à jour vers 4.4.4 ne comprenait pas a priori de correctifs de sécurité, est-ce que ça ne vaudrait pas le coup de regarder comment les pirates sont rentrés ? Je ne sais pas trop qui pinguer pour ça cela dit
Euh… Peut-être étaient-ils rentrés avant la mise à jour ? Le site n’avait-il pas déjà été piraté ? Auquel cas le nettoyage n’avait peut-être pas été complet ?
Il n’y a pas de faille connue de sécu sur SPIP 4.4.
Sinon Signaler un bug ou une faille de sécurité - SPIP
@Jack31 , Hervé a indiqué qu’il était sur 4.4.3 lorsque le site a été piraté (après est-ce que c’était déjà présent avant… toujours possible en effet).
Il me semble bien que le site piraté était un spip 4.4.* d’origine et non une mise à jour depuis une branche précédente.
L’hébergeur à pu finalement supprimer le dossier « www/www » dans lequel étaient hébergé le site piraté.
Théoriquement, il ne reste plus de fichiers vérolés dans l’hébergement.
Par contre, si quelqu’un de plus chevronné que moi est intéressé, aux vues d’analyse, par une copie de l’ensemble du dossier « www/www » avant nettoyage puis suppression, j’en ai gardé une copie en local que je suis prêt à le fournir.
Si les mises à jour ne changent pas le httaccess d’exploitation, il y a une petite chance que l’entête de ce fichier soit encore tagué avec la version d’origine.
Clt
