Pages blanche dans FO et BO,

[tom21]

bonjour,

 

dernier jours, j'ai eu des pages blanche dans FO et BO, (selement sur version ps.1.5; ) je deja essayer les astuce que j'ai trouver sur forum mais je ne pas réussi a résoudre le problème , le changement du ('_PS_MODE_DEV_', true) ne reagis pas.

 

hébergeur :  o2switch.fr,

version ps :  ps. 1.5.5  (version 1.4 ça marche correctement)

 

 

merci

[tom21]

j'avance... je trouver une ligne de trop sur plusieurs fichiers il me faut nettoyer toutes les fichier infecter

[DevNet]

Bonjour,

 

Ces lignes en trop vous semblent malicieuses ?

Normalement vous n'avez pas à avoir des modifications dans vos fichiers autres que les modules / thèmes.

 

A+

[tom21]

c'est une ligne codé du type

$ivzrduxrku = '%x7825ff2!>!bssbz)%x5c%x7824]25x78e%x5c%x78b%x5c%x7825w:!>!%x5c%x78246767~6<Cw6<pd%x5c%x7825w6Z6<

[DevNet]

Il s'agit malheureusement d'un code malicieux. Ceci n'annonce pas de bonnes choses.

Cela signifie que vous avez un problème de sécurité sur votre hébergement.

 

Avez-vous un CMS autre que PrestaShop ? comme un blog WordPress par exemple, sur ce même hébergement ?

Avez-vous des plugins / modules, non mis à jour ?

[tom21]

si j'ai aussi une cms joomla (non mise a jour) que j'ai supprimer hier.

vous avais une ide , avec quoi ce décode ce ligne, pour voir en clair, avant que j'efface ?

je deja essayer avec base64 mais ça se décode pas

[DevNet]

Aaaahhh ! joomla ...

 

Vous avez 95% de chance que ça vienne de votre joomla pas à jour.

Maintenant que vous avez ciblé le problème, vérifiez qu'il ne revienne pas, même après la suppréssion de l'autre cms.

 

Si vous avez un accès ssh sur votre hébergement, je peux vous proposer une commande de recherche pour vérifier si ce code malicieux est bien éradiqué sur l'ensemble des fichiers présents sur l'hébergement.

[tom21]

le même problème encore... et cet foi c’est dans toutes les fichiers php

[DevNet]

Vous avez une faille quelque part.

 

Pour cela il vous faut au minimum avoir accès à vos log httpd, afin de les lire et de les analyser. Le point de départ est déjà de prendre une date de modification des fichiers, à 30 min près avant, et de lire tous les logs liés à votre nom de domaine.

 

A+

[tom21]

merci de votre réponse, c'est vraiment sympa de votre part .

 

j'essaye de voir sur ce direction , mais le problème c'est que j'ai plusieurs domaines sur le même compte, je recommencer toute sans les vieux installations que j'ai.

Edited December 27, 2013 by tom21 (see edit history)

[DevNet]

Vous voulez dire que vous avez plusieurs sites web sur un même herbergement principal ?

 

si c'est le cas, je ne voudrais pas vous démoraliser, mais c'est une très mauvaise méthode. La preuve aujourd'hui.

 

Il ne faut surtout pas que les attaques d'injections de codes malicieux puissent impacter les autres sites web.  Votre problème est surement que vous avez plusieurs autres CMS OpenSources en sous-dossier (même si les différents noms de domaines pointes bien respectivement sur eux).

 

Tous vos contenus hebergés possèdent alors les mêmes permissions par défaut, ceux de l'utilisateur web défini par votre hébergeur. Dans le cas d'un hebregement mutualisé de qualité, il dispose d'un utilisateur / groupe unique propre à tout votre répertoire de publication web, qui lui seul a le droit de traiter les demandes de votre httpd (option suEXEC et suPhP). Ce qui siginifie que cet utilisateur est en mesure de manipuler tous les fichiers/dossiers depuis le root de hébergement de publication (soit généralement /www ou /public_html). Tout ce qui se trouve après ce dossier root est donc impactable.

 

Généralement les codes malicieux sont pas "dupe", ils s'attaques aux fichiers très connus : index.php, index.html / .htm, et aussi les fichiers .js

 

L'un des incovénients de l'OpenSource, et la mise en avant de tout. Il est donc facile pour une code malicieux d'évoluer dans un environnement connu (structures de fichiers). C'est pour cela que Joomla est pas très sérieux à ce niveau la.

PrestaShop et WordPress sont très très réactifs et très solides à la base. Mais leur environnement modulaire et ouvert permette la mise en place de modules / plugins, codes personnels, qui peuvent être moins sérieux. Et il suffit d'une seule porte d'entrée pour que tout votre hébergement soit accessible.

 

Dans la plupart des cas, si le même script revient malgrès vos interventions, il s'agit d'un script malicieux non cilbé à votre égard, mais plutôt un script universel automatique, lancé depuis des serveurs / hebergements qui sont eux-mêmes vérollés.

 

Dans tous les cas :

• Vous devez dès aujourd'hui faire un backup de tout ce que vous pouvez (fichiers / base de données)
• Trouver le source de l'injection grace à l'horodatage des modifications des fichiers depuis vos logs http
• Eradiquer le problème pour assanir chaque fichier
• Vérifier dans votre / vos bases de données si les codes malicieux n'y sont pas présents aussi, surtout dans les contenus textes enrichis
• Quand vous avez tout nettoyé, faites une ultime sauvegarde de tout.
• Surveillez au quotidien les logs http, pour traiter le problème à nouveau plus précisement.

Dans tous les cas, c'est un travail très fastidieux et contre productif.

Ca me renvoi à la discussion : http://www.prestashop.com/forums/topic/297280-faut-il-mettre-%C3%A0-jour-la-boutique-%C3%A0-chauqe-mont%C3%A9e-de-version/

 

Je reponds toujours et je persiste : Oui pensez à faire les mises à jours régulièrement, même si vous ne vous estimez pas concerné.

 

A+ et bonne chance pour la suite