Blocage de l'hébergement, je ne trouve pas la faille

Après un échange au 1007 avec un technicien très compétent et très professionnel qui a su répondre à toutes mes questions, j'ai reçu les résultats d'un scan interne à OVH avec une liste de 4 fichiers incriminés.

J'ai tout passé en revue et je ne trouve aucune anomalie dans ces 4 fichiers. Ils n'ont pas été modifiés depuis plusieurs années, et n'ont pas été appelés aujourd'hui (dans les logs serveur).

Je ne comprends pas le lien avec la "commande apparente" stipulée dans le mail (cf. mon premier message ci-dessus).

Par précaution j'ai carrément effacé un site concerné, pour le second site c'est impossible car il est important.

J'ai rouvert mes sites via FTP avec CHMOD 705 mais je suis traumatisé par ce que je viens de vivre et j'aimerais être certain que cela ne se reproduira pas. Je me demande si il ne s'agit pas d'un faux positif ?

Voici le contenu d'un des fichiers incriminé, si quelqu'un peut y jeter un oeil ?
https://gist.github.com/anonymous/7b5be67bf370344cb7bbac6e8e4df058

Merci beaucoup pour votre aide.

Bonjour,

Puisque c'est un fichier de phpbb le mieux est de le remplacer ou de le comparer avec un fichier original. (win merge permet de comparer 2 fichiers)

Bonjour,

à priori c'est un faux positif et il faut faire remonter le problème, car ce fichier ressemble +/- à une V3.0 (non à jour) de phpBB.

Dernier fichier de la V3.0 : https://github.com/phpbb/phpbb/blob/3.0.x/phpBB/includes/utf/utf_tools.php

Cordialement, janus57

Merci de t'intéresser à mon problème @Buddy , je viens de comparer (avec PSPad qui permet aussi de comparer 2 fichiers) et il n'y a pas de différence. Le fichier n'a pas été modifié depuis 2013 (date de dernière modification indiquée sur le FTP, c'est le jour de l'installation du CMS) ! Le fichier incriminé est donc totalement intègre !
Que suggères-tu ?

Qu'il faudrait faire la mise à jour car il y a peut être une faille publiée depuis qui est exploitable..

Certes tu as bien sûr raison, mais je pense que là ça n'a rien à voir, j'aimerais comprendre pourquoi le scan OVH me sort ce fichier qui me semble intègre et sans aucun lien avec la commande incriminée, à savoir :
> Problème rencontré : Un script malveillant a été détecté sur votre hébergement
> Commande apparente : /images/x86.r3/lib/ld-linux.so.2 --library-path /images/x86.r3/lib/i386-linux-gnu:/images/x86.r3/usr/lib:/images/x86.r3/usr/lib/i386-linux-gnu:/images/x86.r3/usr/local/lib:/images/x86.r3/usr/local/php5.4/lib/php-extensions:/images/x86.r3/lib php-fpm: pool xxxxxxx
> Exécutable utilisé : /usr/bin/perl

Si un admin passait par ici et pouvait nous donner son point de vue ce serait très apprécié !

Bonjour,

