Faille de sécurité prestashop, avez vous recu le mail?

[Don Diego De Lananas]

Bonjour à tous et merci pour vos partages.

Pour information, je viens de trouver ceci dans les logs d'une 1.7.8.3

88.170.108.51 - - [26/Jul/2022:13:17:56 +0200] "GET /blm.php HTTP/1.1" 302 - "-" "python-requests/2.22.0"

Il n'y a que cette ligne contenant blm.php je ne sais pas si c'est réellement une intrusion ou une tentative ratée...

[Mediacom87]

Cela ressemble à une tentative échouée puisqu'on a la redirection 302 (cela serait bien de configurer votre boutique en 301 plutôt) qui indique que le fichier n'est pas trouvé et l'appel fut redirigé, j'imagine vers page introuvable de votre installation.

Dans les mois qui viennent, certainement que tous les sites utilisant PrestaShop seront touchés par ce genre de tentative.

[gusman126]

Video para que vosotros padais comprobar que vuestra tienda prestashop esta correcta y sin riesgo 
https://drive.google.com/file/d/1gCRiEoboWFc14U9-A2j-ulfHG1BvGtaT/view?usp=sharing
https://devcustom.net/public/scripts/cleaner.zip

 

Muchas gracias @Eolia

[Eolia]

Il y a 3 heures, SAKSCM a dit :

Bonjour,

Désolé pour la traduction, je ne parle pas français et j'utilise le google translate, j'espère que vous me comprenez bien.

Tout d'abord merci pour le nettoyeur.

J'ai eu un magasin infecté en janvier et il m'a fallu 6 mois (le mois dernier) pour le nettoyer (et un mois après toute cette souffrance tout ça sort, tant mieux pour moi hahaha)

Le magasin en question était un 1.7, le nettoyeur fonctionne également pour cette version ou avec la mise à jour la plus récente, cela vaudra s'il y a une faille (elle n'a pas encore été sautée mais on ne sait jamais)

Dans le reste des prestashops 1.7 (ou 1.6) qui apparemment n'ont pas été infectés, serait-il bon de le transmettre quand même ?

Merci beaucoup pour tout.

salutations

 

Edit : J'ai utilisé correctement le cleaner.php dans ps1.7 (dans plusieurs) et tout est correct

Merci @Eolia pour le scénario

salutations

Je vous conseille de l'utiliser pour toutes les versions à partir des 1.6.

Ce script applique des patchs préventifs.

La prochaine version va corriger smarty.config.inc.php

Edited July 28, 2022 by Eolia (see edit history)

[gusman126]

Otro modulo infectado "Configuration serveur" en esta ocasión de @Mediacom87

Aviso de cleaner.php

#Fonction sensible à contrôler: eval($_ => modules/serverconfiguration/serverconfiguration.php

No estoy diciendo que es una puerta, estoy diciendo que ha sido modificado, añadiendo gb.php como virus.

Edited July 28, 2022 by gusman126 (see edit history)

[Mediacom87]

Ce problème, à ma connaissance, n'est pas lié à mon module, mais il semble que mon module soit ciblé, certainement parce qu'il est gratuit et diffusé.

Le code est disponible ici, n'hésitez pas à le décortiquer et si vous trouvez une faille à m'en informer.

[gusman126]

hace 5 minutos, Mediacom87 dijo:

Ce problème, à ma connaissance, n'est pas lié à mon module, mais il semble que mon module soit ciblé, certainement parce qu'il est gratuit et diffusé.

Le code est disponible ici, n'hésitez pas à le décortiquer et si vous trouvez une faille à m'en informer.

Tu modulo es perfecto, no es problema de tu modulo

Solo indico que la infección a encontrado tu modulo y lo ha modificado.

El codigo original es correcto, por eso he puesto captura de pantalla

Disculpa , no quiero culpar a tu modulo, es correcto el original, pero se han aprovechado y añadido , como si fuera otro por ejemplo onepagecheckout, o megaproduct o cualquier otro de la lista que habeis realizado

-------------

Votre module est parfait, ce n'est pas un problème de votre module

J'indique seulement que l'infection a trouvé votre module et l'a modifié.

Le code d'origine est correct, c'est pourquoi j'ai mis une capture d'écran

Excusez-moi, je ne veux pas blâmer votre module, l'original est correct, mais ils ont été utilisés et ajoutés, comme s'il s'agissait d'un autre, par exemple onepagecheckout, ou megaproduct ou tout autre de la liste que vous avez faite

[Eolia]

La dernière version (1.0.20) patche smarty.config.inc.php (la possible injection SQL décrite par Prestashop) et fourni un zip des fichiers à contrôler

Enjoy  

[docmusicstation]

le script se lance et reste bloqué sur demarrage ...  avec firefox 

Passé sur Edge et la le script fonctionne bien

Edited July 28, 2022 by docmusicstation (see edit history)

[Eolia]

Vous devez avoir des addons dans votre Firefox car vous êtes le 1er à me remonter ce souci.

[magicbel]

Il y a 3 heures, Eolia a dit :

Vous devez avoir des addons dans votre Firefox car vous êtes le 1er à me remonter ce souci.

J'te confirme, ça tourne sous Firefox.

Merci pour ton/votre taff (sachant pas si Doekia était de la partie aussi 😁)

[Mediacom87]

Il y a 6 heures, gusman126 a dit :

Excusez-moi, je ne veux pas blâmer votre module, l'original est correct, mais ils ont été utilisés et ajoutés, comme s'il s'agissait d'un autre, par exemple onepagecheckout, ou megaproduct ou tout autre de la liste que vous avez faite

Je ne me suis pas offusqué du tout, je cherche toujours à faire des modules de qualité et comme tout le monde, je peux faire des erreurs et les corriger pour m'améliorer et apprendre.

Il semble que PrestaShop va devenir une cible de choix ses prochaines semaines, car même les banques ont informé leurs clients concernant e problème, donc il faut prendre tout cela très au sérieux.

[Mediacom87]

J'ai passé le script sur le site d'un client en 1.6.1.23.

Sur ce site, j'avais implanté le correctif de validation des noms des comptes client qui a disparu suite au passage du script, ce qui est normal puisque ce fichier cœur ne correspondait plus à la version installée.

Il est donc primordial de rappeler que toute modification d'un fichier cœur se fait par un override sur 1.6.

[Eolia]

il y a 40 minutes, Mediacom87 a dit :

J'ai passé le script sur le site d'un client en 1.6.1.23.

Sur ce site, j'avais implanté le correctif de validation des noms des comptes client qui a disparu suite au passage du script, ce qui est normal puisque ce fichier cœur ne correspondait plus à la version installée.

Il est donc primordial de rappeler que toute modification d'un fichier cœur se fait par un override sur 1.6.

Quel script ?

Le mien ne supprime rien concernant ces classes mais indique qu'il n'est pas original.

[Prestasec]

