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
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.
Salut,
En SSH :
find . -type d -name « phpunit » -exec rm -rf {} \;
find . -type f -name « phpunit » -exec rm -rf {} \;
Code à ne pas mettre en toute les mains ^^
Hello,
Et mieux vaut ne pas oublier des paramètres 😉 ahaha…
A bientôt !
Hello,
Merci pour le complément d’information pour les « SUPER GEEK » 😉
A bientôt !
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 !
Bonjour,
applicable de la même façon sur presta 1.6?
Merci.
Aucun souci, je l’ai fait sur 2 boutiques.
Bonne continuation.
Hello,
Oui, le processus fonctionne sur Prestashop 1.6 et 1.7.
A bientôt !
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 ?
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
Un grand merci pour la précieuse contribution & l’optimisation de ce script Prestashop !
Merci beaucoup pour cette optimisation du code, mise en place avec succès. Bonne année à vous.
Merci infiniment pour la correction du script, j’ai trouver encore 14 fichier phpunit
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!
Bonjour et un grand merci pour la précision. Bonne journée à tous.
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 !!
Hello,
A mon avis si les fichiers Prestashop sont intacts ça devrait le faire : https://www.webbax.ch/2020/01/09/corriger-la-faille-de-securite-xsamxadoo-sur-prestashop-ep-92/#comment-26836
Je conseille quand même de demander à l’hébergeur de faire un « SCAN » de l’hébergement.
A bientôt !
Merci pour ton coup de main pour le ménage 🙂
Tout est nickel !!
Merci, avec plaisir !
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
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 !
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.
Hello,
Alors c’est super, au moins vous êtes rassuré vous savez que vous n’êtes pas concerné par la faille Prestashop.
A bientôt !
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
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 !
Bonjour Germain,
OK mais comme je ne suis pas très douée je ne sais pas ou mettre le nom de mon site et avec http , https ??
Merci
Bonjour,
Il faut saisir l’url dans le navigateur comme je le montre dans la vidéo, cela va ensuite exécuter le lien du script déposé sur votre boutique Prestashop (https://votresite.com/modules/script/patch_security.php?token=82733).
A bientôt
Bonjour Germain,
Bon ben y’a rien à faire ça veut toujours pas, ca m’affiche une page d’erreur 404 LA PAGE QUE VOUS CHERCHEZ N’A PAS ÉTÉ TROUVÉE. Mais qui atterit sur mon site….
Merci
Corinne
Bonjour,
Difficile d’en dire plus à ce sujet chez vous l’url devrait être : https://ma-deco-feline.fr/modules/scripts/patch_security.php?token=82733
Sur le FTP vous devez avoir le dossier « scripts » dans le dossier « /modules » et dans ce dossier « scripts » un fichier « patch_security.php ».
A bientôt !
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.
Hello,
Je vais essayer de répondre au mieux :
Faux positifs (ne rien faire)
===
– /AdminXXX/themes/default/js/jquery.iframe-transport.js
– /AdminXXX/themes/new-theme/public/main.bundle.js
– /modules/autoupgrade/vendor/twig/twig/lib/Twig/Test/IntegrationTestCase.php
– /vendor/smarty/smarty/libs/sysplugins/smarty_internal_runtime_tplfunction.php
– /vendor/twig/twig/src/Test/IntegrationTestCase.php
A Remplacer idéalement par le fichier original Prestashop
===
– /js/admin/login.php
– /js/jquery/loader.php
– /licence.php
– /pdf/invoice.php
Une fois le nettoyage effectué, je conseille de modifier le nom et l’accès à la base de données. Une fois l’opération effectuée, il est conseillé de demander à l’hébergeur de faire un SCAN de l’hébergement complet.
Il faut éviter d’écraser complètement Prestashop avec l’ensemble de tous les fichiers.
A bientôt !
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!
Bonjour,
Cela n’est pas lié, mais à vérifier si vous n’avez pas changé la version de PHP, pour Prestashop 1.7, il est recommandé d’utiliser PHP 7.1 (sinon ça génère parfois des erreurs, y compris sur la page de login du back-office).
A bientôt !
Bonjour, je suis en train de voir pour ouvrir une boutique Prestashop et j’aurai aimé savoir la version que vous conseillez ? Merci
Bonjour,
Actuellement je recommande toujours de prendre la dernière version disponible sur le site officiel… donc Prestashop 1.7.
A bientôt !
Bonjour à tous.
La version 1.7.6.3 de Prestashop est sortie il y a quelques jours, annoncée comme « stable ». Elle semblerait corriger le problème des phpunit, d’après la liste des améliorations. Donc ce serait bon pour les nouvelles installations à partir de cette version, mais pour les anciennes il convient de rester prudent et prendre toutes les précautions. L’expérience de Jérôme ci-dessus est assez claire, bon courage à lui…
Je crois qu’on est bon pour une réinstallation complète de la base sur une nouvelle version du shop, l’occasion de faire un très grand ménage, j’ai commencé cette longue marche…
Bonne journée à tous.
Bonjour,
Prestashop a quand même réagi assez vite et il faut dire la faille ne venait pas directement de leur « propre » code source, ce sont des choses qui arrivent. Maintenant on peut commencer l’année 2020 sereinement !
A bientôt !
Merci pour le bon courage.
J’ai décidé de repartir de 0, mais je n’avais que la 1.7.6.2, il fa donc falloir que je procède à la mise à jour.
D’autant que j’ai beau avoir récupéré les clients et commandes, je suis confronté maintenant à des modules qui ne fonctionnent plus correctement avec la nouvelle version (par exemple YTC Blog n’affiche plus le contenu des pages. Je tombe sur des pages quand je clique sur les liens des articles, mais la page sur laquelle j’arrive n’a aucun contenu en dehors du template, et du fil d’ariane. Et le pire, c’est qu’en mode Debug, je n’ai aucun message d’erreur…lol).
Enfin bref, bon courage à toi aussi puisque tu es parti dans le grand ménage!
Et tant qu’à faire, quand tout sera recréé, je blinde!
Bonjour,
Si vous repartez de zéro avec Prestashop, essayez d’utiliser la méthode DESAKTIVTOU pour gagner du temps et vous concentrer sur l’essentiel : https://www.webbax.ch/2018/04/12/prestashop-1-7-methode-desaktivtou-ep-50/
A bientôt !
Salut Webbax,
C’est encore moi Jerome G, désolé de revenir comme ça…
J’avais utilisé ton script une première fois, et tout s’était bien déroulé.
Ce matin, j’ai trouvé ceci dans mes logs :
5.101.0.0 – – [04/Feb/2020:10:13:29 +0100] « POST /vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1 » 404 823 217.160.120.163:80 « – » « Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36 » « – »
Ce qui me fait dire que c’est passé au travers. Pourtant, j’ai passé ton script, j’ai passé le module de ComonSoft de détection de phpunit et celui de soluka.
Et tout me dis que c’est ok.
Sauf ton détecteur, qui me renvoi un bad token alors que je n’ai rien modifié dans ton script.
A quoi pourrais être dû ce bad token d’après toi? Est-ce que quelque chose dans mon htaccess pourrait y être pour quelque choses?
En plus, j’ai souvent des erreur 500 dans le backoffice (je suis en mode maintenance mode debug) et je reçois des messages (Max user bdd dépassé), et je vois dans mes logs que j’ai des bots en masse, donc, il va falloir que j’investisse dans un module anti-bot (j’ai essayé de mettre des blocage dans le htaccess en reprenant un script que j’ai récupéré dans le htaccess d’un site WordPress protégé par All In One sécurity et qui bloque des robots mais ca ne fonctionne pas ici à priori).
Mais sinon, d’après toi, ou d’autres intervenant, tous les avis sont bons :
1 – est-ce que je dois virer le dossier phpunit du module gamification? (Je pense que oui)
2 – Pourquoi ai-je un bad token?
3 – Comment se fait-il que les modules de détection passent au travers? (Parce que du coup, j’ai peut-être encore un fichier pirate sur mon presta (je n’en peux plus, je suis reparti de zéro avec un presta 1.7.6.3 tout propre, et c’est reparti. J’ai l’impression d’être Sisyphe!!)
Merci pour ton (votre) aide
Hello,
Alors voilà ce que je pense :
1) Il faut supprimer le module gamification de Prestashop en entier (il n’est pas utile).
2) Il faut bien écrire le lien comme dans la vidéo avec le « ?token=… » à la fin, si le bad token survient quand même vérifie que l’url a bien le « www » ou non (cela dépend de la configuration de ton shop).
3) Normalement il va trouver le/s dossier/s, mais si le bad token survient, cela veut dire que le script n’a pas pu démarrer et que l’url n’est pas juste.
Courage pour la suite !
Merci pour le temps que tu prends pour me répondre.
Voici l’url que j’appelle :
https://xado-france.com/modules/PatchSecurityWebbax/patch_security.php?token82733
Et donc ca ne fonctionne pas.
J’ai aussi le problème avec l’autre script que tu avais indiqué : antivirus.php qui se termine systématiquement par une erreur ( Fatal error: Maximum execution time of 30 seconds exceeded in urlxxx/antivirus.php on line 34)
Alors que j’ai déjà utilisé les deux auparavant, qu’ils avaient parfaitement fonctionnés et que je n’ai rien changé depuis.
Je suis de plus en plus convaincu que j’ai encore dû être hacké parce que j’ai d’autres symptômes :
1 – Le contenu du blog ne s’affiche pas (les articles apparaissent bien sur la page d’accueil du site, mais quand on clique pour lire tout l’article, le thème se charge, mais il n’y a pas de contenu de blog – aucune erreur mentionnée en mode débug)
2 – lenteurs et nombreuses erreurs500 aléatoires avec le message max-user base de donnée dépassé
3 – J’ai trouvé deux répertoires php unit qui n’ont été trouvé par aucun des modules spécialement conçus pour les trouver (un dans …/vendor/NewFiles/symfony/symfony/src/Symfony/Bridge/PhpUnit et autre dans …/adminXXX/autoupgrade/latest/vendor/symfony/symfony/src/Symfony/Bridge/PhpUnit). – Je les ai trouvé en lançant une recherche de fichier distant avec Filezilla.
4 – Impossible de changer le mot de passe de la BDD sans avoir une erreur500 quand j’essaye d’accéder au backoffice (en FrontOffice tout est ok, mais le backoffice ne fonctionne plus.
Et pourtant, je suis reparti d’un prestashop propre 1.7.6.3.
Je viens d’installer le module payant SecurityPro, mais ca ne semble pas changer grand chose.
Ca m’agace. Je n’arrive pas à trouver ce qui peut coincer.
Bon, allez, je vous laisse tous tranquille.
Bon weekend (pour ceux qui vont être en w.e.) et bon courage aux autres.
Bonjour,
Concernant l’analyse il faut exécuter l’url suivante (dans la vôtre il manque le =): https://xado-france.com/modules/PatchSecurityWebbax/patch_security.php?token=82733
Pour le fichier « antivirus.php », il faut parfois demander à l’hébergeur d’augmenter les limites « max_execution_time » et « memory_limit » pour que le processus réussisse à se terminer / exécuter.
A bientôt !
Bon,
Finalement, nous avons investit dans deux modules de sécurité.
Ils ont un tronc de fonctions communes, du coup, je ne les active que dans un module, et sinon, chacun offre des fonctionnalités complémentaires. Il y en a un qui s’attache plus à sécuriser le FrontOffice et l’autre le backOffice, la BDD, etc.
Il s’agit des modules SecurityPro et AntivirusPro, que l’on trouve sur le site de Prestashop Addons.
Le Développeur du Module SecurityPro est super. Le lui ai parlé de notre problème de max_user. Du coup, juste pour (à cause de…) nous, il a développé son module et ajouté une fonction Anti-Flood. Et le problème est résolu. C’est un type super. Nous avons eu plusieurs échanges et il est actif et efficace. Je recommande.
Les deux modules dont je parle, sont très simple à mettre en oeuvre.
Et comme à eux deux, il proposent, dans tout le panel de fonctions disponibles, certaines fonctionnalités que tu avait mise en ligne gratuitement, je les ai désactiver. Inutile de conserver des outils en double. Mais je me garde tout sous le coude.
En tout cas Webbax, continue (je sais que tu n’attendras pas après moi pour le faire, bien sûr, lol) mais, au cours des recherches que j’ai pu faire pour résoudre tous mes problèmes, j’ai pu constater que tu bénéficiais d’une grande notoriété, et beaucoup, ne jurent que par toi. Alors… actions!
Merci encore pour tous tes conseils
Hello,
Merci pour le retour concernant ces 2 modules Prestashop, certainement qu’ils ont pu approfondir et faire quelque chose de plus complet (ici il s’agit d’un script, qui fait le gros du travail… mais on peut faire mieux).
Le fait d’utiliser un module Prestashop pour augmenter la sécurité ou nettoyer les failles, ça reste toujours plus « simple » d’utilisation… et ça vaut « toujours » la peine d’investir un peu sur la sécurité… Comme on le dit si bien, mieux vaut prévenir que guérir 😉
A bientôt !
C’est tout à fait vrai.
En fait, pendant 3 ans, je me suis reposé sur la réputation de Prestashop : Sécurité, efficacité.
Et même si je reste convaincu par Presta, je le suis moins concernant la sécurité (même si c’est, peut-être l’un des plus fiable du genre), mais mon expérience récente m’a convaincu qu’il y a des investissements sur lesquels il ne vaut mieux pas faire l’impasse.
Je pense que seuls des développeurs peuvent se passer des modules : ceux qui savent très bien ce qu’ils font.
L’attaque dont nous avons été victime aura eu, au moins, le mérite de m’apprendre énormément de choses concernant la sécurité. Un hack, et je perds un mois et demi à tout refaire (ceci dit, j’en ai profiter pour approfondir certaines choses que je n’avais pas fais lors de la mise en place initiale, et repartir de zéro m’aura aussi permis de m’attaquer à certaines choses que je repoussais jusqu’à aujourd’hui).
Mais s’il y a bien deux choses que j’ai retenu de cet apprentissage c’est :
1 – Aucun script n’est fiable à 100% et se reposer sur une réputation conduit à baisser sa garde.
2 – Même avec tout ce que j’ai appris, je ne sais rien. Celui-qui pense tout savoir ou avoir fait tout ce qu’il faut court vers le danger, car là aussi il baissera sa garde.
Ma conclusion est donc, (comme tu me l’as dit un peu plus tôt ou sur un autre billet) : toujours rester vigilent et garder en permanence un oeil sur les fichiers logs.
Hello,
Ce que je peux confirmer c’est que même lorsque le code est « invulnérable » c’est bien souvent une faille « humaine » qui cause le problème. L’ordinateur resté ouvert avec l’accès sur le shop, le mot de passe FTP qui est est le même depuis 2 ans… Touts les comportements humains qui gravitent « autour » de la technologie ont leur importance, on en prend toujours connaissance quand on est face au problème.
Courage & à bientôt !
Bonjour tout le monde et merci webbax pour le contenu.
J’ai subi une attaque sur mon site via cette faille de sécurité (je pense). j’ai réussi à restaurer le site et à le nettoyer en supprimant tous les dossiers phpunit.
En revanche je n arrive plus à accéder au tableau de bord avec cette erreur à la connexion:
1/1) FatalErrorException
Compile Error: Declaration of AdminLoginControllerCore::viewAccess() must be compatible with AdminControllerCore::viewAccess($disable = false)
in AdminLoginController.php line 299
Est ce que c est déjà arrivé a quelqu’un? est ce qu’il y a une solution pour retrouver l’accès au site?
Merci d’avance de votre aide
Bonjour,
Je ne m’en sors pas avec xsam. Il n’arrête pas de revenir. Faites-vous des prestations d’analyse et nettoyage de site ?
Bonne journée,
Clément
Bonjour,
Vous pouvez essayer de regarder la technique antipiratage de Prestashop : https://www.webbax.ch/2020/09/10/prestashop-anti-hacking/
A bientôt !