Hack Prestashop sur la page de paiement - nettoyage

[Eolia]

Concernant le dernier hack #prestashop en cours, voici un script de contrôle et de nettoyage (Ouvrez le zip, prenez le fichier cleaner.php et placez-le à la racine de votre site, puis appelez-le avec cette url: https://votresite.com/cleaner.php)

Ce script a été écrit principalement pour cibler le hack en cours mais il contrôle également l'intégrité générale de votre boutique.

Il est fortement conseillé de l'appeler régulièrement pour vérifier que tout est ok.

Le script se met à jour automatiquement à chaque appel si une nouvelle version est disponible.

Il est conseillé de passer votre boutique en maintenance ou mode catalogue si elle est infectée. Une fois les nettoyages terminé et les fichiers restaurés et que toutes les lignes principales sont en vert vous pourrez réactiver votre boutique.

- Script compatible toutes versions Presta

- Support PHP de 5.6 à 8

- Aucun fichier cœur n'est supprimé. Ils sont éventuellement corrigés pour bloquer les infections mais je vous conseille de restaurer les fichiers d'origine (fournis avec le résultat du script)

- Un rapport complet vous est fourni. Exemple sur une boutique bien infectée :

 

Pour rappel, si vous avez des lignes en rouge, corrigez les fichiers au plus vite et modifiez vos mots de passe employés en BO car il y a de fortes chances que ceux-ci aient été récupérés.

cleaner.zip

Autre lien si celui ci-dessus ne fonctionne pas: https://shop.devcustom.net/fr/content/16-nettoyage-hack

Pour rappel, cleaner est intégré dans les versions PhenixSuite : https://eoliashop.com/prestashop-new

Edited March 27, 2023 by Eolia (see edit history)

[bobby4722]

Bonjour,
Merci pour le script que j'avais téléchargé il y a plusieurs semaine, utilisé et qui se mettait à jour tout seul, top !

Ce matin j'ai voulu à nouveau scanner, mais je me retrouve avec un écran qui me dit qu'il va téléchargé la dernière version, puis erreur 500 et j'ai un fichier .php qui apparait à la racine du ftp avec chiffre et lettre dans le nom du fichier.
Et je n'arrive pas à scanner comme d'habitude.

J'ai voulu tenter de scanner car je n'ai plus les e-mails des commandes dans ma boite mail depuis Samedi matin, nous sommes lundi et personne n'a rien touché.
Je me suis dis que potentiellement cela pouvait être une attaque...

Que pensez-vous que cela puisse être concernant le module ?
Merci beaucoup et bonne journée.

[Eolia]

Bonjour,

Concernant le script, oui, il a beaucoup évolué depuis juillet. Peut-être votre serveur est-il trop limité pour effectuer tous les nouveaux scans.

Vous pouvez-m'envoyer un accès à votre FTP par Message Privé si vous désirez que j'en trouve la raison.

Le nom du script est effectivement encodé aujourd'hui pour éviter les appels de n'importe qui sur celui-ci.

Concernant vos mails il faudrait tester l'envoi des mails depuis le BO pour commencer.

[kerlin]

Eolia, un tout grand merci pour ce script ! Il m'a permis de "sauver" un site en PS1.6.1.11 hacké avec fausse page de paiement. Merci pour ce boulot !!

[bobby4722]

Oui un grand merci à Eolia c'est clair.

En revanche ce hack de la fausse page de paiement est quelque chose qui m'est arrivé le 1re septembre 2020 donc avant l'annonce de Presta en Juillet 2022 !
Ensuite cela s'est reproduit plusieurs fois.
Des fichiers étaient modifiés avec des base64 donc la seule solution pour moi c'était d'apprendre comment fonctionnait SSH un minimum et ensuite de scanner mon site avec pour instruction de trouver les lignes contenant: base64_decode.
Une fois trouvé, je remplaçait les fichiers à la main. @Doekia m'a ensuite aidé à retirer ce qui pouvait ouvrir des portes.
Mais effectivement le script de Eolia aide bien dans la continuité car j'avais des fichiers sur ma 1.6.1.26 qui n'étaient pas corrigés.
Ce que je ne comprends pas c'est que cela soit resté des années avec aucune solution avant que Eolia en propose une même si c'est tout à son honneur.
Un grand bravo encore.

[Eolia]

L'annonce de Presta en Juillet 2022 n'a rien à voir.

Un site a été infecté et en recherchant quelqu'un a trouvé la faille XSS mais cela ne concernait pas le hack effectivement.

Il se sont arrêtés sur ce point (qui ne concerne pas beaucoup de shops vu que pour que l'injection soit possible, il fallait activer l'option de cache en SQL, ce que personne ne fait généralement) et n'ont pas cherché plus loin même si on les a prévenus.

Il faut savoir que depuis que Prestashop a été racheté par les italiens et qu'ils ont viré tous les français du staff, pas mal de choses ont changé...

[kerlin]

J'ignorais que PS avait été racheté !! Par des Italiens !! Pauvre France, tout fout le camp !

En ce qui concerne les piratages, je dois avouer qu'à côté de Worpdress, PS avait l'air d'être mieux sécurisé. En tout cas, jusqu'à présent, à part les faux mails envoyés via le formulaire de contact ou similaire, je n'avais encore jamais vu d'attaque du style de la fausse page de paiement ... heureusement sur un site où les ventes ne sont pas nombreuses ...

[Mediacom87]

Il y a 12 heures, kerlin a dit :

En ce qui concerne les piratages, je dois avouer qu'à côté de Worpdress, PS avait l'air d'être mieux sécurisé. En tout cas, jusqu'à présent, à part les faux mails envoyés via le formulaire de contact ou similaire, je n'avais encore jamais vu d'attaque du style de la fausse page de paiement ... heureusement sur un site où les ventes ne sont pas nombreuses ...

PrestaShop est rarement en cause sur les hack mais bien les modules tiers et pour la plupart ceux provenant de thèmes étrangers.

[Sylv1685]

Bonjour Eolia,
Tout d'abord merci pour tout le travail que tu mets à disposition de la communauté !
Juste pour info, avec la dernière version de ton script cleaner.php sur un serveur pour lequel il y a 2 gigas de RAM par script j'ai le message "La mémoire disponible sur votre serveur (2048M) est insuffisante pour exécuter ce script, veuillez l'augmenter à 512 MB au minimum" pour le faire fonctionner j'ai du supprimer le check sur la mémoire en commentant les lignes suivantes :
/*
@ini_set('memory_limit', -1);
@ini_set('max_execution_time', -1);
$memory = memoryTest();
$ok = ($memory['memory_limit'] == '-1') || ($memory['memory_limit'] >= 512 * 1024 * 1024); // at least 512M?
if(!$ok) {
    die('La mémoire disponible sur votre serveur ('.$memory['display'].') est insuffisante pour exécuter ce script, veuillez l\'augmenter à 512 MB au minimum');
}
*/
Voilà tout....

Bonne journée et encore merci pour ce que tu fais !

 

[Eolia]

pouvez-vous modiifer cette ligne pour voir ce que votre serveur retourne

 

if(!$ok) {

    echo $memory['memory_limit'];
    die('La mémoire disponible sur votre serveur ('.$memory['display'].') est insuffisante pour exécuter ce script, veuillez l\'augmenter à 512 MB au minimum');
}

[Sylv1685]

ça affiche
1024MLa mémoire disponible sur votre serveur (1024M) est insuffisante pour exécuter ce script, veuillez l'augmenter à 512 MB au minimum

Edited September 7, 2022 by Sylv1685 (see edit history)

[Eolia]

La dernière mise à jour doit régler le problème  

 

[Sylv1685]

C'est tout bon ! Encore un grand merci !

[Eolia]

Il y a 6 heures, Mediacom87 a dit :

PrestaShop est rarement en cause sur les hack mais bien les modules tiers et pour la plupart ceux provenant de thèmes étrangers.

Exactement. Je ne me souviens pas que Prestashop (les fichiers cœurs) ai eu une faille grave depuis qu'il existe. Dans tous les cas rencontrés cela venait d'un module tiers ou d'un hébergement multiple (avec par exemple un WP pas à jour qui traine à côté et complètement vérolé)

[bobby4722]

Je pense qu'au vu de la marge qu'ils prennent sur le dos des développeurs des modules vendus via leur store, ils pourraient eux même garantir leur propre solution un peu comme Apple fait pour ses application en vérifiant un minimum...Car je ne sais pas si c'est le cas.
Ensuite celui qui achèterait en dehors tant pis pour lui si quelque chose arrive dans un sens.

[Mediacom87]

à l’instant, bobby4722 a dit :

Je pense qu'au vu de la marge qu'ils prennent sur le dos des développeurs des modules vendus via leur store, ils pourraient eux même garantir leur propre solution un peu comme Apple fait pour ses application en vérifiant un minimum...Car je ne sais pas si c'est le cas.
Ensuite celui qui achèterait en dehors tant pis pour lui si quelque chose arrive dans un sens.

Vaste débat depuis 15 ans.

Et ce point fut abordé auprès du fondateur ou de tous les dirigeants de la société depuis.

[Eolia]

Oui, on l'a toujours réclamé, comme les changelogs détaillés (sécurité, ajout de fonctionnalité, correctifs,...) avant mise à jour.

On avait même demandé qu'ils soient testés et notés suivant des critères (requêtes SQL optimisées, qualité du code PHP, consommation mémoire, intérêt, etc).

Réponse de Prestashop: On n'a pas le temps de tout contrôler (on doit surtout vendre et toucher nos commissions)

Ce qui est contrôlé (de manière automatique et non pas par des humains):

- Conformité du code à la norme PSR2 (ce qui ne change rien concernant la sécurité)

- Pas de liens vers le développeur ou vers son site

- Certaines fonctions interdites ou code obfusqué.

Point barre

[Eolia]

Mise à jour importante (1.0.74) suite à nouvelles détections en cours.

[Mediacom87]