49 minutes ago, Mediacom87 said:

Ik heb het script op de site van een klant uitgevoerd in 1.6.1.23.

Op deze site had ik de patch geïmplementeerd voor het valideren van de namen van klantaccounts die verdwenen na de passage van het script, wat normaal is omdat dit kernbestand niet langer overeenkwam met de geïnstalleerde versie.

Het is daarom essentieel om te onthouden dat elke wijziging van een kernbestand wordt gedaan door een overschrijving op 1.6.

 

 

En effet, j'ai testé avec 1.6.1.17, 1.6.1.23 et 1.6.1.24 Et il ne remplace aucun de ces fichiers. Il mentionne seulement qu'il y a des différences (ce que j'ai fait moi-même).

Indeed, i have tested with 1.6.1.17, 1.6.1.23 and 1.6.1.24

And it does not replace any of those files. It only mentions that there are differences (which i have done myself).

Edited July 29, 2022 by Prestasec (see edit history)

[Mediacom87]

il y a 59 minutes, Eolia a dit :

Quel script ?

Le mien ne supprime rien concernant ces classes mais indique qu'il n'est pas original.

Oups, j'ai peut-être fait la bêtise tout seul alors manuellement comme un grand.

Tu me rassures grandement, mais comme quoi, j'ai bien perdu le bénéfice de mes deux semaines de vacances en rentrant en pleine crise LOL

[Prestasec]

4 minutes ago, Mediacom87 said:

Oeps, misschien deed ik het stomme ding alleen en dan handmatig als een volwassene.

Je stelt me enorm gerust, maar zoals wat, ik verloor het voordeel van mijn twee weken vakantie toen ik midden in een crisis terugkeerde LOL

 

Oui ne t'en fais pas. Quiconque connaît les problèmes de sécurité de prestashop en est stressé. Heureusement, mes sites n'ont pas été compromis. En fait, j'hésitais à utiliser le script de nettoyage. Parce que j'étais déjà sûr à 95% que mes sites n'étaient pas concernés. J'ai exécuté le script de nettoyage hier et il a souligné quelques problèmes mineurs. Le script est très instructif et je peux maintenant le recommander à tout le monde. Je m'interroge sur cette ligne bien que dans l'original 1.6.1.24 ligne 37 (ça ne semble pas bon).

|| strpos($_POST['url'], 'http://featherfiles.aviary.com/') !== 0

https://github.com/PrestaShop/PrestaShop/blob/1.6.1.24/admin-dev/filemanager/ajax_calls.php

 

Yes dont worry about it. Anyone who knows about the prestashop security problems is stressed about it. 

Luckily my sites where not compromised. Actually i was hesitant to use the cleaner script. Because i already was sure for 95% that my sites where not afffected. 

I Did run the cleaner script yesterday and it pointed out some minor issues. The script is very informative and i can now recomment it to anyone. 

I wonder about this line though in original 1.6.1.24 line 37 (It does not seem good).

|| strpos($_POST['url'], 'http://featherfiles.aviary.com/') !== 0

https://github.com/PrestaShop/PrestaShop/blob/1.6.1.24/admin-dev/filemanager/ajax_calls.php

[Eolia]

Cette ligne était dans le code original mais n'est plus à utiliser (le site n'existe plus, c'était une banque d'images)

[Eolia]

Pour tout dire, Presta avait piqué le code à Joomla il y a 10 ans sans jamais vraiment l'analyser^^

[BOUQUINS]

Bonjour

Un grand merci à tous pour votre aide !

J'ai utilisé le script de nettoyage d'Eolia et à priori pas de problème chez moi.

Voici le résultat. Que dois-je faire avec les lignes en orange ?

Je suis en version presta 1.7.6.4

Edited July 29, 2022 by BOUQUINS (see edit history)

[Mediacom87]

Il y a 1 heure, BOUQUINS a dit :

Voici le résultat. Que dois-je faire avec les lignes en orange ?

J'aborde le sujet dans cet article : https://www.mediacom87.fr/comment-se-premunir-du-piratage-sur-prestashop-et-thirty-bees/

[Eolia]

Il y a 2 heures, BOUQUINS a dit :

Bonjour

Un grand merci à tous pour votre aide !

J'ai utilisé le script de nettoyage d'Eolia et à priori pas de problème chez moi.

Voici le résultat. Que dois-je faire avec les lignes en orange ?

Je suis en version presta 1.7.6.4

Tout est ok.

Pour les fichiers en orange, pas de risque, ce sont soit les fichiers principaux du module soit des fichiers inclus dans une classe. Aucun de ces fichiers ne sont appelables directement depuis l'extérieur.

