Faille de sécurité Prestashop

Corriger la faille de sécurité XsamXadoo sur Prestashop (ép. 92)

Récemment une faille de sécurité a été découverte sur Prestashop. Alors, faut-il s’en inquiéter ? Je vous montre une méthode pour corriger le problème facilement… comme le dit le proverbe « mieux vaut prévenir que guérir ».

Une faille de sécurité dans Prestashop ?

Peut-être que cette nouvelle peut vous surprendre, mais cela n’a rien d’étonnant. Que ce soit dans Prestashop, WordPress ou n’importe quel autre CMS il existera toujours des failles de sécurités (ce sont des cas de figures techniques « vulnérables » qui ont été oubliés ou mal pensés). Le problème c’est quand quelqu’un découvre une nouvelle faille, il peut ensuite l’exploiter à grande échelle sur tous les Prestashop par exemple (ce qui est le cas ici avec le cas du malware XsamXadoo).

Une boutique Prestashop avec une faille de sécurité ne se fait pas forcément hacker

En fait il y a plusieurs raisons à cela, déjà il faut que le « robot/bot » malicieux, trouve votre site (parmi les milliers de Prestashop à travers le monde)… certains ne sont jamais trouvés dans les résultats de Google par le bot malicieux, donc jamais hacké. Il y a aussi une question de temps… parce que parfois le temps que le « robot/bot » vous trouve, il peut se passer 6 mois et tout à coup… BAM l’intrusion se fait à retardement. Dans le cas présent, il faut aussi que le robot puisse trouver des dossiers « phpunit » pour effectuer l’intrusion, si ce n’est pas le cas, alors vous serez épargné (voilà pourquoi certains e-commerçants ont plus de chance que d’autres).

Les vrais Hackers ne font pas crasher votre boutique Prestashop

Le but d’un hacker Prestashop n’est pas forcément de rendre votre boutique inutilisable, bien au contraire… Vous savez ce qui est le mieux ? C’est que vous ne vous rendiez compte de rien… et que par exemple le script injecté par le hacker, récupère vos emails clients, toutes leurs informations (y compris parfois les coordonnées des cartes de crédit)… et cela de manière durable dans le temps. Etre surveillé sans s’apercevoir est certainement la pire des choses (svp respirez, je ne vous entends plus…).

Les CMS Open source sont les plus vulnérables

Pour une fois les solutions e-commerce propriétaire sont avantagées. Et oui en Open source, le code intégral d’une application est accessible et visible au public. Comme on a accès au code, on peut savoir comment sont faits les contrôles / traitements… et du coup, en lisant le code… si on constate qu’il manque un contrôle quelque part on peut s’en servir pour faire une intrusion. Dans les solutions e-commerce propriétaire, on ne sait pas comment fonctionne le code en arrière-plan (parce que personne n’y a accès sauf l’entreprise/éditeur), du coup c’est bien plus complexe à hacker, parce qu’il faut fonctionner par « hypothèse / devinette ».

Soyez plus rapide que les hackers

Vous savez, des grandes banques se font hacker et ne le disent jamais… Aucun système n’est « invulnérable » et même si ça existait vraiment, on peut toujours corrompre facilement l’humain avec de l’argent (oui pourquoi s’agacer avec la technique, l’humain est une faille de sécurité). Mon conseil est donc de faire le contrôle préconisé dans la vidéo et de supprimer les répertoires impactés, puis ensuite de passer à autre chose. Il y aura certainement d’autres failles dans le futur qui seront découvertes… mais pas de quoi s’inquiéter, il y aura toujours des patchs de sécurité.

Pour ce tutoriel Prestashop vous avez à disposition :

  • 1 x script (patch_security.php) pour le nettoyage

Télécharger

Résumé de la vidéo : Evitez de vous faire pirater par le virus XsamXadoo

  • Pour commencer, on va prendre connaissance des recommandations de Prestashop pour appliquer au mieux le correctif.
  • Ensuite, je vous propose un script à intégrer dans vos modules Prestashop afin de faire un nettoyage de l’ensemble des dossiers de votre FTP. On va parcourir brièvement le code et simuler un exemple avec des dossiers présentant la faille de sécurité.
  • Si vous avez des modules que vous n’utilisez pas, supprimez-les (sinon vous vous exposez à un risque d’intrusion à long terme).
  • Si vous voulez faire un scan antivirus plus avancé de votre Prestashop, consultez ce billet cela m’avait beaucoup aidé à l’époque.
  • Chez Infomaniak vous avez un système de SCAN intégré à votre hébergement, ça peut toujours vous servir (en complément) pour vérifier que tout est en ordre.