Chez une cliente, j'ai cet affichage et je ne sais pas trop quoi en faire:

[Mediacom87]

bon, j'ai fait le ménage et cela ne s'affiche plus donc pas grave.

[Eolia]

Les noms des fichiers étaient exotiques ?

Je vais rajouter un htmlspecialchars() sur leur chemin  

[arnaudbh]

éolie est d'une grande utilité pour la communauté merci pour le partage.

Merci pour ton aide la dernière fois

[kerlin]

@Eolia,

J'ai mis à jour le script et l'ai relancé sur le clone du site qui avait été hacké (je l'avais donc déjà lancé et fait ce qu'il me préconisait de faire, avec patchage et envoi des fichiers d'orgine, avant de faire les mêmes manips sur le site en prod)

Là, il me sort une liste longue comme le bras de fichiers qui auraient été modifiés (en orange) et surtout dans le dossier d'admin, il me trouve un fichier patch122.php. Je doute qu'il s'agisse d'un fichier créé par le script.
Je le joins à ce post, en .txt

Je me rappelle avoir à un moment installé le script de Doekia qui permettait de stopper les envois de spam via le formulaire de contact. Mais je doute que ce fichier ait quelque chose à voir. Il a l'air d'être pour PS 1.5. Une porte d'entrée ?

 

Merci pour votre avis éclairé 🙂

Edit : le fichier ne passe pas. Voici le code

 <?php
/* This file should be created inside your ADMIN_DIR */
/* Then run the file http(s)://domain.tld/<admindir>/patch122.php */

// Uncomment (remove //) the following line for debug purposes
//@define('_PS_MODE_DEV_', true);

require_once(__DIR__.'/../config/config.inc.php');
if (!version_compare(_PS_VERSION_,'1.5.4.0','>=')) {
    die('Sorry only version since 1.5.4.0 are supported.'.PHP_EOL);
}
$ps_root_dir = _PS_ROOT_DIR_;
(substr($ps_root_dir,-1,1) != '/') && $ps_root_dir .= '/';

if (!file_exists($ps_root_dir.'override/classes/Validate.php')) {
    $content = <<< 'EOF'
<?php
class Validate extends ValidateCore
{
    public static function isCustomerName($name)
    {
        if (preg_match('/www|http/ui', $name)) {
            return false;
        }

        return preg_match('/^(?:[^0-9!<>,;?=+()\/\\@#"°*`{}_^$%:¤\[\]|\.?]|[\.?](?:\s|$))*$/u', $name);
    }
}
EOF;
    file_put_contents($ps_root_dir.'override/classes/Validate.php', $content);
    @unlink($ps_root_dir.'cache/class_index.php');
    echo 'class Validate is now overrided'.PHP_EOL;
}
else {
    echo 'The class Validate is already overrided. You should process manually.'.PHP_EOL;
}

if (!file_exists($ps_root_dir.'override/classes/Customer.php')) {
    $content = <<< 'EOF'
<?php

class Customer extends CustomerCore
{
    /**
     * @see ObjectModel::$definition
     */
    public static $definition = array(
        'table' => 'customer',
        'primary' => 'id_customer',
        'fields' => array(
            'secure_key' =>                array('type' => self::TYPE_STRING, 'validate' => 'isMd5', 'copy_post' => false),
            'lastname' =>                    array('type' => self::TYPE_STRING, 'validate' => 'isCustomerName', 'required' => true, 'size' => 32),
            'firstname' =>                    array('type' => self::TYPE_STRING, 'validate' => 'isCustomerName', 'required' => true, 'size' => 32),
            'email' =>                        array('type' => self::TYPE_STRING, 'validate' => 'isEmail', 'required' => true, 'size' => 128),
            'passwd' =>                    array('type' => self::TYPE_STRING, 'validate' => 'isPasswd', 'required' => true, 'size' => 32),
            'last_passwd_gen' =>            array('type' => self::TYPE_STRING, 'copy_post' => false),
            'id_gender' =>                    array('type' => self::TYPE_INT, 'validate' => 'isUnsignedId'),
            'birthday' =>                    array('type' => self::TYPE_DATE, 'validate' => 'isBirthDate'),
            'newsletter' =>                array('type' => self::TYPE_BOOL, 'validate' => 'isBool'),
            'newsletter_date_add' =>        array('type' => self::TYPE_DATE,'copy_post' => false),
            'ip_registration_newsletter' =>    array('type' => self::TYPE_STRING, 'copy_post' => false),
            'optin' =>                        array('type' => self::TYPE_BOOL, 'validate' => 'isBool'),
            'website' =>                    array('type' => self::TYPE_STRING, 'validate' => 'isUrl'),
            'company' =>                    array('type' => self::TYPE_STRING, 'validate' => 'isGenericName'),
            'siret' =>                        array('type' => self::TYPE_STRING, 'validate' => 'isSiret'),
            'ape' =>                        array('type' => self::TYPE_STRING, 'validate' => 'isApe'),
            'outstanding_allow_amount' =>    array('type' => self::TYPE_FLOAT, 'validate' => 'isFloat', 'copy_post' => false),
            'show_public_prices' =>            array('type' => self::TYPE_BOOL, 'validate' => 'isBool', 'copy_post' => false),
            'id_risk' =>                    array('type' => self::TYPE_INT, 'validate' => 'isUnsignedInt', 'copy_post' => false),
            'max_payment_days' =>            array('type' => self::TYPE_INT, 'validate' => 'isUnsignedInt', 'copy_post' => false),
            'active' =>                    array('type' => self::TYPE_BOOL, 'validate' => 'isBool', 'copy_post' => false),
            'deleted' =>                    array('type' => self::TYPE_BOOL, 'validate' => 'isBool', 'copy_post' => false),
            'note' =>                        array('type' => self::TYPE_HTML, 'validate' => 'isCleanHtml', 'size' => 65000, 'copy_post' => false),
            'is_guest' =>                    array('type' => self::TYPE_BOOL, 'validate' => 'isBool', 'copy_post' => false),
            'id_shop' =>                    array('type' => self::TYPE_INT, 'validate' => 'isUnsignedId', 'copy_post' => false),
            'id_shop_group' =>                array('type' => self::TYPE_INT, 'validate' => 'isUnsignedId', 'copy_post' => false),
            'id_default_group' =>            array('type' => self::TYPE_INT, 'copy_post' => false),
            'id_lang' =>                    array('type' => self::TYPE_INT, 'validate' => 'isUnsignedId', 'copy_post' => false),
            'date_add' =>                    array('type' => self::TYPE_DATE, 'validate' => 'isDate', 'copy_post' => false),
            'date_upd' =>                    array('type' => self::TYPE_DATE, 'validate' => 'isDate', 'copy_post' => false),
        ),
    );

}
EOF;
    file_put_contents($ps_root_dir.'override/classes/Customer.php', $content);
    @unlink($ps_root_dir.'cache/class_index.php');
    echo 'class Customer is now overrided'.PHP_EOL;
}
else {
    echo 'The class Customer is already overrided. You should process manually.'.PHP_EOL;
}
echo 'END'.PHP_EOL;

 

Edited September 8, 2022 by kerlin (see edit history)

[Eolia]

ce fichier avait été proposé par @doekia à l'époque pour éviter les inscriptions avec un http:// dans le prénom ou le nom. Vous avez du oublier l'avoir mis ici.

Effectivement les dernières versions de mon script effectuent une analyse plus profonde, il faut donc contrôler les fichiers modifiés et surtout ceux qui ont été ajoutés.

[arm15]

Bonjour,

dans le script d' @Eolia  j'ai des informations en rouge, que je n'avais pas avant.

 J'ai eu un changement de version de mon thème et mis à part cela, je n'ai pas vraiment eu de gros changements. 

 Je n'ose pas y toucher de peur d'aggraver le problème s'il y a un problème.

 Je joins une capture d'écran.

 Merci

PS : j'utilise la dernière version du script d' Eolia

 

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

[arm15]

[Eolia]

Oui, les analyses sont plus poussées.

Quelle est votre version Presta ?

 

[Eolia]

Alors 1.7.8.6, oui les fichiers controllers/admin ne sont plus pratiquement plus utilisés/présents

[Eolia]

Ce n'est pas de ma faute si Presta n'effectue pas de nettoyage lorsqu'il met à jour ses versions^^

[arm15]

Je ne sais pas si c'est à moi que tu t'adresses @Eolia , mais c'est bien la version 1.7.8.6 de Prestashop que j'utilise.

 Je m'inquiète plus pour ce fichier  .js

PS: faut-il que je vire   les fichiers controllers/admin s'ils ne sont plus utilisés ?

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

[kerlin]

Le 09/09/2022 à 10:57 AM, Eolia a dit :

ce fichier avait été proposé par @doekia à l'époque pour éviter les inscriptions avec un http:// dans le prénom ou le nom. Vous avez du oublier l'avoir mis ici.

Effectivement les dernières versions de mon script effectuent une analyse plus profonde, il faut donc contrôler les fichiers modifiés et surtout ceux qui ont été ajoutés.

Merci pour la réponse. Je me rappelais bien avoir utilisé un script de @doekia mais pas du tout l'avoir mis là. En plus, il me semble qu'il met son nom dans ses scripts, non ?

Oui, la nouvelle version semble bien plus poussée ! il m'a sorti une liste énorme de fichiers ! Vais essayer de comprendre tout ça 😉

[Eolia]

C'est assez simple, le script:

- supprime ou corrige ce qu'il connait comme étant infecté

- indique les fichiers modifiés par rapport aux originaux

- indique les fichiers ajoutés inconnus

- indique les fichiers comportant des risques potentiels

 

[Eolia]

il y a 52 minutes, arm15 a dit :

Je ne sais pas si c'est à moi que tu t'adresses @Eolia , mais c'est bien la version 1.7.8.6 de Prestashop que j'utilise.

 Je m'inquiète plus pour ce fichier  .js

PS: faut-il que je vire   les fichiers controllers/admin s'ils ne sont plus utilisés ?

si ce fichier est dans l'archive de votre version, remplacez-le, sinon, supprimez-le.

[arm15]

Comment puis -je savoir s'il est dans l'archive de ma version. Dans tous les cas, il est bien là.

[Eolia]

il y a 16 minutes, arm15 a dit :

Comment puis -je savoir s'il est dans l'archive de ma version. Dans tous les cas, il est bien là.

C'est une blague ?

C'est comme le Port-salut, c'est écrit dessus:

[arm15]

dsl, je suis vraiment con, je trouve qu'en ce moment, je ne tourne pas rond, c'est grave docteur ?

[arm15]

Bon, j'ai corrigé le fichier .js, plus de souci de ce côté-là.

 Entre temps, j'ai remarqué qu' @Eolia ne chômai pas, une autre version de son script est sortie, la 1.0.78   BRAVO !

 Et pour en revenir à mes fichiers  controllers/admin faut-il les virer vu qu'ils ne sont pas utilisés ? Genre :   public_html/controllers/admin/AdminCmsCategoriesController.php

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

[Eolia]

il y a 10 minutes, arm15 a dit :

 Et pour en revenir à mes fichiers  controllers/admin faut-il les virer vu qu'ils ne sont pas utilisés ? Genre :   public_html/controllers/admin/AdminCmsCategoriesController.php

Oui

[kerlin]

Oui, Eolia est au taquet ! Entre 2 lancements du script pour vérifier si ce que je faisais était ok, une mise à jour ! Merci !!

Bon, donc la précédente allait plus profondément. Et effectivement, elle affiche une longue liste de fichiers qui ne sont plus pareils à ceux de la version idoine. J'ai donc réinjecté les dossiers js, admin, tools, class, controllers, sachant que rien n'avait été modifié pour le site. Fait également la même chose pour des fichiers dans config (sauf bien sûr celui avec mes identifiants ...).
Et bonne nouvelle ! j'avais un très gros souci d'affichage des modules : les onglets à gauche (PS 1.6.1.11) étaient manquants en partie, et les modules installés (et fonctionnels en front) étaient absents. Maintenant, ça y est, onglets et modules réapparaissent ! Ce qui m'était nécessaire car j'avais besoin d'accéder à leurs configurations pour pouvoir installer les versions compatibles de ces modules sur la version 1.7.8.

Sauf que la plupart des modules sont indiqués à installer. Alors qu'ils sont parfaitement fonctionnels en front. J'ai vérifié dans la bdd. Par exemple Stripe. Qui était mis comme non activé (active = 0) alors qu'il apparaît sur la page de commande. Idem pour plein d'autres, que ce soient des modules de PS ou des modules tiers, comme Paypal, etc. Si je clique sur le bouton Installer, il me dit bien entendu qu'ils le sont déjà.
J'ai cherché dans la table de configuration, tout a l'air ok.
D'ousske ça peut bien venir ?

[kerlin]

Au final, j'ai trouvé la solution : dans tous ces modules qui n'apparaissaient pas, il y avait un fichier config_fR.xml à supprimer.

Merci encore 1000 fois à @Eolia car ce hack de la fausse page Paypal est vraiment d'une gravité extrême ! Bon, la page étant très moche et supplantant complètement le panier aant que les gens puissent entrer leurs coordonnées, j'espère que peu ont fait l'erreur d'entrer leurs n° de compte ...

[Histoire de taille]

Bonjour à tous, 

 

J'ai ce resultat, je suis infecté ? 

 

 

 

Contrôle des fichiers admin:

Les fichiers de votre répertoire /admin sont conformes à la version d'origine
 

Contrôle des scripts JS:

Pas de fichier suspect JS detecté => OK
 

Contrôle des images pouvant contenir un script:

Pas de fichier image suspect detecté => OK
 

Contrôle de sécurité sur fichiers indésirables connus:

Aucun fichier indésirable connu trouvé
 

Contrôle sur les fichiers sensibles connus pour être modifiés:

Contrôle de defines.inc.php => OK
Contrôle de Dispatcher.php => OK
Contrôle de Hook.php => OK
Contrôle de FrontController.php => OK
Contrôle de Db.php => OK
Contrôle de Module.php => OK
Contrôle de alias.php => OK
Contrôle de config.inc.php => OK
Contrôle de IndexController.php => OK
Contrôle de smarty_internal_templatebase.php => OK
 

contrôle de sécurité sur les fichiers php coeur:

MD5 INTEGRITY : Fichier php modifié par rapport à la version d'origine. Contenu à contrôler => htdocs/config/smarty.config.inc.phpVoir

MD5 INTEGRITY : Fichier index.php modifié par rapport à la version d'origine. Contenu à contrôler => htdocs/index.phpVoir

 

Recherche de fichiers php ajoutés:

Fichier php inexistant dans la version d'origine. Contenu à contrôler => htdocs/antivirus.phpVoir

Fichier php inexistant dans la version d'origine. Contenu à contrôler => htdocs/cache/Ps_checkout2155AdminContainer.phpVoir

Fichier php inexistant dans la version d'origine. Contenu à contrôler => htdocs/cache/Ps_checkout2155FrontContainer.phpVoir

Fichier php inexistant dans la version d'origine. Contenu à contrôler => htdocs/cache/Ps_checkout2202AdminContainer.phpVoir

Fichier php inexistant dans la version d'origine. Contenu à contrôler => htdocs/cache/Ps_checkout2202FrontContainer.phpVoir

Fichier php inexistant dans la version d'origine. Contenu à contrôler => htdocs/config/settings.inc.phpVoir

Fichier php inexistant dans la version d'origine. Contenu à contrôler => htdocs/defines.inc.phpVoir

Fichier php inexistant dans la version d'origine. Contenu à contrôler => htdocs/mails/fr/lang.phpVoir

Recherche de vulnérabilité sur les modules (à titre d'information, si le module est connu il n'y a à priori pas de risque):

Pas de fonction sensible hors-classe trouvée dans les modules de votre boutique => OK

ANALYSE TERMINÉE

!!! ATTENTION !!! Certains de vos fichiers coeurs ont été modifiés.
Si ces modifications ne sont pas volontaires, nous vous conseillons de comparer les fichiers avec les 2 zips (suspicious_xxxx et Prestashop) et de les restaurer dans leur version d'origine si nécessaire.Télécharger l'archive de votre version d'origine Prestashop 1.6.1.20Télécharger l'archive des fichiers à contrôler INFO: Votre version 1.6 possède la version patchée du répertoire htdocs/**admin**/filemanager

EoliaShop ©Relancer le script

Fichiers de taille supérieure à 300Ko exclus de l'analyse pour éviter le crash du script en défaut mémoire (segmentation fault):
- tools/htmlpurifier/HTMLPurifier.standalone.php (662 Ko)
- tools/tcpdf/fonts/cid0cs.php (447 Ko)
- tools/tcpdf/fonts/cid0jp.php (447 Ko)
- tools/tcpdf/fonts/cid0kr.php (447 Ko)
- tools/tcpdf/fonts/uni2cid_ag15.php (372 Ko)
- tools/tcpdf/tcpdf.php (1052 Ko)
- modules/oney/oney.php (368 Ko)

Si vous pensez que votre serveur peut les analyser, cliquez ci-dessous

[Eolia]

A priori non, vérifiez quand même ces 2 fichiers

MD5 INTEGRITY : Fichier index.php modifié par rapport à la version d'origine. Contenu à contrôler => htdocs/index.php

Fichier php inexistant dans la version d'origine. Contenu à contrôler => htdocs/antivirus.php

[Histoire de taille]

merci pour votre précieux script et vos réponses rapide,

 

Je dois vérifier quoi dans le fichier ? 

 

 

[Eolia]

Envoyez-moi ces 2 fichiers en pièce_jointe (dans un zip) par message privé et je vous dirai s'ils sont ok ou pas.

[Histoire de taille]

je viens de vous les envoyer, par contre c'est format .php

[JLCH]

Bonjour et grandement merci pour votre travail. j'ai deux sites, identiques (sauf le nom de domaine), le script à parfaitement fonctionné sur les deux sites. Puis de nouveau apparition de la page paypal sur l'un des deux site, et page erreur 500 sur le script, même si je remet un nouveau cleaner.php, etc, etc... Je me suis basé au pif sur les erreurs précédentes pour r'enlever la page paypal (des fichiers dans classes/controlers apparemment). mais le script reste désespérément en erreur 500!

 

j'ai cela en bleu par exemple: Fichier php inexistant dans la version d'origine. Contenu à contrôler => site/config/settings.inc.php

Que faire? merci encore

Edited October 26, 2022 by JLCH (see edit history)

[Eolia]

Vous avez des lignes en bleu alors que le script part en erreur 500 ?

[JLCH]

il y a une heure, Eolia a dit :

Vous avez des lignes en bleu alors que le script part en erreur 500 ?

J'ai deux sites identiques, l'un a l'erreur 500, pas l'autre. les ligne bleu sont sur celui ou le script fonctionne, du coup j'applique les modifications du script (sur le site ou il fonctionne), sur le site ou le script est en erreur 500. dsl si je n'ai (ou ne suis) pas été clair;-))

[Eolia]

Erreur 500 en activant le mode debug ?

Pouvez-vous consulter le error.log de votre hébergement ?

[JLCH]

Il y a 12 heures, Eolia a dit :

Erreur 500 en activant le mode debug ?

Pouvez-vous consulter le error.log de votre hébergement ?

Bonjour, c'est votre script (cleaner.php) qui est en erreur 500, pas le site sur lequel est le script! Le mode debug agit sur le script cleaner.php?

[Eolia]

Oui en partie et normalement le script est paramétré pour les afficher aussi.

Dans tous les cas, si erreur 500 il y a forcément une trace dans le error.log de l'hébergement.

[JLCH]

dsl, je n'arrive pas à trouver. par contre, les deux sites sont totalement identiques (sauf l'url), même serveur, même version ps, etc... et même si je réinstalle cleanner.php, sur le 1 ça fonctionne immédiatement, et sur le 2 erreur 500 systématique juste quant il dit "Par sécurité l'url du script a été modifiée..." il passe en erreur 500.

 

puis-je vous envoyer les URL en privé?

 

Merci

[JLCH]

Grand Merci @Eolia, le problème venait de la mémoire serveur trop faible pour exécuter le script. encore merci pour votre temps et savoir.

[JLCH]

bonjour, aujourd'hui j'ai ses lignes qui apparaissent en rouge alors que les fichiers sont exactement ceux du zip source:

Contrôle des scripts JS:

Fichier JS à contrôler => xxx/js/jquery/jquery-1.11.0.min.js

Fichier JS à contrôler => xxx/js/jquery/jquery-migrate-1.2.1.min.js

Fichier JS à contrôler => xxx/js/vendor/d3.v3.min.js

Par contre, j'ai du re-changer le xxx//classes/controller/Controller.php car la fausse page paypal était réapparue!

Et il m'indiquait ce Fichier img infecté trouvé sur votre boutique: xxx/img/XCvZk.png mais je ne le trouve nul part et la ligne à disparue sans rien faire! je viens de voir dans l'email reçu"Fichier xxx/img/XCvZk.png supprimé"

 

Edited November 3, 2022 by JLCH (see edit history)

[Eolia]

il y a 1 minute, JLCH a dit :

Et il m'indiquait ce Fichier img infecté trouvé sur votre boutique: xxx/img/XCvZk.png mais je ne le trouve nul part et la ligne à disparue sans rien faire! je viens de voir dans l'email reçu"Fichier xxx/img/XCvZk.png supprimé"

Normal, le script le copie dans le zip et le supprime.

 

Pour les js la dernière version ne devrait plus vous les remonter (chiffres dans le nom du script)

[JLCH]

merci. c'est pour cela que sur le site BD j'ai:

Fichiers source introuvables pour cette version: 1.6.1.18. Les contrôles md5 ne pourront être effectués.

Contrôle des scripts JS:

Fichier JS à contrôler => bd/js/admin-products.js

Fichier JS à contrôler => xx/js/admin-scene-cropping.js

Fichier JS à contrôler => xx/js/admin-translations.js

Fichier JS à contrôler => xx/js/admin.js

Fichier JS à contrôler => xx/js/admin/addons.js

Fichier JS à contrôler => xx/js/admin/attachments.js

Fichier JS à contrôler => xx/js/admin/attributes.js

Fichier JS à contrôler => xx/js/admin/carrier_wizard.js

Fichier JS à contrôler => xx/js/admin/dashboard.js

Fichier JS à contrôler => xx/js/admin/email.js

Fichier JS à contrôler => xx/js/admin/import.js

Fichier JS à contrôler => xx/js/admin/login.js

Fichier JS à contrôler => xx/js/admin/modules-position.js

Fichier JS à contrôler => xx/js/admin/notifications.js

Fichier JS à contrôler => xx/js/admin/orders.js

Fichier JS à contrôler => xx/js/admin/price.js

Fichier JS à contrôler => xx/js/admin/products.js

Fichier JS à contrôler => xx/js/admin/scenes.js

Fichier JS à contrôler => xx/js/admin/themes.js

Fichier JS à contrôler => xx/js/adminImport.js

Fichier JS à contrôler => xx/js/admin_carrier_wizard.js

Fichier JS à contrôler => xx/js/admin_order.js

Fichier JS à contrôler => xx/js/audio.js

Fichier JS à contrôler => xx/js/cropper/builder.js

Fichier JS à contrôler => xx/js/cropper/cropper.js

Fichier JS à contrôler => xx/js/cropper/dragdrop.js

Fichier JS à contrôler => xx/js/cropper/loader.js

Fichier JS à contrôler => xx/js/cropper/prototype.js

Fichier JS à contrôler => xx/js/cropper/scriptaculous.js

Fichier JS à contrôler => xx/js/fileuploader.js

Fichier JS à contrôler => xx/js/hookLiveEdit.js

Fichier JS à contrôler => xx/js/retro-compat.js.php

Fichier JS à contrôler => xx/js/tools.js

Fichier JS à contrôler => xx/js/validate.js

Fichier JS à contrôler => xx/js/vendor/ladda.js

[Eolia]

Bizarre car le md5 existe^^

https://md5.enter-solutions.com/json/1.6.1.18.json

[JLCH]

en effet!

[TonFairePart]

J'ai ajouter le script, j'ai une ligne en rouge, cela veux dire quoi ? 

 

Contrôle des scripts JS:

MD5 ADMIN WARNING : Fichier différent de l'original => public_html/js/admin/tinymce.inc.js

[Eolia]

Ca veut dire qu'il n'est pas comme celui d'origine.

Il faut donc les comparer pour voir ce qui est différent.

[TonFairePart]

34 minutes ago, Eolia said:

Ca veut dire qu'il n'est pas comme celui d'origine.

Il faut donc les comparer pour voir ce qui est différent.

Merci, rien à signaler pour ma boutique. Un grand merci pour ton script.

 

 

[crealp]

Bonjour Eolia ,
Vous êtes génial, Un grand merci pour le script, super, par contre le hackeur sévis toujours sur mon site, il arrive toujours à modifie le fichier dans /classes/controller/Controller.php.
version Presta 1.6.1.24
Avez vous une solution? Encore merci
Bien Cordialement, Daniel

[Eolia]

Avez-vous contrôlé le code de tous les modules étant marqué comme éventuellement à risque ?

Avez-vous restauré tous les fichiers non conformes ?

Avez-vous vérifié que personne n'aurait des codes d'accès ftp qui trainent ?

Avez-vous un autre cms sur le même hébergement ? (Wordpress ou autre)

[crealp]

Oui j'ai contrôlé tous les modules étant marqué à risque, il n'y a que /classes/controller/Controller.php

restauré tous le fichier /classes/controller/Controller.php

J'ai changé les codes d'accès ftp

Oui j'ai un autre cms sur le même hébergement.

[Eolia]

Mon script ne peut pas contrôler les autres cms s'ils sont infectés.

Il est préférable de les mettre dans des espaces distincts (dossiers racine au même niveau que /www et non en dessous) pour empêcher de passer de l'un à l'autre.

[crealp]

Ok, je vous remercie, je vais vérifier tous cela, encore merci, je vous souhaite une belle journée.

[Bertrand57]

Bonjour,

Merci pour ce script @Eolia

Dans "Recherche de fichiers php ajoutés", le script trouve :
Fichier php inexistant dans la version d'origine. Contenu à contrôler => www/config/settings.inc.old.php
Fichier php inexistant dans la version d'origine. Contenu à contrôler => www/config/settings.inc.php
Fichier php inexistant dans la version d'origine. Contenu à contrôler => www/config/settings.old.php

Ces fichiers settings ne sont pas utiles à Prestashop (1.6) ?

Merci

[Mediacom87]

il y a 3 minutes, Bertrand57 a dit :

Fichier php inexistant dans la version d'origine. Contenu à contrôler => www/config/settings.inc.php

Indispensable, mais absent de l'archive d'origine, cela fut déjà expliqué précédemment, ce fichier n'est généré qu'à l'installation, donc à conserver.

[JLCH]

il y a 45 minutes, Mediacom87 a dit :

Indispensable, mais absent de l'archive d'origine, cela fut déjà expliqué précédemment, ce fichier n'est généré qu'à l'installation, donc à conserver.

merci.

[Bertrand57]

15 hours ago, Mediacom87 said:

Indispensable, mais absent de l'archive d'origine, cela fut déjà expliqué précédemment, ce fichier n'est généré qu'à l'installation, donc à conserver.

Merci, je n'avais pas vu les précédentes explications.

Par contre, les versions old et .bck ne représentent pas d'intérêt ?

[fourmiX]

Merci Eolia 👍

[yoyo64]

MERCI

[Sylv1685]

Bonjour ,
Tout d'abord un grand merci Eolia pour tout ce travail au service de la communauté prestashop !
Je viens de lancer le script sur une 1.7.8.8 et ça me dit tout ça en rouge :

Fichiers source introuvables pour cette version: 1.7.8.8. Les contrôles md5 ne pourront être effectués.

Contrôle des scripts JS:

Fichier JS à contrôler => www/js/admin.js

Fichier JS à contrôler => www/js/admin/addons.js

Fichier JS à contrôler => www/js/admin/attachments.js

Fichier JS à contrôler => www/js/admin/carrier_wizard.js

Fichier JS à contrôler => www/js/admin/dashboard.js

Fichier JS à contrôler => www/js/admin/email.js

Fichier JS à contrôler => www/js/admin/import.js

Fichier JS à contrôler => www/js/admin/login.js

Fichier JS à contrôler => www/js/admin/modules-position.js

Fichier JS à contrôler => www/js/admin/notifications.js

Fichier JS à contrôler => www/js/admin/price.js

Fichier JS à contrôler => www/js/admin/products.js

Fichier JS à contrôler => www/js/admin/themes.js

Fichier JS à contrôler => www/js/admin/tinymce_loader.js

Fichier JS à contrôler => www/js/cropper/builder.js

Fichier JS à contrôler => www/js/cropper/cropper.js

Fichier JS à contrôler => www/js/cropper/dragdrop.js

Fichier JS à contrôler => www/js/cropper/loader.js

Fichier JS à contrôler => www/js/cropper/prototype.js

Fichier JS à contrôler => www/js/cropper/scriptaculous.js

Fichier JS à contrôler => www/js/fileuploader.js

Fichier JS à contrôler => www/js/retro-compat.js.php

Fichier JS à contrôler => www/js/tools.js

Fichier JS à contrôler => www/js/validate.js

Fichier JS à contrôler => www/js/vendor/bower.json

Fichier JS à contrôler => www/js/vendor/ladda.js

J'imagine que c'e