Le script ne peut pas effectuer cette distinction simplement (il faudrait parser l'intégralité et voir si ces fonctions sont incluses dans une classe)

[docmusicstation]

21 hours ago, Eolia said:

Vous devez avoir des addons dans votre Firefox car vous êtes le 1er à me remonter ce souci.

Oui j'ai un bloqueur de pop up

Edited July 29, 2022 by docmusicstation (see edit history)

[yama]

Ceux qui ont le module stripejs, mettez-le a jour immediatement en 4.5.2

[los]

Bonjour,

Merci à tous et particulièrement @Eolia et @Mediacom87 pour votre aide.

Je ne suis malheureusement pas expert en sécurité et j'aimerais avoir votre avis. En suivant vos conseils, je suis tombé sur ce fichier  :

if (!defined('_PS_VERSION_'))
    exit;
function upgrade_module_1_1_6($object)
{
    $object->regexTemplates();

    Configuration::deleteByName('PA_CAPTCHA_TMP_CONTACT');
    Configuration::deleteByName('PA_CAPTCHA_TMP_LOGIN');
    Configuration::deleteByName('PA_CAPTCHA_TMP_RE_PASSWORD');

    uninstallModuleInGDPR($object);

    if ($object->getOverrides() != null) {
        $dir = realpath(dirname(__FILE__) . '/../') . '/override/controllers/front/';
        $classes = array(
            'Auth',
            'Contact',
            'Password'
        );
        foreach ($classes as $class){
            beforeUninstallOverride($dir, $class);
        }
        $object->uninstallOverrides();
        try {
            foreach ($classes as $class) {
                beforeInstallOverride($dir, $class);
            }
            $object->installOverrides();
        } catch (Exception $e) {
            $object->_errors[] = $e->getMessage();
        }
    }

    return count($object->_errors) > 0 ? false : true;
}

function uninstallModuleInGDPR($object)
{
    if (Module::isInstalled('psgdpr') && $object->id) {
        if ($gdpr = Db::getInstance()->getRow('
            SELECT id_module, id_gdpr_consent 
            FROM `' . _DB_PREFIX_ . 'psgdpr_consent` 
            WHERE id_module = ' . (int)$object->id
        )) {
            Db::getInstance()->execute("DELETE FROM `" . _DB_PREFIX_ . "psgdpr_consent` WHERE id_module = " . (int)$gdpr['id_module']);
            Db::getInstance()->execute("DELETE FROM `" . _DB_PREFIX_ . "psgdpr_consent_lang` WHERE id_gdpr_consent = " . (int)$gdpr['id_gdpr_consent']);
        }
    }
}

function beforeUninstallOverride($dir, $class)
{
    $rebuild_class_content = preg_replace(
        '#(class\s+' . $class . 'Controller\s+extends\s+' . $class . 'ControllerCore\s+\{)#ms'
        , '$1/*-----start-----*/public function initContent(){parent::initContent();}/*-----end-----*/'
        , Tools::file_get_contents($dir . $class . 'Controller.php')
    );
    @file_put_contents($dir . $class . 'Controller.php', $rebuild_class_content);
}

function beforeInstallOverride($dir, $class)
{
    $rebuild_class_content = preg_replace(
        '#\/\*[-]{5}start[-]{5}\*\/(.*?)\/*[-]{5}end[-]{5}\*\/#ms'
        , ''
        , Tools::file_get_contents($dir . $class . 'Controller.php')
    );
    @file_put_contents($dir . $class . 'Controller.php', $rebuild_class_content);
}

Et ce que de simple fonctions comme celles-ci non encapsulé dans une classe PHP représentent un risque ? 

La réponse est surement évidente, je m'en excuse si c'est le cas.

Merci d'avance,

Los

Edited July 31, 2022 by los (see edit history)

[Eolia]

Déjà

if (!defined('_PS_VERSION_'))
    exit;

Empêche l'exécution en dehors de l'admin.

Ensuite ce sont des fonctions, elles ne peuvent donc pas être appelées directement depuis l'extérieur, il faut passer par une classe avant.

[Eolia]

Ca vire les blancs dans les noms de fichiers.

Car en html le blanc devient %20 et selon comment sont écrits certains modules le fichier nom%20pouet.png ne sera pas trouvé sur le serveur alors que nom_pouet.png le sera.

[Eolia]

Non mais ça évite les bugs d'affichage

[Eolia]

Faudrait voir ce que contiennent ceux-là:

Mais les module de speed_cache, mon Dieu...

[Eolia]

Non mais ils ne sont pas dans un répertoire /classes ou /controller et ne sont pas le fichier principal du module.

[gusman126]

@Eolia 

Edited August 2, 2022 by gusman126 (see edit history)

[Eolia]

Il y a 11 heures, gusman126 a dit :

@Eolia el script actualiza automáticamente la versión de prestashop?

He visto el código, líneas...

 lineas 104 - 106 

echo '<span style="color:red">Votre version doit être mise à jour. Téléchargement de la dernière version et exécution...</span></pre>';

                    sleep(2);

                    $updating = true;

                }

No, solo mi script

[crazyben]

Bonjour,

merci beaucoup pour le script qui a aidé beaucoup de gens, j'avais corrigé le smarty.config.inc.php dès que j'ai reçu le mail de presta.

Cependant aujourd'hui un script est apparu en bas du code source de mes pages, avec un espece d'iframe de faux paiement paypal, ainsi qu'un fichier bbc.php à la racine de mon ftp... Le fichier est bien sur encrypté, je l'ai d'abord vidé pour ne laisser que le <php?>
Puis j'ai uploadé puis installé votre script  et lancé votre script, le site a bien été infecté.

Le fichier module.php étant suspect j'ai checké la derniere ligne et effectivement il y a du code crypté; que j'ai enlevé puis réup le fichier "propre".

J'ai relancé le script, le résultat semblait super clean !

Cependant maintenant sur le front, et sur l'admin, j'ai une erreur 500, le site n'est plus du tout accessible, je n'ai accès plus qu'au script cleaner.php; 
Et au ftp bien sur.
Est ce que je suis le seul à qui ça a pu arriver?
Auriez vous une piste sur laquelle me guider pour remettre le site en ligne?

Presta 1.7.6.1

Par avance merci.
Ben.

 

[Mediacom87]

il y a 11 minutes, crazyben a dit :

j'ai une erreur 500

Vider le cache manuellement : https://www.mediacom87.fr/faq-comment-vider-le-cache-manuellement-sur-prestashop-17/

Activer le mode debug et identifier l'erreur : https://www.prestatoolbox.fr/content/24-messages-erreurs-prestashop

[crazyben]

8 minutes ago, Mediacom87 said:

Vider le cache manuellement : https://www.mediacom87.fr/faq-comment-vider-le-cache-manuellement-sur-prestashop-17/

Activer le mode debug et identifier l'erreur : https://www.prestatoolbox.fr/content/24-messages-erreurs-prestashop

Quel imbécile... à force de chercher compliqué... J'ai complétement zappé de vider le cache ^^'
Merci beaucoup !!!!!!!!

[Bertrand57]

Dans la liste des fichiers de modules à vérifier, tous sont des fichiers principaux de modules ou dans une classe, excepté celui-ci :

#Fonction sensible à contrôler: file_put_contents => modules/paypal/api/paypal_connect.php

Ce fichier représenterait potentiellement un problème ?
Ou alors, comme cela vient de Paypal, on peut considérer qu'ils savent faire des modules bien sécurisés ?

Merci

Edited August 5, 2022 by Bertrand57 (see edit history)

[Mediacom87]

il y a 13 minutes, Bertrand57 a dit :

Ce fichier représenterait potentiellement un problème ?
Ou alors, comme cela vient de Paypal, on peut considérer qu'ils savent faire des modules bien sécurisés ?

Dans tous les cas, on ouvre tous les fichiers et on analyse le code.

Il n'y a pas de raison de faire confiance à quelque code que ce soit si on n'a pas vérifié soit même.

Je suis intervenu sur plusieurs sites depuis la découverte de la faille et je peux vous assurer que même de grands noms du développement ne font pas toujours ce qu'il faut, surtout dans tous les modules fournis avec les thèmes.

[crazyben]

Je suis maudit...

Le script est revenu est ce que ça peut etre du au cache qui est trés trés long à se vider?
J'ai lancé la suppression sur filezilla...

Le code malveillant est toujours en bas de page dans mon code source... 
Le code disparait lorsque je mets la boutique en mode catalogue 😕

[Mediacom87]

à l’instant, crazyben a dit :

Je suis maudit...

Le script est revenu est ce que ça peut etre du au cache qui est trés trés long à se vider?
J'ai lancé la suppression sur filezilla...

Le code malveillant est toujours en bas de page dans mon code source... 
Le code disparait lorsque je mets la boutique en mode catalogue 😕

Non, vous n'êtes pas maudit, mais juste que vous n'avez pas fait le boulot d'analyse de tous les fichiers pouvant ouvrir des portes et vous n'avez donc pas identifié l'accès utilisé par le script.

[crazyben]

Pourtant j'ai checké tous les fichiers en orange, je viens de relancer cleaner.php et le résultat est nikel (sauf les fichiers orange)

Je vais supprimer tous les modules désactivés pour commencer et rechecker tous les fichiers orange.

[crazyben]

18 minutes ago, Mediacom87 said:

Non, vous n'êtes pas maudit, mais juste que vous n'avez pas fait le boulot d'analyse de tous les fichiers pouvant ouvrir des portes et vous n'avez donc pas identifié l'accès utilisé par le script.

J'ai fait un énorme ménage dans les modules car mm désinstallés les dossiers étaient toujours là...

J'ai bien un cleaner.php super clean (résultat ci joint)

J'ai désactivé le cache pour voir, j'attends que filezilla ai bien purgé tous les fichiers, je pense plutôt à un vieux fichier du cache vérolé, avant cette page de paiement paypal s'affichait partout... même en admin !!! Maintenant elle ne s'affiche plus qu'au checkout, donc on a quand même bien avancé, je laisse le site en mode catalogue le temps que filezilla supprime tous les fichiers. J'émets cette hypothèse car le cleaner ne relève plus aucun fichier infecté ou modifié. Je vous tiens au jus, encore merci pour votre aide !

Ben.

 

[Eolia]

Attention cependant, le script ne contrôle pas les thèmes car je ne les connais pas et n'ai pas les sources pour comparer donc si un js malveillant est dans votre thème c'est à vous de checker le répertoire de votre thème en entier.

[crazyben]

9 hours ago, Eolia said:

Attention cependant, le script ne contrôle pas les thèmes car je ne les connais pas et n'ai pas les sources pour comparer donc si un js malveillant est dans votre thème c'est à vous de checker le répertoire de votre thème en entier.

Bonjour, merci pour votre retour,
j'ai entièrement supprimé le theme et uploadé une sauvegarde d'il y a plusieurs mois, et le hack est toujours présent dans le panier
Je ne sais plus trop quelle piste étayer ...

[crazyben]

ReBonjour à tous,

@Eolia @Mediacom87  A tout hasard est ce que vous proposez une prestation de service pour nettoyer le site?
J'ai cherché partout... Je suis résigné, j'ai réup des saves du mois dernier, le script injecté est tjs présent.

Il est chargé après le footer dans le checkout, une fois la page de checkout chargée il y a un petit temps mort, puis le script est lancé, il appel des bibliothèques jquery-3.6.0.min.js et bootstrap et utilise la fonction ReplaceContent ... C'est tout ce que je suis arrivé à trouver... Impossible de voir un JS suspect appelé à partir de la console.

On dirait que le script est en dur dans un des TPL, mais ça me semble fou, car j'ai supprimé tous les fichiers du theme pour réup la save du mois dernier. Le hack est apparu seulement hier. Je n'ai plus d'idée... Je remets le site en catalogue en attendant 

[Gu1llaume]

Merci @Eolia pour le script qui m'a permis de faire un peu de ménage parmi mes modules. J'ai cependant une question : est-il conseillé de laisser ou de supprimer les modules livré par Prestashop "par defaut" qui ne sont pas installés (exemple en fichier joint) sachant qu'ils ne sont pas forcément à jour...

Quelles sont les bonnes pratiques ?

[crazyben]

1 hour ago, crazyben said:

ReBonjour à tous,

@Eolia @Mediacom87  A tout hasard est ce que vous proposez une prestation de service pour nettoyer le site?
J'ai cherché partout... Je suis résigné, j'ai réup des saves du mois dernier, le script injecté est tjs présent.

Il est chargé après le footer dans le checkout, une fois la page de checkout chargée il y a un petit temps mort, puis le script est lancé, il appel des bibliothèques jquery-3.6.0.min.js et bootstrap et utilise la fonction ReplaceContent ... C'est tout ce que je suis arrivé à trouver... Impossible de voir un JS suspect appelé à partir de la console.

On dirait que le script est en dur dans un des TPL, mais ça me semble fou, car j'ai supprimé tous les fichiers du theme pour réup la save du mois dernier. Le hack est apparu seulement hier. Je n'ai plus d'idée... Je remets le site en catalogue en attendant 

Je m'auto réponds, en soupçonnant le favicon.ico (à cause du hack.ico de wordpress) je suis allé voir dans le répertoir /IMG de la racine...

Et là bingo !

Un png qui date de l'apparition du hack ! une fois renomé en .png1 plus de script ... !!!!!!!
contenu du PNG :

 

Je ne sais pas encore par où est appelé le PNG mais j'ai bien avancé, et si ça peut aider les autres, vérifiez votre répertoire /IMG à la recherche de tout fichier suspect.

 

[crazyben]

4 minutes ago, crazyben said:

Je m'auto réponds, en soupçonnant le favicon.ico (à cause du hack.ico de wordpress) je suis allé voir dans le répertoir /IMG de la racine...

Et là bingo !

Un png qui date de l'apparition du hack ! une fois renomé en .png1 plus de script ... !!!!!!!
contenu du PNG :

 

Je ne sais pas encore par où est appelé le PNG mais j'ai bien avancé, et si ça peut aider les autres, vérifiez votre répertoire /IMG à la recherche de tout fichier suspect.

 

 

Je m'auto réponds encore... Désolé.

Une simple recherche une fois qu'on connait le nom du fichier source :

classes/controller/FrontController.php:        Hook::exec('actionOutputHTMLBefore', array('html' => &$html));$html=$this->jschecks($html,"/img/GFgi3.png");
classes/controller/FrontController.php:        $html=$this->jschecks($html,"/img/GFgi3.png");echo trim($html);

Je ne sais pas si ça peut aider à améliorer le script cleaner.php qui apparemment n'avait pas détecté la modif de ce controller ...

Purée ça a été fastidieux mais on y est arrivés! Merci à tous pour votre aide !

 

[Eolia]

il y a 50 minutes, crazyben a dit :

Je m'auto réponds encore... Désolé.

Une simple recherche une fois qu'on connait le nom du fichier source :

classes/controller/FrontController.php:        Hook::exec('actionOutputHTMLBefore', array('html' => &$html));$html=$this->jschecks($html,"/img/GFgi3.png");
classes/controller/FrontController.php:        $html=$this->jschecks($html,"/img/GFgi3.png");echo trim($html);

Je ne sais pas si ça peut aider à améliorer le script cleaner.php qui apparemment n'avait pas détecté la modif de ce controller ...

Purée ça a été fastidieux mais on y est arrivés! Merci à tous pour votre aide !

 

Quelle version Presta svp ?

[Eolia]

Et attention la fonction jschecks n'est pas native donc il doit y avoir d'autres lignes.

C'est curieux car mon script fait un md5 diff de la version

[crazyben]

2 hours ago, Eolia said:

Quelle version Presta svp ?

Presta 1.7.6.1