Surement car un des script fait un appel à "perl" ou fait croire (genre une balise [code=perl] qui est parsé à l'aide des fichiers).
Où alors le scan détecte les vieux CMS avec des failles.

Cordialement, janus57

je ne trouve rien dans les logs et je vois mal OVH passer tout un hébergement en 403 FORBIDDEN parce qu'un CMS n'est pas à jour ?

par contre en cas de faille avérée sur l'hébergement, oui, bien sûr et c'est normal.

je n'affirme pas que mes fichiers sont safe mais j'aimerais juste comprendre où se trouve la faille et être certain qu'il ne s'agit pas d'un faux positif

A priori quelqu'un s'est déjà fait confirmer un faux positif avec exactement le même message d'erreur (voir https://community.ovhcloud.com/community/fr/hebergement-pirate?id=community_question&sys_id=f172fdc8f15e42d01e11e7bb9bf103ab )

Bonjour,

je ne trouve rien dans les logs et je vois mal OVH passer tout un hébergement en 403 FORBIDDEN parce qu'un CMS n'est pas à jour ?

si il contient une faille critique qui est public et que le robot est capable de détecter c'est pas improbable.

je n'affirme pas que mes fichiers sont safe mais j'aimerais juste comprendre où se trouve la faille et être certain qu'il ne s'agit pas d'un faux positif

déjà il serait bon de mettre les CMS à jour, et si c'est réellement un faux positif "tant mieux" car si il y a réellement une faille ou fichiers infectés OVH n'est pas tendre très longtemps.

Cordialement, janus57

Voici un autre fichier incriminé, il contient ... 2 tableaux et n'a pas été modifié depuis 2013 :
https://gist.github.com/anonymous/0de86bd3d10e042bec1ef308cbb7c309

Ca pue en effet le faux positif car la plupart des hacks encryptent le payload en hexadécimal.
Les lignes comme celles-ci
> "\xE1\xBE\xAD" => "\xE1\xBD\xAD\xCD\x85",
seraient bien à l'origine de détections de type heuristiques.

Frédéric

Merci pour ton retour @Fritz2cat, je pense comme toi.

Parmi les 4 fichiers incriminés par le scan interne OVH :

- 3 fichiers contiennent du code hexa (dont un fichier très lourd qui a pu faire bugguer Okiller ?)
- 1 fichier contient du eval(base64 decode) LEGITIME (une obfuscation de droit d'auteur / copyright du script que j'avais repéré dès son installation et qui ne contient aucune commande malveillante)

Maintenant là où le mystère subsiste, c'est la provenance de la commande qui a déclenché la fermeture automatique de mon hébergement et donc de tous mes sites :

`/images/x86.r3/lib/ld-linux.so.2 --library-path /images/x86.r3/lib/i386-linux-gnu:/images/x86.r3/usr/lib:/images/x86.r3/usr/lib/i386-linux-gnu:/images/x86.r3/usr/local/lib:/images/x86.r3/usr/local/php5.4/lib/php-extensions:/images/x86.r3/lib php-fpm: pool xxxxxxx`

et là je sèche complètement, aucune trace nulle part ...

Je suis inquiet car je me rends compte qu'OVH peut couper à tout moment mes outils de travail, c'est hyper anxiogène.

J'ai laissé un accès FTP au technicien du support (à sa demande), je vous tiens au courant pour la suite car ça peut intéresser / concerner tout le monde. Si un membre de la team OVH passe par là et a un avis sur le sujet je suis preneur !

Bonjour,

ce qui a entrainé la fermeture de votre site c'est cette commande [quote]Exécutable utilisé : /usr/bin/perl[/quote]
Le reste c'est juste que c'est votre pool PHP (PHP 5.4 même) qui a bien exécuté cette commande et le chemin de celle-ci sur les serveurs OVH (ce qui est débile à montrer car cela n'aide en rien le débug pour le propriétaire du site).

Cordialement, janus57

D'accord, mais ce que je ne comprends pas c'est le rapport entre cette commande et les fichiers indiqués par le scan OVH.

J'ai l'impression que le processus Okiller est tout à fait indépendant du scan effectué sur demande par le technicien du support, et que ce scan fournit des résultats qui ne sont pas forcément en rapport avec le problème remonté par Okiller. Parfois ça colle, parfois pas.

J'ai l'impression d'être démuni face à ce problème car je manque d'éléments pour identifier la source du problème (si problème il y a ce qui n'est pas certain).

Au passage, une suggestion pour OVH : lors du blocage d'un hébergement il serait peut-être plus indiqué de renvoyer une erreur 503 plutôt qu'une erreur 403, cela impacterait moins le référencement des sites bloqués je pense.

Il faudrait également aider davantage les clients à comprendre l'origine exacte de la commande ayant déclenché le blocage. Un hébergeur n'a pas vocation à faire du webmastering pour ses clients, nous sommes d'accord, mais peut-être que des informations complémentaires pourraient être fournies car un blocage d'hébergement est loin d'être anodin.

D'accord, mais ce que je ne comprends pas c'est le rapport entre cette commande et les fichiers indiqués par le scan OVH.

il n'y en a peut être pas..
Un fichier php a appelé une commande perl qui a déclénché le robot ovh.

OVH ne fournit pas l'heure de la commande ? histoire de pouvoir corréler avec les logs ?
Quelle page du site a été appelé à cette heure ci ?
Par quelle ip ? Si c'est un ip d'Europe de l'est, chine, russie , asie et etc ... c'est quasi sur qu'une faille a été touchée.

J'ai épluché les logs je n'ai rien trouvé d'anormal mais j'ai pu passer à côté

Il y a une heure dans l'horodatage. à mon avis il faut chercher les pages juste avant. et analyser les ips qui ont chargé des pages.

Réponse du support cette nuit :
> Merci pour votre complément d'information.
> Effectivement, je confirme que les fichiers concernés sont authentiques.
> De toute manière le serveur n'est plus bloqué.
> Si jamais vous rencontrez un souci pareil, merci de les fournir ce numéro de ticket ou la même explication pour rétablir votre site.

Le scan a donc bien remonté 4 fichiers en faux positifs, ce n'est pas grave en soi mais qu'en est-il en revanche d'Okiller et de la commande qu'il a repérée ? Parce que bloquer tout un hébergement ça c'est très grave et je n'accepte pas de vivre avec cette épée de Damoclès au-dessus de la tête donc j'aimerais comprendre ce qu'il s'est passé avec Okiller ! Le problème c'est que je ne dispose d'aucun élément pour le débug.

Bonjour,

faut savoir que ce ne va pas changer grand chose dans le sens ou si un robot de OVH (Okiller ou qu’importe son nom) détecte un fichiers/comportent anormale sur un mutualisé c'est le mutualisé au complet qui est verrouiller pour "limiter la casse".

C'est pour ça qu'il est conseillé d'avoir un site ""critique"" sur une offre rien que pour lui et de mettre les "sites à côté", sur un autre pack mutualisé.

Pourquoi verrouiller au complet et pas juste le dossier ?
Simple l'attaquant peu infiltrer les fichiers à n'importe quel niveau comme si il avait un accès FTP, sauf qu'il fait via PHP, donc il peut infecter d'autre multisite ce qui rend le verrouillage par doser inopérant.

Cordialement, janus57