Jump to content

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


Recommended Posts

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...

Share this post


Link to post
Share on other sites

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.

  • Thanks 1

Share this post


Link to post
Share on other sites

Posted (edited)
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 by Eolia (see edit history)
  • Like 1

Share this post


Link to post
Share on other sites

Posted (edited)

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.

image.thumb.png.6d3a19099cf0398c484bfac2a6db556b.png

Edited by gusman126 (see edit history)
  • Like 1

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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 ;) 

  • Like 3
  • Thanks 4

Share this post


Link to post
Share on other sites

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 😁)

  • Like 1

Share this post


Link to post
Share on other sites

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.

  • Like 2

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

Posted (edited)
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 by Prestasec (see edit history)

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Posted (edited)

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

image.png.d6285974ba1165c9713f4f240c7017c3.png

Edited by BOUQUINS (see edit history)

Share this post


Link to post
Share on other sites

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

image.png.d6285974ba1165c9713f4f240c7017c3.png

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)

  • Like 2

Share this post


Link to post
Share on other sites

Posted (edited)

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 by los (see edit history)

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

En 25/7/2022 a las 8:32 AM, Eolia dijo:

La dernière version du script (1.0.15) contrôle /filemanager et propose le patch automatique

Bonjour, quelle est la différence avec ces nouvelles lignes dans le fichier upload.php dans filemanager ?

$targetFile = $targetPath.str_replace(' ', '_', $_FILES['file']['name']);
        $targetFileThumb = $targetPathThumb.str_replace(' ', '_', $_FILES['file']['name']);

Share this post


Link to post
Share on other sites

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.

  • Like 1

Share this post


Link to post
Share on other sites

hace 13 minutos, Eolia dijo:

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.

Cela signifie-t-il plus de sécurité pour notre site ?

Share this post


Link to post
Share on other sites

En 29/7/2022 a las 8:07 AM, Eolia dijo:

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)

Donc les fichiers en orange ne représentent pas un risque ?

Screenshot_75.jpg

Share this post


Link to post
Share on other sites

hace 10 minutos, Eolia dijo:

Faudrait voir ce que contiennent ceux-là:

image.png.3a616d3ef97539b59a10f52ec0e85b00.png

Mais les module de speed_cache, mon Dieu...

Sont-ils trop nombreux pour un seul module ?  😕

Share this post


Link to post
Share on other sites

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

  • Like 1

Share this post


Link to post
Share on other sites

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.

 

2022-08-05_15-22-56.jpg

2022-08-05_15-15-03.jpg

2022-08-05_16-13-07.jpg

Share this post


Link to post
Share on other sites

8 minutes ago, Mediacom87 said:

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

Share this post


Link to post
Share on other sites

Posted (edited)

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 by Bertrand57 (see edit history)

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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 😕

2022-08-05_17-39-35.jpg

2022-08-05_17-37-26.jpg

Share this post


Link to post
Share on other sites

à 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 😕

2022-08-05_17-39-35.jpg

2022-08-05_17-37-26.jpg

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

 

2022-08-05_18-21-54.jpg

Share this post


Link to post
Share on other sites

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.

  • Like 1

Share this post


Link to post
Share on other sites

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 ...

Share this post


Link to post
Share on other sites

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 

2022-08-06_07-52-05.jpg

  • Like 1

Share this post


Link to post
Share on other sites

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 ?

moduleinstall.png

Share this post


Link to post
Share on other sites

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 

2022-08-06_07-52-05.jpg

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 !

2022-08-06_09-12-48.jpg.4f842a220aa700389b97b1c23c679268.jpg

Un png qui date de l'apparition du hack ! une fois renomé en .png1 plus de script ... !!!!!!!
contenu du PNG :
image.thumb.png.1a56d08d3b8f5b43a2ab418ce3f7c1db.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.

 

  • Like 2

Share this post


Link to post
Share on other sites

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 !

2022-08-06_09-12-48.jpg.4f842a220aa700389b97b1c23c679268.jpg

Un png qui date de l'apparition du hack ! une fois renomé en .png1 plus de script ... !!!!!!!
contenu du PNG :
image.thumb.png.1a56d08d3b8f5b43a2ab418ce3f7c1db.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 !

 

  • Like 1

Share this post


Link to post
Share on other sites

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 ?

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

297596567_384459740484232_2894985360939425310_n.png

Share this post


Link to post
Share on other sites

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à.

2022-08-06_12-34-37.jpg

Share this post


Link to post
Share on other sites

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

  • Like 1

Share this post


Link to post
Share on other sites

Posted (edited)
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 by crazyben (see edit history)

Share this post


Link to post
Share on other sites

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 

  • Like 1

Share this post


Link to post
Share on other sites

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.

 

2022-08-05_15-15-03.jpg

Share this post


Link to post
Share on other sites

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]

Share this post


Link to post
Share on other sites

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 :
image.thumb.png.ec7deb6143af33995971d91eb6077b82.png

 

zipEolia.zip

Share this post


Link to post
Share on other sites

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 ?

 

Capture d’écran, le 2022-08-08 à 05.05.36.png

Capture d’écran, le 2022-08-08 à 04.40.49.png

Share this post


Link to post
Share on other sites

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

  • Like 2

Share this post


Link to post
Share on other sites