Jump to content

Hack Prestashop sur la page de paiement - nettoyage


Eolia

Recommended Posts

  • 3 weeks later...

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.

  • Like 1
Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 !

 

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

@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 by kerlin (see edit history)
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 by arm15 (see edit history)
Link to comment
Share on other sites

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 😉

Link to comment
Share on other sites

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

 

Link to comment
Share on other sites

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 ?

6.png

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

Link to comment
Share on other sites

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 by arm15 (see edit history)
Link to comment
Share on other sites

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 ?

Link to comment
Share on other sites

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

Link to comment
Share on other sites

  • razaro pinned this topic
  • 3 weeks later...

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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 by JLCH (see edit history)
Link to comment
Share on other sites

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

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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 by JLCH (see edit history)
Link to comment
Share on other sites

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)

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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)

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 ?

Link to comment
Share on other sites

  • 2 weeks later...

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'est lié au fait que la version 1.7.8.8 soit sortie il y a peu de temps ?
Merci pour tes précisions !

Link to comment