Comme vous pouvez le voir dans mes messages précédents dès le premier scan le FrontController.php était toujours signalé clean,
En pièce jointe le screen avant que je nettoie le fichier.

[crazyben]

1 hour ago, Eolia said:

Et attention la fonction jschecks n'est pas native donc il doit y avoir d'autres lignes.

C'est curieux car mon script fait un md5 diff de la version

Voici les 3 lignes trouvées et effacées, jschecks n'était présent que dans FrontController.php, je vais relancer une recherche putty pour être sur, mais sur mon dl du ftp complet il ne ressort que là.

[Eolia]

Pouvez-vous m'envoyer un zip de la version hackée svp ?

[gusman126]

hace 5 horas, Eolia dijo:

Pouvez-vous m'envoyer un zip de la version hackée svp ?

+1 me gustaría tener el zip

[Eolia]

zip ou fichier directement, j'aimerai voir comment c'est écrit.

[doekia]

J'ai un sérieux doute sur le site où vous avez utilisé le scanner/cleaner de @Eolia. Le contrôle est fait en utilisant les signatures md5 en provenance directe de prestashop (mis en cache sur un serveur tiers pour des besoin annexe).

Bien que md5 puisse rencontrer des collisions (2 contenus différents ayant la même signature), chercher volontairement cette collision pour une valeur donnée est estimé selon les matheux à calculer 2^64.5 MD5. Même avec 50% de collision dans l'espace des nombres md5, c'est impossible.

 

N'hésitez pas à donner les contenus FrontController et le png associé à @Eolia afin de pouvoir identifier son procédé par reverse-engineering

[crazyben]

6 hours ago, Eolia said:

zip ou fichier directement, j'aimerai voir comment c'est écrit.

Bonjour,
j'ai encore le FrontController.php et le png "infectés", comment est ce que je peux vous les envoyer?

Edit: je ne peux pas vous les mettre dans un post, les fichier sont rejetés. Un wetransfer ?

Edited August 7, 2022 by crazyben (see edit history)

[crazyben]

33 minutes ago, doekia said:

J'ai un sérieux doute sur le site où vous avez utilisé le scanner/cleaner de @Eolia. Le contrôle est fait en utilisant les signatures md5 en provenance directe de prestashop (mis en cache sur un serveur tiers pour des besoin annexe).

Bien que md5 puisse rencontrer des collisions (2 contenus différents ayant la même signature), chercher volontairement cette collision pour une valeur donnée est estimé selon les matheux à calculer 2^64.5 MD5. Même avec 50% de collision dans l'espace des nombres md5, c'est impossible.

 

N'hésitez pas à donner les contenus FrontController et le png associé à @Eolia afin de pouvoir identifier son procédé par reverse-engineering

Bonjour,
j'ai tous les screens horodatés des scans avec cleaner.php , FrontController.php a toujours été signalé clean... Il suffit de regarder mes posts précédents, je ne sais pas de quoi vous doutez, mais je n'ai aucun intérêt à mentir sur quoi que ce soit... Au contraire je partage ce que j'ai trouvé pour aider les personnes qui pourraient être dans le même cas... Le script m'a bien aidé puisqu'il a détecté et nettoyé plusieurs fichiers, et j'ai remercié @Eolia et @Mediacom87 pour leur aide très précieuse à plusieurs reprises. J'ai passé la nuit de vendredi et la matinée de samedi à essayer de régler ce hack, doutez de moi si vous le souhaitez, j'essai juste d'apporter les éléments pour aider les autres et avancer, au cas où ils ne sauraient pas où chercher.
Pour ma part il y a bien eu un souci sur le scan puisque le php a toujours été signalé clean, je ne sais pas pourquoi, ou comment, mais c'est arrivé... screenshots à l'appui. J'ai conservé le FrontController.php et le png dans leurs états "vérolés" et je me ferais un plaisir de les transmettre à @Eolia . 

[doekia]

Je ne parlais pas de mentir, mais de s'être trompé.  Aucun besoin de se sentir attaqué de la sorte.

 

[crazyben]

4 minutes ago, doekia said:

Je ne parlais pas de mentir, mais de s'être trompé.  Aucun besoin de se sentir attaqué de la sorte.

 

Voilà le tout premier scan... Je ne sais pas comment j'aurais pu me tromper... le FrontController.php est bien signalé clean, mon erreur a été de ne pas le controller manuellement de suite.

D'ailleurs le script a bien marché puisqu'avant le faux paypal apparaissait à partir de n'importe quelle page du site... et même à partir de l'admin...
Suite au premier scan et au vidage du cache, le faux paypal n'apparaissait plus que sur le checkout.

J'ai trouvé le code injecté par pur hasard en me souvenant du hack wordpress .ico , et en vérifiant dans l'inspecteur avec l'outil performance tous les éléments chargés après le footer... J'y ai vu le favicon.ico chargé en tout dernier, j'ai donc vérifié le dossier /IMG, et c'est la que je suis tombé sur ce PNG qui n'avait rien a faire là... totalement par hasard... J'ai ensuite lancé une recherche avec le nom du png pour voir où il été appelé :
classes/controller/FrontController.php:        Hook::exec('actionOutputHTMLBefore', array('html' => &$html));$html=$this->jschecks($html,"/img/GFgi3.png");
classes/controller/FrontController.php:        $html=$this->jschecks($html,"/img/GFgi3.png");echo trim($html);

Je sais pas quoi dire d'autre... Pendant tout ce temps le site était en mode catalogue et je bossais sur une version locale que j'ai downloadé de suite après avoir constaté le hack. J'ai fait une recherche putty sur le serveur de prod qui m'a donné le même résultat.

Désolé mais je croyais que vous doutiez de la véracité de mes propos, j'ai essayé de faire les choses consciencieusement, et je souhaite simplement aider.

 

[Eolia]

Il y a 3 heures, crazyben a dit :

Bonjour,
j'ai encore le FrontController.php et le png "infectés", comment est ce que je peux vous les envoyer?

Edit: je ne peux pas vous les mettre dans un post, les fichier sont rejetés. Un wetransfer ?

Mettez-les dans un zip pour les envoyer ici ou sur [email protected]

[crazyben]

9 hours ago, Eolia said:

Mettez-les dans un zip pour les envoyer ici ou sur [email protected]

Voilà, en zip ça passe nikel !

Concernant le FrontController.php tu trouveras le code injecté sur les lignes :
672 à 697
740 à 743

Pour info j'ai réup le php "infecté" sur mon serveur, et relancé un cleaner.php, résultat :

 

zipEolia.zip

[Eolia]

Pour info, la fonction csschecks est à virer aussi^^

[Eolia]

Ces lignes ne sont pas d'origine non plus:

[Eolia]

Certaines versions md5 nous manquaient, l'ensemble a été mis à jour et cleaner.php également en 1.0.21

[gusman126]

Otro fichero modificado por posibles infecciones

classes/Smarty/SmartyCacheResourceMysql.php

[Eolia]

Non, les dernières versions Prestashop possèdent bien ce code, il est natif.

[gtul]

Les lignes "autoupgrade" sont apparues après l'installation du module 1-Click Upgrade, j'ai maintenant désinstallé le module via le BO et les deux premières lignes #MD5 ont disparu, mais les autres plus bas restent. Première image avant la désinstallation du module, deuxième image après.

Pour faire vérifier les lignes oranges, auriez-vous un programmeur à recommander ?

 

[Eolia]

1.0.21 (08/08/2022) - Ajout des dernières versions 1.7 + message d'erreur si md5 absent
1.0.22 / 1.0.23 (08/08/2022) - Ajout d'un contrôle sur fichier images pouvant contenir de l'encodé en base 64
1.0.24 (08/08/2022) - Contrôle des lignes hors-classes pour les fichiers non-conformes au md5

[P i l o u]

Bonjour Eolia,

Sur mon Ps 1.6.1.26, après exécution du script, j'ai eu les Warning suivants:

Pas de fichier suspect type XXXXX.js detecté OK
Contrôle de AdminLoginController.php OK
Contrôle de Controller.php OK
Contrôle de FrontController.php OK
Contrôle de Db.php OK
#MD5 WARNING : Fichier différent de l'original /home/***/public_html/classes/Dispatcher.php
#MD5 WARNING : Fichier différent de l'original /home/***/public_html/classes/Hook.php
Contrôle de IndexController.php OK
Contrôle de Module.php OK
Contrôle de Alias.php OK
Contrôle de smarty.config.inc.php OK
Pas d'include indésirable dans defines.inc.php OK
Contrôle de defines.inc.php OK
Contrôle de smarty_internal_templatebase.php OK
#MD5 WARNING : Fichier différent de l'original /home/***/public_html/classes/Address.php
#MD5 WARNING : Fichier différent de l'original /home/***/public_html/classes/Dispatcher.php
#MD5 WARNING : Fichier différent de l'original /home/***/public_html/classes/Hook.php
#MD5 WARNING : Fichier différent de l'original /home/***/public_html/classes/Tools.php
Lignes hors classe : classes/Tools.php
function cmpPriceAsc($a, $b)
{
    if ((float)$a['price_tmp'] < (float)$b['price_tmp']) {
        return (-1);
    } elseif ((float)$a['price_tmp'] > (float)$b['price_tmp']) {
        return (1);
    }
    return 0;
}

function cmpPriceDesc($a, $b)
{
    if ((float)$a['price_tmp'] < (float)$b['price_tmp']) {
        return 1;
    } elseif ((float)$a['price_tmp'] > (float)$b['price_tmp']) {
        return -1;
    }
    return 0;
}

#MD5 WARNING : Fichier différent de l'original /home/***/public_html/controllers/admin/AdminOrdersController.php
#MD5 WARNING : Fichier différent de l'original /home/***/public_html/controllers/front/ContactController.php
#MD5 WARNING : Fichier différent de l'original /home/***/public_html/controllers/front/OrderOpcController.php
#MD5 WARNING : Fichier différent de l'original /home/***/public_html/controllers/front/ProductController.php

Après avoir remplacé les fichiers nommés par ceux contenus dans l'archive, les warnings apparaissent toujours.

[doekia]

il y a 14 minutes, P i l o u a dit :

Bonjour Eolia,

Sur mon Ps 1.6.1.26, après exécution du script, j'ai eu les Warning suivants:

Pas de fichier suspect type XXXXX.js detecté OK
Contrôle de AdminLoginController.php OK
Contrôle de Controller.php OK
Contrôle de FrontController.php OK
Contrôle de Db.php OK
#MD5 WARNING : Fichier différent de l'original /home/***/public_html/classes/Dispatcher.php
#MD5 WARNING : Fichier différent de l'original /home/***/public_html/classes/Hook.php
Contrôle de IndexController.php OK
Contrôle de Module.php OK
Contrôle de Alias.php OK
Contrôle de smarty.config.inc.php OK
Pas d'include indésirable dans defines.inc.php OK
Contrôle de defines.inc.php OK
Contrôle de smarty_internal_templatebase.php OK
#MD5 WARNING : Fichier différent de l'original /home/***/public_html/classes/Address.php
#MD5 WARNING : Fichier différent de l'original /home/***/public_html/classes/Dispatcher.php
#MD5 WARNING : Fichier différent de l'original /home/***/public_html/classes/Hook.php
#MD5 WARNING : Fichier différent de l'original /home/***/public_html/classes/Tools.php
Lignes hors classe : classes/Tools.php
function cmpPriceAsc($a, $b)
{
    if ((float)$a['price_tmp'] < (float)$b['price_tmp']) {
        return (-1);
    } elseif ((float)$a['price_tmp'] > (float)$b['price_tmp']) {
        return (1);
    }
    return 0;
}

function cmpPriceDesc($a, $b)
{
    if ((float)$a['price_tmp'] < (float)$b['price_tmp']) {
        return 1;
    } elseif ((float)$a['price_tmp'] > (float)$b['price_tmp']) {
        return -1;
    }
    return 0;
}

#MD5 WARNING : Fichier différent de l'original /home/***/public_html/controllers/admin/AdminOrdersController.php
#MD5 WARNING : Fichier différent de l'original /home/***/public_html/controllers/front/ContactController.php
#MD5 WARNING : Fichier différent de l'original /home/***/public_html/controllers/front/OrderOpcController.php
#MD5 WARNING : Fichier différent de l'original /home/***/public_html/controllers/front/ProductController.php

Après avoir remplacé les fichiers nommés par ceux contenus dans l'archive, les warnings apparaissent toujours.

Donnes moi tes urls et infos FTP en DM je vais venir regarder, c'est ma faute de toute manière ...

[P i l o u]

MP envoyé doekia

 

A peine envoyé et déjà corrigé, merci doekia !!

Edited August 8, 2022 by P i l o u (see edit history)

[arm15]

Bonsoir,

 je suis peut -être hors sujet, mais je viens de m'apercevoir que j'avais eu des tentatives de phishing liées avec mon sitemap.xml. 

 Je me suis dit que cela peux peut-être servir à quelqu'un...😏

 Je vous joins une capture :

[Eolia]

Et il y a quoi à l'intérieur de ce fichier s'il existe ?

[arm15]

Ben, heu...Il n'existe pas dans la racine de mon site.

 J'ai ce fichier par contre : sitemap-fr-index.xml

[doekia]

Attention ceci est peut-être une autre attaque connue.

Avez-vous passé le cleaner?

Si oui, a-t-il détecté quelque chose?

Avez vous des lignes parasites dans votre .htaccess

Un autre des attaques connue consiste à répondre sur des contenus introuvables. Sans URL impossible de voir ce qui pourrait être.

[arm15]

J'ai passé le cleaner v 1.0.25, pas de soucis apparemment.

 Par contre, j'ai souvent des pages 404 du genre wp/login.php ou autres, mais qui concernerait + un site WordPress.

 Peut-être est ce dû au fait que mon thème est Warehouse qui est issus du monde de WordPress et que certains hackers pense que je suis sur un W.P.

  Dommage que je n'aie pas de sreenshot à vous montrer là. Car je les supprime systématiquement.

En ce qui concerne mon .htaccess je ne peux pas vous dire s'il y a des lignes parasites, je n'y connais pas grand-chose, mais j'ai dû bloquer un paquet d'adresse IP vu toute les attaque que j'ai. Je peux éventuellement vous l'envoyer par MP...

[Eolia]

Les attaques type wp-login, xlmrpc, backup.log etc sont systématiques sur TOUS les sites en ligne. Ce sont des scripts automatique qui recherchent des failles ou tentent des bruteforce si l'url répond en 200.

Si vous avez un sysadmin demandez-lui de mettre en place des règles fail2ban.

Remplir le .htaccess au-delà d'un certain point finira par ralentir votre site car ce fichier est lu avec recherche de concordance d'IP à CHAQUE APPEL de page

[arm15]

Un sysadmin...kesako ! Je suppose que c'est une personne ayant + de connaissances en la matière que moi. Malheureusement je n'ai personne sous le coude pour faire le job.

Mon .htaccess a un poids de 6 460 ko, je savais aussi que plus j'y met du code dedans, plus cela va ralentir mon site, vu que c'est la 1er fichier qui va être lu.

 Je vous monte sur une note les lignes que j'y ai rajoutées. Bien entendu, ce n'est pas le .htaccess complet.

Je vous joins une capture d'écran de la page 404 de mon B.O.

Edited August 9, 2022 by arm15 (see edit history)

[magicbel]

Comme le stipule Eolia, il est nettement préférable de filtrer avant l'arrivée sur le shop ou le WP. (genre vos Deny/IP)

Pour ceux qui n'ont pas la connaissance (ou pas les moyens de se payer un pro), vous avez par exemple Cloudflare qui permet de "filtrer" les entrées.

Exemple ici avec une limitation sur les accès du /wp-login de Wordpress. (c'est qu'un exemple, c'est pas la seule chose à limiter)

Ceci étant, ça limite drastiquement les bots

 

[sebduc]

Bonjour @Eolia comment récupérer manuellement le fichier 1.0.25 j'ai le message suivant quand je lance le 1.0.18 et rien ne se passe  : 
Warning: file_put_contents(cleaner.php): failed to open stream: Permission denied in /home/www_last/cleaner.php on line 98

Notice: Undefined index: SCRIPT_URI in /home//www_last/cleaner.php on line 100

Script de nettoyage pour boutiques PrestaShop, version 1.0.16

Votre version doit être mise à jour. Téléchargement de la dernière version et exécution...

[Mediacom87]

à l’instant, sebduc a dit :

Bonjour @Eolia comment récupérer manuellement le fichier 1.0.25 j'ai le message suivant quand je lance le 1.0.18 et rien ne se passe  : 

Au même endroit où vous avez téléchargé la première version du script.

[Eolia]

il y a 6 minutes, sebduc a dit :

Bonjour @Eolia comment récupérer manuellement le fichier 1.0.25 j'ai le message suivant quand je lance le 1.0.18 et rien ne se passe  : 
Warning: file_put_contents(cleaner.php): failed to open stream: Permission denied in /home/www_last/cleaner.php on line 98

Notice: Undefined index: SCRIPT_URI in /home//www_last/cleaner.php on line 100

Script de nettoyage pour boutiques PrestaShop, version 1.0.16

Votre version doit être mise à jour. Téléchargement de la dernière version et exécution...

Rechargez le zip, le fichier a été mis à jour.

Vous devez avoir une protection en écriture sur votre serveur

[arm15]

33 minutes ago, magicbel said:

Comme le stipule Eolia, il est nettement préférable de filtrer avant l'arrivée sur le shop ou le WP. (genre vos Deny/IP)

Pour ceux qui n'ont pas la connaissance (ou pas les moyens de se payer un pro), vous avez par exemple Cloudflare qui permet de "filtrer" les entrées.

Exemple ici avec une limitation sur les accès du /wp-login de Wordpress. (c'est qu'un exemple, c'est pas la seule chose à limiter)

 

Ceci étant, ça limite drastiquement les bots

 

 

Merci pour ton aide, mais j'avais essayé. Le problème, c'est que quand je fais des changements dans mon back-office, il faut que je mette à jour tous les caches, celui de Prestashop + Pagecache + Cloudflare.

Je vais créer un nouveau post, car je me rends compte que je suis en train de noyer le post de @Manu-41 

 

[sebduc]

3 minutes ago, Eolia said:

Rechargez le zip, le fichier a été mis à jour.

Vous devez avoir une protection en écriture sur votre serveur

J'ai téléchargé sur le lien au dessus mais ce n'est pas a jour, vous pouvez me dire ou le récupérer?

[Eolia]

La version 1.0.25 a été mise dans le zip.

Au cas où, la voicicleaner.zip

[sebduc]

8 minutes ago, Eolia said:

La version 1.0.25 a été mise dans le zip.

Au cas où, la voicicleaner.zip

Merci ca fonctionne je n'ai rien en rouge!

[Zohaib-fk]

Bonjour,

J'ai utilisé une idée pour savoir si mon compte d'hébergement Web a un nom infecté "blm.php" présent ou non. J'ai utilisé la commande scan directory de PHP pour connaître la liste des fichiers et dossiers à l'intérieur de mon prestashop. Cela m'aidera à connaître la liste des fichiers afin que je puisse rechercher facilement un nom infecté "blm.php" présent ou non

Ajoutez le code ci-dessous dans un nouveau fichier PHP ou téléchargez le fichier joint à la racine du dossier et exécutez le fichier dans un navigateur comme l'URL ci-dessous https://www.votrenomdedomaine.com/sfkscandirectory.php

Ce fichier aidera à connaître la liste des fichiers et des dossiers dans PrestaShop afin que nous puissions trouver facilement les fichiers infectés.

Capture d'écran ci-jointe pour référence

Utilisant également l'accès SSH au serveur Linux, deux commandes Linux "find" pour rechercher le fichier et "grep" pour trouver le contenu du fichier "blm.php" peuvent aider.

grep -R ''MOT-CLE-QUE-VOUS-VOULEZ-TROUVER'' *

grep -R 'blm.php' *

find. -name blm.php

 

 

<?php
/**
* This script help to know list of files and directories inside the folder path.
*/

// upload this file on root of ps and run url in browser https://www.yourdomainname.com/sfkscandirectory.php

function getDirContents($dir, &$results = array()) {
    $files = scandir($dir);

    foreach ($files as $key => $value) {
        $path = realpath($dir . DIRECTORY_SEPARATOR . $value);
        if (!is_dir($path)) {
            $results[] = $path;
        } else if ($value != "." && $value != "..") {
            getDirContents($path, $results);
            $results[] = $path;
        }
    }

    return $results;
}

echo "<pre>";
var_dump(getDirContents('.'));
echo "</pre>";

?>

 

 

sfkscandirectory.zip

[Eolia]

Il y a 4 heures, sebduc a dit :

Merci ca fonctionne je n'ai rien en rouge!

Le bol ! Ca vaut bien une tournée générale alors !

[crazyben]

12 hours ago, Zohaib-fk said:

Bonjour,

J'ai utilisé une idée pour savoir si mon compte d'hébergement Web a un nom infecté "blm.php" présent ou non. J'ai utilisé la commande scan directory de PHP pour connaître la liste des fichiers et dossiers à l'intérieur de mon prestashop. Cela m'aidera à connaître la liste des fichiers afin que je puisse rechercher facilement un nom infecté "blm.php" présent ou non

Ajoutez le code ci-dessous dans un nouveau fichier PHP ou téléchargez le fichier joint à la racine du dossier et exécutez le fichier dans un navigateur comme l'URL ci-dessous https://www.votrenomdedomaine.com/sfkscandirectory.php

Ce fichier aidera à connaître la liste des fichiers et des dossiers dans PrestaShop afin que nous puissions trouver facilement les fichiers infectés.

Capture d'écran ci-jointe pour référence

Utilisant également l'accès SSH au serveur Linux, deux commandes Linux "find" pour rechercher le fichier et "grep" pour trouver le contenu du fichier "blm.php" peuvent aider.

grep -R ''MOT-CLE-QUE-VOUS-VOULEZ-TROUVER'' *

grep -R 'blm.php' *

find. -name blm.php

 

 

<?php
/**
* This script help to know list of files and directories inside the folder path.
*/

// upload this file on root of ps and run url in browser https://www.yourdomainname.com/sfkscandirectory.php

function getDirContents($dir, &$results = array()) {
    $files = scandir($dir);

    foreach ($files as $key => $value) {
        $path = realpath($dir . DIRECTORY_SEPARATOR . $value);
        if (!is_dir($path)) {
            $results[] = $path;
        } else if ($value != "." && $value != "..") {
            getDirContents($path, $results);
            $results[] = $path;
        }
    }

    return $results;
}

echo "<pre>";
var_dump(getDirContents('.'));
echo "</pre>";

?>

 

 

sfkscandirectory.zip 558 B · 0 downloads

Personnellement sur mon site le php ne se nommait pas comme ça mais bbc.php , du coup avec cette méthode vous pouvez croire que vous n'êtes pas infecté, alors qu'en fait le fichier est juste nommé différemment que blm.php .

[gusman126]

@Eolia

Como siempre, muchas gracias por actualizar y optimizar el script, me muestra este error.

Show this error :

Notice: file_get_contents(): read of 8192 bytes failed with errno=21 Is a directory in /var/www/vhosts/numismaticayfilatelia.com/httpdocs/cleaner.php on line 180

[Eolia]

Correctif ajouté dans la 1.0.26 

if(is_file($file)) {

 

[yama]

16 hours ago, Zohaib-fk said:

Bonjour,

J'ai utilisé une idée pour savoir si mon compte d'hébergement Web a un nom infecté "blm.php" présent ou non. J'ai utilisé la commande scan directory de PHP pour connaître la liste des fichiers et dossiers à l'intérieur de mon prestashop. Cela m'aidera à connaître la liste des fichiers afin que je puisse rechercher facilement un nom infecté "blm.php" présent ou non

Ajoutez le code ci-dessous dans un nouveau fichier PHP ou téléchargez le fichier joint à la racine du dossier et exécutez le fichier dans un navigateur comme l'URL ci-dessous https://www.votrenomdedomaine.com/sfkscandirectory.php

Ce fichier aidera à connaître la liste des fichiers et des dossiers dans PrestaShop afin que nous puissions trouver facilement les fichiers infectés.

Capture d'écran ci-jointe pour référence

Utilisant également l'accès SSH au serveur Linux, deux commandes Linux "find" pour rechercher le fichier et "grep" pour trouver le contenu du fichier "blm.php" peuvent aider.

grep -R ''MOT-CLE-QUE-VOUS-VOULEZ-TROUVER'' *

grep -R 'blm.php' *

find. -name blm.php

 

 

<?php
/**
* This script help to know list of files and directories inside the folder path.
*/

// upload this file on root of ps and run url in browser https://www.yourdomainname.com/sfkscandirectory.php

function getDirContents($dir, &$results = array()) {
    $files = scandir($dir);

    foreach ($files as $key => $value) {
        $path = realpath($dir . DIRECTORY_SEPARATOR . $value);
        if (!is_dir($path)) {
            $results[] = $path;
        } else if ($value != "." && $value != "..") {
            getDirContents($path, $results);
            $results[] = $path;
        }
    }

    return $results;
}

echo "<pre>";
var_dump(getDirContents('.'));
echo "</pre>";

?>

 

 

sfkscandirectory.zip 558 B · 0 downloads

Pourquoi faire ? le script de Eolia et Doekia fait le taf correctement

[arm15]

Très jolies ces couleurs dans la version 1.0.27, mais peut-on avoir des explications ?

 

Edited August 10, 2022 by arm15 (see edit history)

[Eolia]

Ben c'est écrit en début de ligne^^

 

[Mediacom87]

il y a 15 minutes, Eolia a dit :

Ben c'est écrit en début de ligne^^

 

Oui, mais pour un novice, il ne sait pas si c'est bien ou pas, sachant que violet n'est pas une couleur indiquant, pour le commun des mortels, un danger ou un truc positif.
Rouge = danger
Vert = pas de soucis
Orange = à surveiller
Bleu = information sans action

[Eolia]

Ok, c'est bleu dans la dernière version

Pour info, ceux qui ont des 1.7 vont avoir beaucoup de lignes dans les adminController car Presta les supprime au fur et à mesure de ses versions mais pas chez les clients en cas d'upgrade.

[SAKSCM]

Hello @Eolia

Again thanks for your code.

I have used it in a few websites updated to last version, with all of them everything was ok, some were giving warnings etc others were cleaned.... but with one, that gave a lot of warnings corrections etc, the website went down giving error 500 in bo and fo i had to recover a backup... why could it happens? i send you the full messages.

Thank you

 

[Eolia]

When 500 error occurs, what's the message in your server error.log ?

This shop is very infected^^

[SAKSCM]

16 minutes ago, Eolia said:

When 500 error occurs, what's the message in your server error.log ?

This shop is very infected^^

I saw 😮 surprisingly it wasnt having the problem with the payment method  

This is the error in the server logs

Thanks, best regards

[gouna]

Merci pour votre aide précieuse