Notez mon billet, Google va adorer :
1 étoiles - J'aime pas !2 étoiles - Bof !3 étoiles - Bien !4 étoiles - Très bien !5 étoiles - Génial ! (13 votes, moyenne : 5,00 sur 5)
Loading...

29 commentaires sur “Corriger la faille de sécurité XsamXadoo sur Prestashop (ép. 92)”

  1. Bonjour à tous,

    Petite précision, pour ceux qui découvrent la présence de ces répertoires « phpunit », je vous invite ensuite à effectuer une analyse des fichiers modifiés de votre Prestashop sous « Paramètres avancés -> Informations ».

    Par contre, pour cette partie, obligé de faire une analyse manuelle et de comparer avec les fichiers originaux de votre version Prestashop (vous pouvez récupérer une archive sur le site officiel).

    Bonne journée !

  2. Bonjour et merci pour le tuto mis en place dès aujourd’hui.
    En revanche à l’utilisation, je constate une sensibilité à la casse : le script s’occupe bien des phpunit, mais on peut constater après une recherche manuelle qu’il demeure dans les répertoires Prestashop des entrées PhpUnit et Phpunit (principalement dans le module de Navigation à facettes, en tous cas chez moi).
    Je ne sais pas si ces entrées sont susceptibles d’être affectées par la faille de sécurité, ni si elles sont indispensables/nécessaires/superflues/nuisibles… Quelqu’un peut il nous éclairer à ce sujet ? Que doit-on en faire ?

    1. patch_security.php : Modification à la ligne 27

      if(stripos($dir_folder, $folder_detection)!==false){
      

      par

      if(mb_stripos($dir_folder, $folder_detection)!==false){
      


      (doc php) > mb_stripos() : Trouve la première occurrence d’une chaîne dans une autre, sans tenir compte de la casse.

      Merci pour cet excellent billet que je trouve excellent et complet, donc je le partage 😉
      Belle et heureuse année à toutes et à tous

    2. Bonjour,

      De ce que j’ai pu voir, le module navigation à facettes peut être concerné par la faille, il est donc recommandé de supprimer le dossier « phpunit » présent à l’intérieur du module.

      A bientôt!

  3. Salut 🙂
    100% infectés, sur 4 sites gérés, 4 touchés, dont 2 en 1.6 et 2 en 1.7.
    Merci pour ton script, tout a été supprimé.
    Penses-tu qu’il faudra refaire un passage d’ici quelques jours ?
    merci !!

  4. Bonjour,
    Merci pour ce tutoriel. Le script me trouve des dossiers du type :
    modules/gamification/vendor/symfony/phpunit-bridge
    Ce n’est donc pas des dossiers phpunit mais phpunit-bridge, doit-on tout de même les supprimer ?

    Merci

    1. Bonjour,

      Le module « gamification » de Prestashop est à supprimer totalement, car celui-ci provoque régulièrement des ralentissements de la boutique Prestashop.

      A bientôt !

  5. Extra ! Quel réactivité !
    J’avais prévu de voir ça aujourd’hui et que vois-je dans mes mails ?
    La new letter de WEBBAX avec la solution clé en main.
    Gé-nial le script te fais le truc tout seul … les codeurs sont vraiment les Rois.
    Cerise sur le gâteau, le script n’a rien trouvé.
    Grand merci, encore une fois.
    Très bonne année à toi.

  6. Bonjour Germain,
    Merci pour ce super tuto mais je n’arrive pas à faire la vérification car je ne suis pas en local, mon shop est uniquement sur mon herbergeur et je n’arrive pas à trouver l’url pour faire la manip.
    Corinne

    1. Bonjour,

      Il faut faire comme sur la vidéo et commencer par déposer le dossier « scripts » dans « /modules » via le FTP, ensuite vous pouvez exécuter la même url que dans le tutoriel Prestashop (saut que vous mettez le nom de votre site).

      A bientôt !

  7. Salut à tous, et particulièrement à toi Webbax.
    J’apprécie vraiment toujours autant tes conseils, scripts et vidéos que j’apprécie particulièrement parce que tu arrives à mettre de la simplicité pour d’expliquer des choses complexes (complexes pour des gars comme moi, qui se débrouillent sans être des cracks – j’apprends sur le tas!). Bon, « fini la brosse à reluire », lol, je passe aux choses plus … sérieuses! :

    Ce message est en fait une suite des questions que je t’avais posées sur ce post (https://www.webbax.ch/2019/07/18/prestashop-1-7-securiser-le-back-office-ep-81/), mais le post sur lequel je t’écris maintenant me parait plus cohérent avec mon problème puisque, je ne saurai l’affirmer avec certitude, mais il semblerait ce soit notre site qui ait été le premier concerné par cette faille XsamXadoo, d’ailleurs, le « nom de l’attaque » a peut-être été choisie par rapport à notre site (Xado-France.com)… en tout cas, la coïncidence me parait suspecte.
    Bon, peu importe.

    Suite à l’avertissement que j’ai donné à l’équipe Prestashop sur la faille en décembre, il y a eu la publication de l’avis et la présentation de la solution, que, nous, comme beaucoup, ont appliqué afin de virer tous les répertoires et fichiers du phpunit.

    Mais il semblerait que l’histoire ne s’arrête pas là et que la faille soit plus importante qu’il n’y parait à première vue.

    C’est un peu long à raconter, mais celles et ceux qui ont eu à faire face à cette faille peuvent être intéressé(e)s par ce que j’ai à dire (j’ai déjà eu la démarche que je suis en train de faire ici, sur le forum francophone de Prestashop).

    Pour la petite histoire :
    Après l’histoire de la faille XsamXadoo, j’ai reçu, ce jeudi 16 janvier 2020, une alerte de Google Search Console m’informant de l’apparition Top Error sur le site.
    Évidemment, j’ai consulté la console de Google Search et, constaté que ces Top Error sont apparues subitement le 15 janvier 2020.

    J’ai, bien sûr tout de suite pensé à la faille de sécurité, et en ouvrant Filezilla sur l’espace d’hébergement, j’ai trouvé, à la racine du site, un fichier nommé « Updating.php ».

    Premier réflexe, je l’ai ouvert pour voir ce qu’il contenait, mais, mes maigres connaissances en programmation ne m’ont pas permis de déterminer exactement la fonction du fichier. J’y ai quand même trouvé des mots comme « extract », « db », « user », etc.
    J’ai tout de suite senti un loup, et mauavis réflexe, je l’ai supprimé en ayant conservé le contenu ouvert dans notepad, ce qui m’a permis de faire une sauvegarde de ce code… suspect).
    Mais j’ai appris plus tard, et trop tard, que le mal était fait.

    Je vous passerais mes vaines tentatives restaurer le site à une date antérieure afin de le dupliquer, puis de le lier à une nouvelle base de données avec un nouveau mot de passe qui se sont soldées par une erreur500 lorsque j’ai tenté d’accéder à l’admin… admin qui fonctionnait tout de même en mode débug et qui, en mode normal, fonctionnait parfaitement à la condition de remettre le mot de passe original de la bdd (mot de passe existant lors du piratage, parce que c’est bien ça, la base a été piratée – Cf. plus bas).

    Enfin bref, toutes ces tentatives m’ont pris la journée et face à mes échecs, je me suis dit que j’allais chercher d’autres solutions. J’ai donc décidé de revenir remettre le mot de passe original de la bdd dans le fichier parameters.php, afin de revenir à mon site du matin (avec la brèche de sécurité, certes, mais sans le fichier « Updating.php quand même) afin de pouvoir accéder au backoffice.

    Et donc en revenant dans l’hébergement pour faire cette manipulation, ayant conservé un tri de fichier par date dans mon filezilla, j’ai tout de suite remarqué l’apparition d’un nouveau fichier
    intitulé, cette fois « readme.php ».
    Je l’ai ouvert et j’ai pu constater qu’il contenait exactement le même code que celui que j’avais trouvé le matin dans le fichier « Updating.php ».
    Là, j’ai donc compris, que non seulement, je pouvais être sûr à 100% que ce code était « malicieux » et qu’en plus, il était le fruit d’un travail volontaire d’un pirate, et non le résultat de la mise à jour ou je ne sais quoi d’un module qui installerait des fichiers pour son propre fonctionnement, auquel cas, le nom aurait, au moins été le même.

    J’ai donc :
    1 – pris contact avec l’équipe Prestashop pour les informer de tout ça et leur transmettre le contenu du code du fichier afin d’en déterminer la fonction.
    2 – posté, tout le contenu du message que je suis en train de te rédiger en y ajoutant le contenu du fichier (updating.php et readme.php), sur le forum Presta pour trouver de l’aide (https://www.prestashop.com/forums/topic/1013028-faille-de-sécurité-suite/), et alerter le plus de gens possible sur les failles persistantes qui pourraient également les concerner afin qu’il se prémunissent et / ou cherchent et trouvent des solutions.

    Le lendemain (hier), l’équipe Prestashop m’a répondu, en même temps que sur le forum, que ce script récupérait « pleins informations dans la base de données » d’après l’équipe Presta, des adresses email d’après l’aide de certains développeurs chevronnés sur le forum.

    L’équipe Presta m’a précisé que les pirates avaient pu (dû) créer des backdoor et m’a donc recommandé de comparer tous les fichiers de mon site avec leur zip, ce qui, vus mes compétences va prendre un certains temps… Je ne sais pas s’il existe un moyen d’automatiser la chose(?).
    J’ai donc cherché d’autres solutions complémentaires, et comme tu me l’as recommandé précédemment, nous allons envisager l’achat d’un module de protection (peut-être le Security Pro ou un autre, il faut je vois les meilleurs protections possibles).

    Mais, je me suis dit, que, quoiqu’il en soit, avant de « mettre un pansement, il faut désinfecter ». et faire la comparaison des fichiers (ai-je raison?).

    Tu m’as également transmis un lien vers https://www.webbax.ch/2016/11/30/antivirus-gratuit-wordpress-prestashop/ qui m’a fournis des résultats intéressant avec des fichiers que je n’avais pas encore trouvé :

    == Virus potentiels trouvés ==
    Ces fichiers pourraient être infectés :

    – /AdminXXX/themes/default/js/jquery.iframe-transport.js
    – /AdminXXX/themes/new-theme/public/main.bundle.js
    – /js/admin/login.php
    – /js/jquery/loader.php
    – /licence.php
    – /modules/autoupgrade/vendor/twig/twig/lib/Twig/Test/IntegrationTestCase.php
    – /pdf/invoice.php
    – /vendor/smarty/smarty/libs/sysplugins/smarty_internal_runtime_tplfunction.php
    – /vendor/twig/twig/src/Test/IntegrationTestCase.php

    J’ai donc procédé au remplacement des fichiers présent sur le site et ayant un fichier original existant dans le zip et supprimé ceux qui n’en avaient pas (en prenant soin de sauvegarder d’abord tous les fichiers potentiellement infectés au cas où quelqu’un de compétent en php aurait souhaité y jeter un oeil – d’ailleurs, je vais surement poster la liste et le contenu des fichiers sur le post du forum.)

    En résumé :
    – J’ai installé le script : check4update.php lancé par une tâche CRON pour être averti, 4 fois par jour, de changements ou de création de fichier / répertoires
    – J’ai installé mais pas encore utilisé ton script security.php
    – J’ai utilisé et nettoyé / supprimé les fichiers que m’a trouvé l’antivirus. et lorsqu’il m’a ressorti certains fichiers que je venais de remplacer par les fichiers originaux de Prestashop, j’ai changé les droit, comme tu le recommandes, pour les passer en chmoid555.

    Et donc, j’en suis là pour l’instant.
    Et je ne sais pas trop par quel bout continuer maintenant…
    1 – Est ce que ce que j’ai fais suffit pour avoir fermé cette éventuelle backdoor? en existe-t-il d’autres potentiellement, sachant que Prestashop n’est pas sujet fréquemment à des failles de sécurité, et si oui, comment les trouver?
    2 – Si j’installe un module spécifique de protection, est-ce que ca me réparera les éventuelles backdoor ouvertes par le pirate, ou bien dois-je les trouver d’abord avant d’installer le module?
    3 – Dois-je, à tout prix, passer par une nouvelle base de données dans laquelle importer la sauvegarde des données actuelles afin que le pirate n’aient, au moins pas les noms, et identifiants de la base qu’il a déjà pu récupérer, et si je le fais, est ce que ce sera suffisant?
    (J’ai même pensé à ré-installer un nouveau Presta, avec une nouvelle BDD propres tous les 2 et importer la BDD existante dans la nouvelle BDD)…
    4 – Je me suis demandé si je pouvais renvoyer tous les fichiers du zip Prestashop écraser l’ancien script, mais je ne pense pas, je crois que ca me produira une série d’erreur plus compliquées à réparer qu’autre chose (mais peut-être pas, je ne sais pas trop).

    Enfin bref, voilà, je ne sais pas trop par quel bout prendre les choses, et ni moi, ni le boss n’avons les moyens d’engager une agence pour faire le boulot à ma place et je dois me dépatouiller seul, et avec l’aide que je pourrai éventuellement trouver à droite à gauche auprès de gens plus compétents que moi.

    Donc, si toi ou quelqu’un d’autre a des idées, je suis preneur et vous remercie d’avance pour tous les conseils que vous pourrez éventuellement m’apporter.

  8. Bonjour et merci pour le Tuto!
    Par contre pour ma part après avoir fait le nettoyage je n’ai plus accès à mon back office… mais le site fonctionne toujours. Une idée?

    Merci!

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *