Eolia 3,110 Posted January 5, 2020 (edited) Pour info et surtout pour les utilisateurs 1.7 il est fortement conseillé de supprimer le répertoire /vendor/phpunit/ de TOUS les modules où il se trouve. Sont concernés (aux dernières nouvelles): - autoupgrade (versions 4) - module pscartabandonmentpro ; versions v2.0.1 and 2.0.2 - module ps_checkout ; versions v1.0.8 & v1.0.9 - module ps_facetedsearch ; version v3.0.0 and v2.2.1 - module gamification Edited January 8, 2020 by Eolia (see edit history) 1 Share this post Link to post Share on other sites
Gu1llaume 6 Posted January 5, 2020 Bonsoir, que faut-il chercher dans le répertoire vendor ? Share this post Link to post Share on other sites
Eolia 3,110 Posted January 5, 2020 virez le sous-repertoire phpunit s'il existe si vous êtes en 1.6 vous pouvez virer tout le répertoire Share this post Link to post Share on other sites
Gu1llaume 6 Posted January 5, 2020 D'accord merci, à priori j'ai que Dolibaar (hors prestashop) avec du phpunit... J'ai quelques modules avec des reps vendor mais sans phpunit modules/paypal/sdk/paypalREST/vendor modules/rcpganalytics/vendor Share this post Link to post Share on other sites
Eolia 3,110 Posted January 5, 2020 L'explication en détails pour ceux que ça intéresse: https://nvd.nist.gov/vuln/detail/CVE-2017-9841 Share this post Link to post Share on other sites
okom3pom 682 Posted January 5, 2020 Les premiers signalements datant de 9 jours virer le dossier phpunit mais il faudra quand même vérifier l'intégrité des fichiers de la boutique. Share this post Link to post Share on other sites
okom3pom 682 Posted January 6, 2020 Il y a déjà du monde https://www.zone-h.org/archive/notifier=Xsam Xadoo Bot/page=1 Share this post Link to post Share on other sites
david. 5 Posted January 6, 2020 Bonjour, Merci pour ce signalement. Hors répertoire /modules/ j'ai trouvé ce répertoire en rapport avec PhpUnit sur un prestahsop 1.7, est-ce aussi impacté ? RACINE_PRESTASHOP/vendor/symfony/symfony/src/Symfony/Bridge/PhpUnit A bientôt. Share this post Link to post Share on other sites
Eolia 3,110 Posted January 6, 2020 Le fichier qui pose problème est /vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php pour les versions PHPUnit 4 avant la 4.8.28 et 5.x avant la 5.6.3 Dans le doute et s'il existe vous pouvez le supprimer (Vous n'avez jamais de tests unitaires à effectuer en tant qu'utilisateur) 1 Share this post Link to post Share on other sites
Eolia 3,110 Posted January 6, 2020 Il y a 6 heures, okom3pom a dit : Les premiers signalements datant de 9 jours virer le dossier phpunit mais il faudra quand même vérifier l'intégrité des fichiers de la boutique. La faille a été trouvée en 2017 quand même https://security.gentoo.org/glsa/201711-15 Share this post Link to post Share on other sites
okom3pom 682 Posted January 6, 2020 Par signalement, je voulais dire des gens utilisant prestashop qui se sont fait hackés, on voit bien la vague commencer le 26/12/2019 mais oui la faille existe depuis longtemps, on peut dire qu'il y a eu belle boulette et quid des modules pas dev par presta sur addon et autre marketplace. Share this post Link to post Share on other sites
Gu1llaume 6 Posted January 6, 2020 Ça scan à fond en tous cas ... 20191205-access.log.gz:118.24.147.252 - - [05/Dec/2019:09:20:33 +0100] "POST /vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1" 301 576 "-" "Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.139 Safari/537.36" 20191205-access.log.gz:88.99.189.59 - - [05/Dec/2019:22:33:40 +0100] "GET /vendor/phpunit/phpunit/build.xml HTTP/1.1" 301 543 "-" "Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_8; en-us) AppleWebKit/534.50 (KHTML, like Gecko) Version/5.1 Safari/534.50" 20191205-access.log.gz:88.99.189.59 - - [05/Dec/2019:22:33:40 +0100] "GET /vendor/phpunit/phpunit/build.xml HTTP/1.1" 404 68787 "-" "Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_8; en-us) AppleWebKit/534.50 (KHTML, like Gecko) Version/5.1 Safari/534.50" 20191217-access.log.gz:209.141.49.246 - - [17/Dec/2019:16:34:30 +0100] "GET /vendor/phpunit/phpunit/build.xml HTTP/1.1" 301 541 "-" "Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_8; en-us) AppleWebKit/534.50 (KHTML, like Gecko) Version/5.1 Safari/534.50" 20191217-access.log.gz:209.141.49.246 - - [17/Dec/2019:16:34:30 +0100] "GET /vendor/phpunit/phpunit/build.xml HTTP/1.1" 301 543 "-" "Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_8; en-us) AppleWebKit/534.50 (KHTML, like Gecko) Version/5.1 Safari/534.50" 20191217-access.log.gz:209.141.49.246 - - [17/Dec/2019:16:34:31 +0100] "GET /vendor/phpunit/phpunit/build.xml HTTP/1.1" 404 68762 "-" "Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_8; en-us) AppleWebKit/534.50 (KHTML, like Gecko) Version/5.1 Safari/534.50" 20191217-access.log.gz:209.141.49.246 - - [17/Dec/2019:16:34:54 +0100] "GET /vendor/phpunit/phpunit/build.xml HTTP/1.1" 301 543 "-" "Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_8; en-us) AppleWebKit/534.50 (KHTML, like Gecko) Version/5.1 Safari/534.50" 20191217-access.log.gz:209.141.49.246 - - [17/Dec/2019:16:34:55 +0100] "GET /vendor/phpunit/phpunit/build.xml HTTP/1.1" 404 68764 "-" "Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_8; en-us) AppleWebKit/534.50 (KHTML, like Gecko) Version/5.1 Safari/534.50" 20191220-access.log.gz:185.81.157.154 - - [20/Dec/2019:04:12:51 +0100] "GET /vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1" 301 577 "-" "python-requests/2.22.0" 20191220-access.log.gz:185.81.157.154 - - [20/Dec/2019:04:12:52 +0100] "GET /vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1" 301 579 "-" "python-requests/2.22.0" 20191220-access.log.gz:185.81.157.154 - - [20/Dec/2019:04:12:54 +0100] "GET /vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1" 404 68784 "-" "python-requests/2.22.0" 20191220-access.log.gz:185.81.157.154 - - [20/Dec/2019:07:05:36 +0100] "GET /vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1" 301 579 "-" "python-requests/2.22.0" 20191220-access.log.gz:185.81.157.154 - - [20/Dec/2019:07:05:36 +0100] "GET /vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1" 404 68782 "-" "python-requests/2.22.0" 20191222-access.log.gz:103.100.158.53 - - [22/Dec/2019:21:31:41 +0100] "POST /vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1" 301 576 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:48.0) Gecko/20100101 Firefox/48.0" 20191223-access.log.gz:117.50.49.60 - - [23/Dec/2019:04:00:37 +0100] "POST /vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1" 301 576 "-" "Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:60.0) Gecko/20100101 Firefox/60.0" 20191225-access.log.gz:43.229.152.212 - - [25/Dec/2019:20:08:45 +0100] "POST /vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1" 301 576 "-" "Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.139 Safari/537.36" 20191225-access.log.gz:154.0.169.225 - - [25/Dec/2019:20:42:41 +0100] "POST /vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1" 301 576 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.108 Safari/537.36" 20191226-access.log.gz:51.89.253.7 - - [26/Dec/2019:03:47:31 +0100] "GET /modules/autoupgrade/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1" 301 619 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.95 Safari/537.36" 20191226-access.log.gz:51.89.253.7 - - [26/Dec/2019:03:47:40 +0100] "GET /modules/autoupgrade/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1" 404 68654 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.95 Safari/537.36" 20191226-access.log.gz:51.89.253.7 - - [26/Dec/2019:04:07:06 +0100] "GET /modules/autoupgrade/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1" 301 617 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.95 Safari/537.36" 20191226-access.log.gz:51.89.253.7 - - [26/Dec/2019:04:07:15 +0100] "GET /modules/autoupgrade/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1" 301 619 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.95 Safari/537.36" 20191226-access.log.gz:51.89.253.7 - - [26/Dec/2019:04:07:19 +0100] "GET /modules/autoupgrade/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1" 404 68656 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.95 Safari/537.36" 20191226-access.log.gz:51.89.253.7 - - [26/Dec/2019:08:01:06 +0100] "GET /modules/autoupgrade/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1" 301 619 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.95 Safari/537.36" 20191226-access.log.gz:51.89.253.7 - - [26/Dec/2019:08:01:12 +0100] "GET /modules/autoupgrade/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1" 404 68877 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.95 Safari/537.36" 20191226-access.log.gz:129.204.115.226 - - [26/Dec/2019:23:30:03 +0100] "POST /vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1" 301 576 "-" "Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:58.0) Gecko/20100101 Firefox/58.0" 20191229-access.log.gz:40.89.165.84 - - [29/Dec/2019:04:22:04 +0100] "GET /modules/autoupgrade/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1" 301 617 "-" "python-requests/2.22.0" 20191229-access.log.gz:40.89.165.84 - - [29/Dec/2019:04:22:06 +0100] "GET /modules/autoupgrade/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1" 301 619 "-" "python-requests/2.22.0" 20191229-access.log.gz:40.89.165.84 - - [29/Dec/2019:04:22:07 +0100] "GET /modules/autoupgrade/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1" 404 68875 "-" "python-requests/2.22.0" 20191229-access.log.gz:40.89.165.84 - - [29/Dec/2019:04:22:08 +0100] "GET /modules/autoupgrade/vendor/phpunit/phpunit/src/Util/PHP/XsamXadoo_Bot.php HTTP/1.1" 301 623 "-" "python-requests/2.22.0" 20191229-access.log.gz:40.89.165.84 - - [29/Dec/2019:04:22:08 +0100] "GET /modules/autoupgrade/vendor/phpunit/phpunit/src/Util/PHP/XsamXadoo_Bot.php HTTP/1.1" 301 625 "-" "python-requests/2.22.0" 20191229-access.log.gz:40.89.165.84 - - [29/Dec/2019:04:22:08 +0100] "GET /modules/autoupgrade/vendor/phpunit/phpunit/src/Util/PHP/XsamXadoo_Bot.php HTTP/1.1" 404 68871 "-" "python-requests/2.22.0" 20191229-access.log.gz:40.89.165.84 - - [29/Dec/2019:04:22:12 +0100] "GET /modules/ps_facetedsearch/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1" 301 627 "-" "python-requests/2.22.0" 20191229-access.log.gz:40.89.165.84 - - [29/Dec/2019:04:22:17 +0100] "GET /modules/ps_facetedsearch/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1" 301 629 "-" "python-requests/2.22.0" 20191229-access.log.gz:40.89.165.84 - - [29/Dec/2019:04:22:19 +0100] "GET /modules/ps_facetedsearch/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1" 404 68869 "-" "python-requests/2.22.0" 20191229-access.log.gz:40.89.165.84 - - [29/Dec/2019:04:22:20 +0100] "GET /modules/ps_facetedsearch/vendor/phpunit/phpunit/src/Util/PHP/XsamXadoo_Bot.php HTTP/1.1" 301 633 "-" "python-requests/2.22.0" 20191229-access.log.gz:40.89.165.84 - - [29/Dec/2019:04:22:22 +0100] "GET /modules/ps_facetedsearch/vendor/phpunit/phpunit/src/Util/PHP/XsamXadoo_Bot.php HTTP/1.1" 301 635 "-" "python-requests/2.22.0" 20191229-access.log.gz:40.89.165.84 - - [29/Dec/2019:04:22:24 +0100] "GET /modules/ps_facetedsearch/vendor/phpunit/phpunit/src/Util/PHP/XsamXadoo_Bot.php HTTP/1.1" 404 68865 "-" "python-requests/2.22.0" 20191229-access.log.gz:150.136.220.44 - - [29/Dec/2019:18:41:33 +0100] "GET /vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1" 301 579 "-" "python-requests/2.22.0" 20191229-access.log.gz:150.136.220.44 - - [29/Dec/2019:18:41:33 +0100] "GET /vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1" 404 68867 "-" "python-requests/2.22.0" 20200105-access.log:166.62.92.37 - - [05/Jan/2020:13:16:16 +0100] "POST /vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1" 301 576 "-" "Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2623.105 Safari/537.36" 20200105-access.log:166.62.92.37 - - [05/Jan/2020:13:16:16 +0100] "POST /vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1" 301 576 "-" "Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2623.105 Safari/537.36" Share this post Link to post Share on other sites
ttoine 212 Posted January 6, 2020 Par contre faite gaffe: ne supprimez pas systématiquement les dossier vendors: pour certains modules ils incluent des dépendances utiles et ne fonctionneront plus. Seuls les dossiers "php-unit" doivent être supprimés. Voici un extrait du document de travail en cours avec les agences et les partenaires. On a Linux server, the cleanup procedure to fix a vulnerable shop can be performed using the following bash command line from the modules/ folder from the shop: find . -type d -name "phpunit" -exec rm -rf {} \; This command requires the relevant user rights. Share this post Link to post Share on other sites
okom3pom 682 Posted January 6, 2020 Il faut ensuite vérifier les logs pour voir si il y a eu des POST eval-stdin.php, supprimer le dossier c'est bien, savoir si on a infecté c'est mieux Le premier post à ce sujet sur le forum prestashop étant du 27/12/2019 et les premiers site défacés ou compromis datant au moins du 25/12/2019 il faut vraiment vérifier les acces à ce fichier. On trouve des presta 1.5 / 1.6 / 1.7 hackés qui tournent toujours d'ailleurs donc on peut se dire qu'il y a du vol de données / mot de passe / et autre sur pas mal de sites ... Share this post Link to post Share on other sites
matth_87 0 Posted January 6, 2020 bonjour, on doit vérifier tout les répertoires des modules pour trouver ce repertoire ? il n'y a pas un moyen de savoir plus rapidement que chercher à la main ? Share this post Link to post Share on other sites
okom3pom 682 Posted January 6, 2020 (edited) 45 minutes ago, ttoine said: find . -type d -name "phpunit" -exec rm -rf {} \; Avec un acces ssh Edited January 6, 2020 by okom3pom (see edit history) Share this post Link to post Share on other sites
AAymeric 6 Posted January 6, 2020 (edited) Il y a ce module qui scan le dossier /modules : [DELETE] Edited January 10, 2020 by Mediacom87 Le lien doit envoyer directement sur l'archive du module ou l'archive doit être jointe au message. (see edit history) 1 Share this post Link to post Share on other sites
matth_87 0 Posted January 6, 2020 ok, je vais paraitre newbie mais tu fais comment pour avoir un accé SSH ? Share this post Link to post Share on other sites
matth_87 0 Posted January 6, 2020 @AAymeric merci de ton retour ! Share this post Link to post Share on other sites
okom3pom 682 Posted January 6, 2020 Just now, matth_87 said: ok, je vais paraitre newbie mais tu fais comment pour avoir un accé SSH ? Non pas de soucis, mais bon du coup tu devrais utiliser le module, si tu ne connais pas tu pourrais faire de grosses bêtises. Si le module liste les dossiers, il faudra faire une investigation des logs Share this post Link to post Share on other sites
AAymeric 6 Posted January 6, 2020 @okom3pom Oui le module liste les dossiers à supprimer, mais il ne permet pas de dire si la faille a été exploitée. Share this post Link to post Share on other sites
matth_87 0 Posted January 6, 2020 ok, dans tous les cas je vais regarder les logs par la suite, deja enlevé les problemes si il y a . merci pour vos retours ! Share this post Link to post Share on other sites
Ether Création 43 Posted January 6, 2020 Nous venons de faire un module rapide qui permet de vérifier et patcher si nécessaire la faille. Vous pouvez le télécharger gratuitement pour corriger. ec_cleanphpunit.zip 3 5 Share this post Link to post Share on other sites
ludoc 2 Posted January 6, 2020 (edited) deleted - faille confirméhttps://build.prestashop.com/news/critical-security-vulnerability-in-prestashop-modules/?_ga=2.245478541.841835923.1578307930-262943242.1577965761&_gac=1.183160210.1578075983.EAIaIQobChMI5Ousj4fo5gIV0sjeCh1XiAHREAAYASAAEgITd_D_BwE visiblement sans rapport avec la CVE-2017-9841 mentionné en début d'article Edited January 7, 2020 by ludoc (see edit history) 2 Share this post Link to post Share on other sites
Gu1llaume 6 Posted January 7, 2020 11 hours ago, ludoc said: Bonjour, pour ceux qui veulent comprendre et faire les choses proprement (...) Merci beaucoup pour ton message Ludocn c'est clair, net et précis ! Share this post Link to post Share on other sites
ttoine 212 Posted January 7, 2020 Attention il y a actuellement des recherches en cours qui montrent que des versions plus récentes de PHPunit peuvent être impactées. Dès que j'arrive à en savoir plus, je vous tiens au courant. Share this post Link to post Share on other sites
okom3pom 682 Posted January 7, 2020 13 hours ago, ludoc said: On parle ici d'une CVE de 2017, si vous avez un Prestashop et ses modules à jours le risque est minime, cela fait bien longtemps que le problème est traité. https://github.com/sebastianbergmann/phpunit/issues/3989 Depuis longtemps , le dossier n'a rien à faire sur un site en prod quelque soit la version. 1 Share this post Link to post Share on other sites
ttoine 212 Posted January 7, 2020 C'est pour ça que les versions en cours de release des modules concernés incluent un script qui s'assure que les dossiers PHPUnit sont bien effacés pendant la mise à jour. l'autre problème c'est que tout le monde n'utilise pas Apache. Donc, les fichiers .htaccess ne sont pas utilisables par tout le monde. Et si c'est mal fait ou bidouillé, ça peut causer d'autres problèmes. Bref, le problème va être réglé rapidement en ce qui concerne PrestaShop. Ce qui est sur Addons va être vérifié. Il pourra subsister des modules tierces parties, indépendants, avec ce problème. Si vous en rencontrez, vous pouvez le signaler sur notre adresse email de sécurité, et bien évidemment vous pouvez prévenir les auteurs des modules et thèmes concernés. Attention, quand même, à ne pas le faire publiquement dans la mesure du possible et à leur laisser le temps de régler le problème. Enfin, il peut y avoir d'autres applications sur vos serveurs qui incluent le même problème: dès que Composer est utilisé pour développer un logiciel ou ajouter des fonctionnalités, c'est possible. Donc, jetez un coup d'oeil. Share this post Link to post Share on other sites
Vas69 4 Posted January 7, 2020 Bonjour, Merci AAymeric pour ta contribution avec la création du module fixant cette faille de sécurité ! A propos du module est il valide pour une version 1.6 et peut on désinstaller le module une fois la modification effectuée ? D'avance, merci ! Share this post Link to post Share on other sites
Thomas 0 Posted January 7, 2020 Bonjour, Suite à l'alerte nous avons fait des correctifs sur nos deux sites mais un des deux comportait la faille dans le module autoupgrade (PS 1.6.1.4). J'ai fait des recherches dans les logs et je suis tombé là dessus : [26/Dec/2019:08:00:58 +0100] "GET /modules/autoupgrade/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1" 200 220 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.95 Safari/537.36" [26/Dec/2019:03:14:41 +0100] "GET /modules/autoupgrade/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1" 200 220 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.95 Safari/537.36" [26/Dec/2019:03:16:55 +0100] "GET /modules/autoupgrade/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1" 200 220 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.95 Safari/537.36" [26/Dec/2019:05:39:12 +0100] "GET /modules/autoupgrade/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1" 200 220 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.95 Safari/537.36" Ce sont des appels GET, mais y a-t-il quand même matière à s'inquiéter ? Merci beaucoup ! Share this post Link to post Share on other sites
okom3pom 682 Posted January 7, 2020 Ce qui m'embête c'est la phrase ci-dessous 17 hours ago, ludoc said: si vous avez une version de PHPUnit >= 5.6.3, vous n'êtes pas concerné par cette vulnérabilité. Il suffit donc de vérifier le numéro de version : Vous induisez en erreur les personnes qui veulent fixer leur shop. Ce dossier n'a rien a faire dans un shop on le supprime. 18 hours ago, ludoc said: De manière générale, ce n'est pas en supprimant une dépendance d'un module ou d'un CMS que l'on adresse un problème de sécurité. Il suffit de mettre en place le correctif publié par l'éditeur. Encore une fois non, on corrige ce qu'on peu et on attend le correctif. Mais bon c'est mon point de vu perso. Share this post Link to post Share on other sites
ttoine 212 Posted January 7, 2020 Pour le coup, supprimer les dossiers phpunit est bien ce qui est recommandé par l'éditeur en attendant, merci @okom3pom de le rappeler. Mais dans d'autres cas, il peut y avoir d'autres approches, ça dépend. Bref, évitons les luttes de points de vue dans cette discussion, le but est vraiment de pouvoir traiter le problème au mieux. 1 Share this post Link to post Share on other sites
okom3pom 682 Posted January 7, 2020 On est d'accord l'importance étant de protéger un maximum de shop. 1 hour ago, ludoc said: Je maintiens que la bonne pratique est de demander aux éditeurs de traiter le problème, plutôt que d'effectuer des modifications dans son coin qui seront de toute manière écrasées lors d'une prochaine mise à jour. https://github.com/PrestaShop/autoupgrade/commit/ce96357ad3ff6278bb28dc225913e75c2f077a32#diff-bbb5f6c32b6b87e63c0d01953d9d41baR59 Share this post Link to post Share on other sites
okom3pom 682 Posted January 7, 2020 https://github.com/PrestaShop/ps_facetedsearch/commit/47c4785a21ee3b1734b2d46f044f9659a151feca Share this post Link to post Share on other sites
ttoine 212 Posted January 7, 2020 L'article officiel à propos de ce problème: https://build.prestashop.com/news/critical-security-vulnerability-in-prestashop-modules/ 1 1 Share this post Link to post Share on other sites
Ether Création 43 Posted January 7, 2020 Nous avons remis en ligne le module qui permet de corriger très facilement la faille pour ceux qui le souhaite, il est gratuit : ec_cleanphpunit.zip 1 1 Share this post Link to post Share on other sites
ludoc 2 Posted January 7, 2020 2 hours ago, okom3pom said: Ce qui m'embête c'est la phrase ci-dessous Vous induisez en erreur les personnes qui veulent fixer leur shop. Ce dossier n'a rien a faire dans un shop on le supprime. Encore une fois non, on corrige ce qu'on peu et on attend le correctif. Mais bon c'est mon point de vu perso. mon analyse se base uniquement sur la CVE-2017-9841 mentionné par l'auteur de ce fil, dans le cas présent il s'agit visiblement d'autre chose d'après l'annonce de prestashop. J'ai supprimé mes précédents messages pour éviter les confusions 😉 Share this post Link to post Share on other sites
Thomas 0 Posted January 8, 2020 Je relance mon cas, peut-être que cela clarifiera aussi pour d'autres personnes : On 1/6/2020 at 10:57 AM, okom3pom said: Il faut ensuite vérifier les logs pour voir si il y a eu des POST eval-stdin.php De mon côté je n'ai eu que des GET comme par exemple : [26/Dec/2019:08:00:58 +0100] "GET /modules/autoupgrade/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1" 200 220 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.95 Safari/537.36" Est-ce qu'il y a un risque que le site ai été compromis ? Merci ! Share this post Link to post Share on other sites
Bruckert Thomas 2 Posted January 8, 2020 Donc si je comprends bien, dans l'idée si je vérifie mes logs et que je fais un bête "ctrl+F" en tapant "phpunit" je verrais si qqun a tenté d'accéder à mes logs en faisant un "get phpunit" et si oui ou non on est possiblement infectés ? QUID de la fiabilité des modules envoyés sur ce fil de discussion ? 1 Share this post Link to post Share on other sites
S4G 0 Posted January 8, 2020 Bonjour Je viens de recevoir le mail de Presta. Quant est il si je n'ai pas de presta sur mon pc mais seulement via mon hébergeur OVH, la procédure de recherche et purge est elle la même ? D'avance merci Share this post Link to post Share on other sites
Eolia 3,110 Posted January 8, 2020 le module envoyé plus haut ne fait que scanner et supprimer le répertoire phpunit s'il existe mais en aucun cas ne vérifie la présence suspecte d'autre fichiers qui auraient déjà été ajoutés. Commencez donc par consulter vos logs d'accès avant toute chose et si jamais il y a des POST sur eval-stdin.php il faut contrôler l'ensemble du ftp. Share this post Link to post Share on other sites
Eolia 3,110 Posted January 8, 2020 il y a 19 minutes, S4G a dit : Bonjour Je viens de recevoir le mail de Presta. Quant est il si je n'ai pas de presta sur mon pc mais seulement via mon hébergeur OVH, la procédure de recherche et purge est elle la même ? D'avance merci La procédure est à appliquer là où est hébergé le Prestashop. Share this post Link to post Share on other sites
Alpes Eco Matériaux 2 Posted January 8, 2020 bonjour à tous, Après avoir fait un scan de tous les répertoires à partir de la racine (via FTP FileZilla ) aucun fichier phpunit na été trouvé normal ou je mis prend mal ? Share this post Link to post Share on other sites
okom3pom 682 Posted January 8, 2020 1.5.6.2 je dirais normal Share this post Link to post Share on other sites
Alpes Eco Matériaux 2 Posted January 8, 2020 J'ai fais la même chose sur ma version 1.6.1.20 et aucun fichier non plus ... quelqu’un sait quelle terme rechercher dans les logs svp ? Share this post Link to post Share on other sites
matthieu bak2 0 Posted January 8, 2020 Bonjour, J'ai supprimé le dossier phpunit du vendors prestashop, également le dossier phpunit dans le module : ingenico_epayment Suite à la vérification des logs, j'ai trouvé : [01/Jan/2020:23:05:55 +0100] "POST /vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1" 404 543 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36" Quelles sont les conséquences ? Merci Share this post Link to post Share on other sites
Aurélia222 23 Posted January 8, 2020 Le 06/01/2020 à 10:57 AM, okom3pom a dit : Il faut ensuite vérifier les logs pour voir si il y a eu des POST eval-stdin.php, supprimer le dossier c'est bien, savoir si on a infecté c'est mieux Le premier post à ce sujet sur le forum prestashop étant du 27/12/2019 et les premiers site défacés ou compromis datant au moins du 25/12/2019 il faut vraiment vérifier les acces à ce fichier. On trouve des presta 1.5 / 1.6 / 1.7 hackés qui tournent toujours d'ailleurs donc on peut se dire qu'il y a du vol de données / mot de passe / et autre sur pas mal de sites ... Bonjour, comment bien vérifier les logs ??? J'ai supprimé les dossiers phpunit et je voudrais vérifier si j'ai été infecté ou pas . sur les logs de mon hebergement , j'ai web,php, error, out j'ai verifié web et je n'ai pas trouvé avec une recherche " eval". est ce suffisant ou est ce que je m'y prend mal ? Share this post Link to post Share on other sites
kokou z 0 Posted January 8, 2020 bonjour, moi j'ai vu le dossier dans------> vendor/symfony/symfony/src/Symfony/Bridge dois-je le supprimer aussi? Share this post Link to post Share on other sites
ttoine 212 Posted January 8, 2020 @kokou z il suffit de lire et d'appliquer. on ne supprime que phpunit, pas le reste. Share this post Link to post Share on other sites
okom3pom 682 Posted January 8, 2020 @kokou z && @ tout le monde Toutes les informations sont données dans ce sujet et sur le blog prestashop, si les mots ssh / grep / md5 / signature ne vous disent rien je ne peux que vous conseiller de prendre un prestataire des tickets de nettoyage et de fix sont proposés pour 50 € Supprimer phpunit c'est bien savoir si on est infecté c'est mieux. 50€ pour les données de vos clients c'est rien Share this post Link to post Share on other sites
Studio Créations 5 Posted January 8, 2020 Bonjour, Je suis en train de faire un tour dans les différents Prestashop que je gère, dans un de mes modules (eicaptcha), j'ai un fichier phpunit.xml.dist, mais qui ne se trouve pas dans un dossier phpunit. Faut il que je le laisse ou est ce à supprimer également ? Merci Share this post Link to post Share on other sites
ttoine 212 Posted January 8, 2020 il ne faut supprimer que les dossiers phpunit dans les dossiers indiqués. le fichier phpunit.xml.dist n'est pas un executable, il ne présente aucun risque. Share this post Link to post Share on other sites
Studio Créations 5 Posted January 8, 2020 à l’instant, ttoine a dit : il ne faut supprimer que les dossiers phpunit dans les dossiers indiqués. le fichier phpunit.xml.dist n'est pas un executable, il ne présente aucun risque. Super merci pour l'information 😉 Share this post Link to post Share on other sites
DUCHENE 2 Posted January 8, 2020 Bonjour à tous, Je viens de supprimer le dossier phpunit d'un module (ps_facetedsearch/vendor/phpunit) et je suis en train de consulter les logs. Avez-vous une idée de jusqu'à quand il faut remonter dans cette consultation. J'ai vu que l'alerte datait du 2 janvier. Faut-il remonter en décembre? Merci d'avance pour votre retour Jérôme 1 Share this post Link to post Share on other sites
ttoine 212 Posted January 8, 2020 ça vaut le coup de regarder avant le 2 janvier, effectivement. ce n'est que le jour où le problème a été clairement identifié. un hacker peut avoir exploité la faille avant. Share this post Link to post Share on other sites
Eolia 3,110 Posted January 8, 2020 il y a une heure, matthieu bak2 a dit : Bonjour, J'ai supprimé le dossier phpunit du vendors prestashop, également le dossier phpunit dans le module : ingenico_epayment Suite à la vérification des logs, j'ai trouvé : [01/Jan/2020:23:05:55 +0100] "POST /vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1" 404 543 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36" Quelles sont les conséquences ? Merci Cela signifie que ce fichier existait avant et que le hacker tente d'y accéder. Si l'url était connue et exploitée il faut rechercher sur votre ftp les fichiers éventuellement ajoutés par le hacker. 1 Share this post Link to post Share on other sites
matthieu bak2 0 Posted January 8, 2020 6 minutes ago, Eolia said: Cela signifie que ce fichier existait avant et que le hacker tente d'y accéder. Si l'url était connue et exploitée il faut rechercher sur votre ftp les fichiers éventuellement ajoutés par le hacker. Ok, savez-vous dans quel dossier chercher en particulier ? Faut t'il changer les mots de passe serveur, BDD, ... Share this post Link to post Share on other sites
Lindsay_lfb 0 Posted January 8, 2020 On 1/6/2020 at 10:57 AM, okom3pom said: Il faut ensuite vérifier les logs pour voir si il y a eu des POST eval-stdin.php, supprimer le dossier c'est bien, savoir si on a infecté c'est mieux Le premier post à ce sujet sur le forum prestashop étant du 27/12/2019 et les premiers site défacés ou compromis datant au moins du 25/12/2019 il faut vraiment vérifier les acces à ce fichier. On trouve des presta 1.5 / 1.6 / 1.7 hackés qui tournent toujours d'ailleurs donc on peut se dire qu'il y a du vol de données / mot de passe / et autre sur pas mal de sites ... Bonjour, J'ai trouvé un fichier phpunit que j'ai supprimé. Mais je ne comprends pas comment vérifier si on a été infecté. Pouvez m'expliquer stp : ) Share this post Link to post Share on other sites
tuk66 791 Posted January 8, 2020 Vous pouvez vérifier tous les répertoires par ce module gratuit 1 Share this post Link to post Share on other sites
magicbel 49 Posted January 8, 2020 il y a 19 minutes, Lindsay_lfb a dit : Bonjour, J'ai trouvé un fichier phpunit que j'ai supprimé. Mais je ne comprends pas comment vérifier si on a été infecté. Pouvez m'expliquer stp : ) Le but est de trouver si un fichier à été ajouté ou modifié. Par exemple, sous linux il est possible de lister ce qui à été créé ou modifié après une date. (ceci n'est qu'un exemple avec 'find', un listing plus "propre" est possible aussi avec 'grep') find /var/www/vhosts/tonsiteprestashop/httpdocs/modules/ -type f -newermt '12/01/2019 0:00:00' ou encore sur une extension spécifique find /var/www/vhosts/tonsiteprestashop/httpdocs/modules/ -type f -newermt '12/01/2019 0:00:00' -name "*.php" Si tu es sur un hébergement mutualisé, là ça va être plus compliqué. Share this post Link to post Share on other sites
sebwvs 6 Posted January 8, 2020 Bonjour, Je vérifie un à un tous mes sites , pour un site important, je n'ai pas trouvé de dossier vendor, ni phpunit ni à la racine ni dans les sous dossier de chaque module ... par contre dans mes log du 23-12-2019 je trouve avec le crtl +f : eval-stdin.php 18 lignes de ce genre : 68.183.234.160 - - [23/Dec/2019:01:27:27 +0100] "GET /app/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1" 404 60201 "-" "Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:28.0) Gecko/20100101 Firefox/28.0" 68.183.234.160 - - [23/Dec/2019:01:27:29 +0100] "POST /app/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1" 404 60201 "-" "Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:28.0) Gecko/20100101 Firefox/28.0" je suppose à la lecture des logs et à la réponse du serveur (404) que c'était la trace d'une tentative sans succès , vu que je n'avais pas ces dossiers ? merci d'avance Share this post Link to post Share on other sites
Lindsay_lfb 0 Posted January 8, 2020 6 minutes ago, magicbel said: Le but est de trouver si un fichier à été ajouté ou modifié. Par exemple, sous linux il est possible de lister ce qui à été créé ou modifié après une date. (ceci n'est qu'un exemple avec 'find', un listing plus "propre" est possible aussi avec 'grep') find /var/www/vhosts/tonsiteprestashop/httpdocs/modules/ -type f -newermt '12/01/2019 0:00:00' ou encore sur une extension spécifique find /var/www/vhosts/tonsiteprestashop/httpdocs/modules/ -type f -newermt '12/01/2019 0:00:00' -name "*.php" Si tu es sur un hébergement mutualisé, là ça va être plus compliqué. Merci pour votre réponse. J'ai utilisé le module [FREE] M4 Check for vulnerabilities (XsamXadoo vulnerability) qui m'indique qu'il n'y a pas de risque de vulnérabilité. Share this post Link to post Share on other sites
okom3pom 682 Posted January 8, 2020 1 hour ago, tuk66 said: Vous pouvez vérifier tous les répertoires par ce module gratuit Mais vous ne serez pas si vous êtes infecté ... Merci de bien lire le POST sur le blog Prestashop ne vous faite pas induire en erreur avec tous ces modules gratuits .... qui ne servent qu'a supprimer un dossier ! ( en gros à rien ) La recherche dans le dossier module c'est bien mais si on lit le blog on voit que des controllers sont modifiés. Donc les modules qui suppriment un dossier avant investigation on ne les télécharge pas ... c'est vraiment du patching de mer*e Et les pros qui proposent ces modules un peu de sérieux on parle quand même des données personnelles de clients ... il serait judicieux au moins d'écrire la marche à suivre dans le bon ordre dans vos modules .... Franchement 👎 2 Share this post Link to post Share on other sites
okom3pom 682 Posted January 8, 2020 45 minutes ago, Lindsay_lfb said: Merci pour votre réponse. J'ai utilisé le module [FREE] M4 Check for vulnerabilities (XsamXadoo vulnerability) qui m'indique qu'il n'y a pas de risque de vulnérabilité. Mon message fait suite à ce genre de réponse. 1 Share this post Link to post Share on other sites
okom3pom 682 Posted January 8, 2020 En 30 secondes il est facile d'écrire un bot qui supprimera vos dossiers phpunit de votre site et qui écrira un shell dans un des dossiers img de votre shop, vous aurez alors utilisé un module gratuit qui vous aura dit pas de risque ... alors que vous êtes infecté ! Oui je cris et j'aboie fort mais on ne rigole pas avec ça, surtout quand on voit que les derniers reports sur ZH s'arrête au 02/01/2020 les hackers ne sont pas con quand un bot match souvent ils arrêtent de signaler les exploits et ils installent des mailers, des ftps de warez, volent des données ... 1 Share this post Link to post Share on other sites
ttoine 212 Posted January 8, 2020 Surtout, vérifiez qui a créé ces modules. Il faut avoir confiance pour installer un truc sur votre boutique que vous récupérez depuis n'importe où sur Internet, parce que si ça ne vérifie pas tout, ou pire, qu'au passage ça infecte votre site, mais que ça vous dit quand même que tout vas bien, c'est pas pertinent. (genre comme un faux antivirus pour windows) Pour rappel, il suffit juste de supprimer quelques dossiers, et de vérifier si quelques fichiers sont présent, et si un fichier a été modifié. Ca peut vraiment se faire à la main en quelques minutes. Share this post Link to post Share on other sites
Eolia 3,110 Posted January 8, 2020 il y a 2 minutes, ttoine a dit : Surtout, vérifiez qui a créé ces modules. Il faut avoir confiance pour installer un truc sur votre boutique que vous récupérez depuis n'importe où sur Internet, parce que si ça ne vérifie pas tout, ou pire, qu'au passage ça infecte votre site, mais que ça vous dit quand même que tout vas bien, c'est pas pertinent. (genre comme un faux antivirus pour windows) Pour rappel, il suffit juste de supprimer quelques dossiers, et de vérifier si quelques fichiers sont présent, et si un fichier a été modifié. Ca peut vraiment se faire à la main en quelques minutes. Euh... @ttoine, même si c'est modules ne font le job qu'à moitié la décence demanderait d'éviter ce genre de remarques vu l'origine de l'infection actuelle... Celle-ci est arrivée grâce à des modules Prestashop, distribués par Prestashop et auteur Prestashop donc l'origine ne protège en rien. (Et pour cartabandomnentpro, c'est quand même la 2ème fois). Des excuses auraient surtout été bienvenues et j'ose espérer qu'avant de mettre quoi que ce soit en ligne, un comité de contrôle validera l'ensemble des fichiers proposés à l'avenir. Pour ceux qui airaient des traces en POST, recherchez en priorité ces 2 fichiers sur votre serveur: - Xsam_Xadoo.html - XsamXadoo_deface.php S'ils sont présents, supprimez-les immédiatement 1 Share this post Link to post Share on other sites
Bruckert Thomas 2 Posted January 8, 2020 Hello, de mon côté aucun fichier n'a été trouvé par le soft et je n'ai vu aucun log étrange. Cependant je n'ai accès qu'aux logs des deux derniers jours hébergés par presta. Est-ce que ça vaut le coup que je pousse encore plus profond l'analyse ou est-ce que je peux estimer ne pas être vulnérable à cette attaque ? Share this post Link to post Share on other sites
ttoine 212 Posted January 8, 2020 @Eolia voici la liste des 4 fichiers connus à chercher, précisés dans l'article sur Build: XsamXadoo_Bot.php XsamXadoo_deface.php 0x666.php f.php Et il est à noté que ces modules PrestaShop ne sont malheureusement pas les seuls impactés. Il y a d'autres modules, mais aussi d'autres logiciels écrits en PHP, dont certains bien plus utilisés que PrestaShop, qui ont fait la même erreur. Ce n'est jamais avec plaisir que l'on doit gérer et communiquer là dessus. Deux bonnes nouvelles par rapport à ça: - PrestaShop attire de plus en plus de moyennes et grandes entreprises, qui ont les moyens de faire des audits réguliers, ce qui devrait permettre de signaler et de régler d'autres problèmes (sécurité, mais aussi performance, UX, etc.) - PrestaShop est déjà parmi les CMS ayant le moins de faille de sécurité sur ces dernières années Ah et oui, en général, effectivement, je me méfie des trucs magiques disponibles sur le web sans avoir bien vérifié leur provenance et leur auteur. Et il vaut mieux aller les télécharger sur le site original. Il suffit par exemple d'aller sur 01.net pour télécharger un logiciel, au lieu d'aller sur le site original, et de se retrouver avec beaucoup de trucs inutiles sur son pc. C'est pareil avec les modules pour les CMS: on fait attention à ce qu'on installe sur sa boutique en ligne. Rien de méchant ni aucun sous entendu de ma part, juste un peu de prévention. Share this post Link to post Share on other sites
okom3pom 682 Posted January 8, 2020 (edited) Pour ma part : J'ai lancé une commande pour vérifier la présence de dossiers phpunit ( Sur la racine et les sous domaines pas comme les modules proposés qui vérifie que le dossier module ), prestashop c'est bien mais il y a d'autre CMS avec la même faille. Ensuite dans les logs j'ai recherché un POST sur eval-stdin.php J'ai regardé la structure des fichiers dans Paramètres avancées -> Informations ( controller ou class modifiés ) J'ai lancé une recherche sur xam*, f.php et x.666.php J'ai lancé une recherche sur << eval >> dans mes fichiers J'ai régénéré les images ( tu t'embêtes pas ça vide le dossier img/p qu'aime les hackers ) ( Fail dans la procédure merci @doekia ) J'ai dl une sauvegarde d'avant le 26/11 et fait un compare avec ma version. ( hors cache et img ) Ensuite j'ai supprimé les dossiers phpunit présents. Je pense que là on a un bon << début >> de procédure pour vérifier si un site est vérolé. Comme dit plus haut vérifier la présence d'un dossier, d'un log, ou autre selon les droits qu'aura eu le hacker ça risque de ne servir à rien. Edited January 8, 2020 by okom3pom (see edit history) Share this post Link to post Share on other sites
Cédric P 0 Posted January 8, 2020 Bonjour, Actuellement en train de faire les vérifications (sur une 1.7), je trouve des dossiers /phpunit plus bas que dans la racine du dossier /vendor. Exemples : - /modules/ps_facetedsearch/vendor/mockery/mockery/tests/Mockery/Adapter/Phpunit - /modules/ps_facetedsearch/vendor/friendsofphp/php-cs-fixer/src/Fixer/PhpUnit - /vendor/symfony/symfony/src/Symfony/Bridge/PhpUnit Faut-il aussi les supprimer ? Merci d'avance pour vos réponses Share this post Link to post Share on other sites
najtema 1 Posted January 8, 2020 1 hour ago, okom3pom said: En 30 secondes il est facile d'écrire un bot qui supprimera vos dossiers phpunit de votre site et qui écrira un shell dans un des dossiers img de votre shop, vous aurez alors utilisé un module gratuit qui vous aura dit pas de risque ... alors que vous êtes infecté ! Oui je cris et j'aboie fort mais on ne rigole pas avec ça, surtout quand on voit que les derniers reports sur ZH s'arrête au 02/01/2020 les hackers ne sont pas con quand un bot match souvent ils arrêtent de signaler les exploits et ils installent des mailers, des ftps de warez, volent des données ... C'est surtout que ceux qui écrivent du code à la va-vite ont comme objectif de récolter au plus vite les adresses mails avec leurs modules gratos, comme quoi l'urgence est une bonne technique sur le plan marketing. 1 Share this post Link to post Share on other sites
sebwvs 6 Posted January 8, 2020 si çà peux aider , j'ai trouvé des tentatives dans les logs les jour suivants : j'ai vérifié pour l instant que du 15-12 au 29-12 15-12-2019 17-12-2019 18-12-2019 19-12-2019 20-12-2019 23-12-2019 24-12-2019 26-12-2019 27-12-2019 28-12-2019 29-12-2019 et avec les ip suivantes : 8.208.20.89 68.183.234.160 163.172.5.104 185.81.157.154 51.77.110.206 51.89.253.7 40.89.165.84 Share this post Link to post Share on other sites
Redsign 1 Posted January 8, 2020 Bonjour, Le 26/12/2019 j'ai été mis en garde par IONOS (1&1) comme quoi mon site avait subi une attaque: Bonjour xxxxxxxxxx, Ceci est un message urgent concernant votre contrat avec 1&1 IONOS. Il y a quelques minutes, notre anti-virus a détecté qu'un fichier nuisible a été transféré sur votre espace Web. Vous trouverez ce fichier sur votre espace Web à l'emplacement suivant : ~/monsiteweb/Xsam_Xadoo.html Afin de vous protéger des attaques de hackers, notre anti-virus analyse chaque fichier de votre espace Web dès lors qu'il est modifié ou qu'il y a été transféré. Si un code malicieux est détecté, l'exécution du fichier est bloquée pour éviter toute attaque supplémentaire. Par conséquent, les droits du fichier sont automatiquement modifiés pour que tout appel à ce fichier ne soit plus possible. Afin de pouvoir désactiver les autres fichiers nuisibles, notre analyse continuera même après l'envoi de cet e-mail. Après finalisation de notre analyse, vous recevrez un e-mail supplémentaire avec des informations détaillées afin de nettoyer votre espace Web. Nous vous demandons un peu de patience. En attendant, vous pouvez déjà réaliser les étapes suivantes : 1. Utilisez-vous un système de gestion de contenu (CMS) tel que WordPress ou Joomla! ? Nous vous recommandons dans ce cas de mettre à jour votre CMS, ainsi que les plug-ins et thèmes de ce dernier, vers la dernière version. 2. Analysez votre ordinateur avec un anti-virus. En effet, dans le cas où vos données d'accès ont été relevées par un tiers, la présence d'un virus est probable. Vous accéderez à une sélection de logiciel anti-virus gratuit en suivant le lien ci-après :http://www.antibot.fr/nettoyer/eu-cleaner --------------------------- deuxieme mail: Bonjour xxxxxxxxxxxx, Comme annoncé par e-mail, nous vous adressons via ce message le résultat de notre analyse. Vous trouverez ci-après la liste complète des fichiers nuisibles issues de notre analyse est disponible ici :http://monaccesxxxxxxxxxxxxxxxxxxx.fr/logs/forensic/lock-1577323694.log Afin de sécuriser votre contrat avec 1&1 IONOS, veuillez suivre les étapes suivantes : (A) Nettoyer ou supprimer les fichiers nuisibles 1. Cliquez sur le lien ci-dessus et identifiez-vous à l'aide du nom d'utilisateur et du mot de passe FTP. Vous pouvez également utiliser un logiciel FTP (comme par exemple FileZilla) pour récupérer le fichier se trouvant dans le dossier suivant : ./logs/forensic/ 2. Le fichier journal contient des informations plus détaillées concernant les fichiers nuisibles. Veuillez suivre les indications présentes dans celui-ci. 3. Pour que votre site Web soit à nouveau accessible, modifiez, après désinfection, les droits des fichiers de 200 à 604. Pour les dossiers, modifiez les droits de 700 à 705. Ces droits sont nécessaires au bon affichage de votre site Web. ############################### Vous n'êtes pas encore sûr par où vous devez commencer ? Est-ce que vous souhaitez que votre site Web soit rapidement désinfecté ? Notre Service de nettoyage de l'espace qui est payant désinfecte en un clin d'oeil votre site Web. Nos experts répondent à toutes vos questions concernant ce service et sont à votre disposition du lundi au vendredi de 08:30 à 20:00 au 0970 808 911 (appel non surtaxé). Vous pouvez également répondre à cet e-mail. Veuillez indiquer notre référence [Ticket xxxxxxxxxxxxxxxxxxx] dans votre message. ############################### (B) Voici comment vous protéger à l'avenir 1. Si vous utilisez un CMS comme WordPress ou Joomla!, nous vous recommandons de le mettre à jour, ainsi que les plug-ins et thèmes de ce dernier, vers la dernière version. 2. Par mesure de sécurité, dans le cas où vos données d'accès auraient été relevées par un tiers, veuillez modifier vos mots de passe. 3. Assurez-vous que vos appareils (PC, Mac, tablettes ou smartphones) ne sont pas infectés par des logiciels malveillants. Vous accéderez à une sélection de logiciel anti-virus gratuit en suivant le lien ci-après. Vous pourrez ainsi supprimer les logiciels malveillants.https://www.botfree.eu/en/eucleaner/ Nous nous réjouissons de votre collaboration pour assurer la sécurité de votre site Web. voici le log envoyé par le service: Vous trouverez ci-dessous le résultat de notre analyse. Afin que votre site web fonctionne après nettoyage, il vous faudra rétablir les droits 604 sur vos fichiers . Selon toute vraisemblance, les fichiers suivant ont été chargés par un tiers. Veuillez vérifier ces fichiers et les supprimer si nécessaire. ~/xxxxxmonsitewebxxxxxx/modules/autoupgrade/vendor/phpunit/phpunit/src/Util/PHP/XsamXadoo_Bot.php ~/xxxxxmonsitewebxxxxxx/Xsam_Xadoo.html Selon toute vraisemblance, les fichiers suivant ont été modifiées par un tiers. Veuillez vérifier ces fichiers et si nécessaire chargez une copie de ces fichiers provenant d'une sauvegarde non infectée sur votre espace web. ~/xxxxxmonsitewebxxxxxx/modules/autoupgrade/vendor/phpunit/phpunit/src/Util/PHP/XsamXadoo_Bot.php ~/xxxxxmonsitewebxxxxxx/Xsam_Xadoo.html comment puis je me certifié que ma boutique n'est pas infectée? et si c'est le cas comment corriger cela? dois je patienter? IONOS a du intervenir sur mes données car je ne vois plus du tout de dossiers PHPunit ou les fichiers courament rencontrés dans ces dossiers. j ai trouvé des centaines de lignes commes celle ci dans les logs 68.183.234.0 - - [30/Dec/2019:01:57:00 +0000] "POST /sites/all/libraries/mailchimp/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1" 404 71006 68.183.234.0 - - [30/Dec/2019:01:56:59 +0000] "GET /sites/all/libraries/mailchimp/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1" 404 70891 www.monsite.com "-" "Mozilla/5.0 (X11; Ubuntu; Linux i686; rv: 105.103.0.0 - - [30/Dec/2019:10:57:29 +0000] "GET /modules/autoupgrade/vendor/phpunit/phpunit/src/Util/PHP/0x666.php HTTP/1.1" 200 235 monsite.com "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.95 Safari/537.36" "-" 68.183.234.0 - - [30/Dec/2019:01:57:02 +0000] "POST /admin/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1" 404 70941 www.monsite.com "-" "Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:28.0) Gecko/20100101 Firefox/28.0" "-" 68.183.234.0 - - [30/Dec/2019:01:57:04 +0000] "GET /laravel/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1" 404 70891 www.monsite.com "-" "Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:28.0) Gecko/20100101 Firefox/28.0" "-" 68.183.234.0 - - [30/Dec/2019:01:57:05 +0000] "POST /laravel/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1" 404 70891 www.monsite.com "-" "Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:28.0) Gecko/20100101 Firefox/28.0" "-" 68.183.234.0 - - [30/Dec/2019:01:57:06 +0000] "GET /app/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1" 404 70917 www.monsite.com "-" "Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:28.0) Gecko/20100101 Firefox/28.0" "-" 68.183.234.0 - - [30/Dec/2019:01:57:07 +0000] "POST /app/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1" 404 71069 www.monsite.com "-" "Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:28.0) Gecko/20100101 Firefox/28.0" "-" 68.183.234.0 - - [30/Dec/2019:01:57:08 +0000] "GET /new/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1" 404 70941 www.monsite.com "-" "Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:28.0) Gecko/20100101 Firefox/28.0" "-" 68.183.234.0 - - [30/Dec/2019:01:57:10 +0000] "POST /new/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1" 404 71069 www.monsite.com "-" "Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:28.0) Gecko/20100101 Firefox/28.0" "-" 68.183.234.0 - - [30/Dec/2019:01:57:11 +0000] "GET /blog/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1" 404 70891 www.monsite.com "-" "Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:28.0) Gecko/20100101 Firefox/28.0" "-" 68.183.234.0 - - [30/Dec/2019:01:57:12 +0000] "POST /blog/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1" 404 70783 www.monsite.com "-" "Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:28.0) Gecko/20100101 Firefox/28.0" "-" 68.183.234.0 - - [30/Dec/2019:01:57:13 +0000] "GET /old/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1" 404 70781 www.monsite.com "-" "Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:28.0) Gecko/20100101 Firefox/28.0" "-" 68.183.234.0 - - [30/Dec/2019:01:57:14 +0000] "POST /old/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1" 404 71006 www.monsite.com "-" "Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:28.0) Gecko/20100101 Firefox/28.0" "-" 68.183.234.0 - - [30/Dec/2019:01:57:16 +0000] "GET /backup/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1" 404 71006 www.monsite.com "-" "Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:28.0) Gecko/20100101 Firefox/28.0" "-" 68.183.234.0 - - [30/Dec/2019:01:57:17 +0000] "POST /backup/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1" 404 71006 www.monsite.com "-" "Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:28.0) Gecko/20100101 Firefox/28.0" "-" 68.183.234.0 - - [30/Dec/2019:01:57:18 +0000] "GET /site/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1" 404 70917 www.monsite.com "-" "Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:28.0) Gecko/20100101 Firefox/28.0" "-" 68.183.234.0 - - [30/Dec/2019:01:57:19 +0000] "POST /site/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1" 404 70998 www.monsite.com "-" "Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:28.0) Gecko/20100101 Firefox/28.0" "-" 68.183.234.0 - - [30/Dec/2019:01:57:20 +0000] "GET /home/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1" 404 70998 www.monsite.com "-" "Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:28.0) Gecko/20100101 Firefox/28.0" "-" 68.183.234.0 - - [30/Dec/2019:01:57:22 +0000] "POST /home/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1" 404 70874 www.monsite.com "-" "Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:28.0) Gecko/20100101 Firefox/28.0" "-" 68.183.234.0 - - [30/Dec/2019:01:57:23 +0000] "GET /cms/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1" 404 71002 www.monsite.com "-" "Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:28.0) Gecko/20100101 Firefox/28.0" "-" 68.183.234.0 - - [30/Dec/2019:01:57:24 +0000] "POST /cms/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1" 404 70891 www.monsite.com "-" "Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:28.0) Gecko/20100101 Firefox/28.0" "-" merci pour votre aide 1 Share this post Link to post Share on other sites
doekia 1,499 Posted January 8, 2020 (edited) Il y a 1 heure, ttoine a dit : Et il est à noté que ces modules PrestaShop ne sont malheureusement pas les seuls impactés. Le problème étant que votre validateur aurait dû détecter ces contenus impropre à la production. Par ailleurs si un dev s'inspire des modules développés par prestashop, dans le design et dans le code. Le fait que phpunit soit dans nombre d'entre eux (notamment autoupgrade) incite un dev à distribuer son code de cette manière. Je suis désolé de re-constater que les réponse officielles: forum et finalement newsletter dans ce genre de cas ait à nouveau demander un temps excessif de la part de la team. Edited January 8, 2020 by doekia (see edit history) Share this post Link to post Share on other sites
doekia 1,499 Posted January 8, 2020 il y a 24 minutes, sebwvs a dit : si çà peux aider , j'ai trouvé des tentatives dans les logs les jour suivants : j'ai vérifié pour l instant que du 15-12 au 29-12 15-12-2019 17-12-2019 18-12-2019 19-12-2019 20-12-2019 23-12-2019 24-12-2019 26-12-2019 27-12-2019 28-12-2019 29-12-2019 et avec les ip suivantes : 8.208.20.89 68.183.234.160 163.172.5.104 185.81.157.154 51.77.110.206 51.89.253.7 40.89.165.84 Je rapelle que le plus simple est de configurer un filtre fail2ban http://area51.enter-solutions.com/snippets/81 1 Share this post Link to post Share on other sites
Studio Créations 5 Posted January 8, 2020 il y a 25 minutes, sebwvs a dit : 40.89.165.84 J'ai également repéré cette IP dans mes logs 40.89.165.84 - - [26/Dec/2019:01:18:58 +0000] "GET /modules/autoupgrade/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.0" 301 669 "-" "python-requests/2.22.0" 40.89.165.84 - - [26/Dec/2019:01:19:24 +0000] "GET /modules/autoupgrade/vendor/phpunit/phpunit/src/Util/PHP/XsamXadoo_Bot.php HTTP/1.0" 301 675 "-" "python-requests/2.22.0" Share this post Link to post Share on other sites
okom3pom 682 Posted January 8, 2020 Ne vous embêtez pas à regarder les ips, c'est du temps dépensé pour rien. Une bonne règle fail2ban ou un htaccess ( si apache sinon lisez les docs ) fera je job, dans 30 secondes / minutes / heures elles auront changé. Share this post Link to post Share on other sites
Prestashop Addict 41 Posted January 8, 2020 Nous avons développé un module gratuit pour détecter et corriger la faille de sécurité. Module gratuit pour 1.6 et 1.7. Share this post Link to post Share on other sites
okom3pom 682 Posted January 8, 2020 Bonjour, Et si le site est déjà vérolé que fait le module ? Quote $hackFilesNames = array('XsamXadoo_Bot.php','XsamXadoo_deface.php','0x666.php','f.php'); C'est soft non ? Je ne vois pas en quoi le module va corriger une faille, merci de respecter les utilisateurs de ce forum. Merci de ne pas poster quelque chose faisant penser au utilisateur que leur site est clean avec votre module. Quote Le module phpunit vous permet de supprimer en quelques secondes les fichiers et dossiers contenant le trou de sécurité phphunit. Il permet de vérifier en même temps si votre site a été hacké par XsamXadoo Bot, et il supprime automatiquement les fichiers connus à ce jour. Totalement faux ! Quid des controllers modifiés pourtant dans le blog prestashop ! STOP AU CHARLATAN ( SAVOIR PARTAGE ) Put1 que ça me gonfle les mecs qui sortent des solutions bancals désolé pour les mots mais c'est la vérité ! SVP lisez le POST de @prestashop 1 Share this post Link to post Share on other sites
okom3pom 682 Posted January 8, 2020 STOP FAKE AVEC VOS MODULES !!!! Share this post Link to post Share on other sites
okom3pom 682 Posted January 8, 2020 D'ailleurs j'ai un module pour vous : Bonne soirée 1 Share this post Link to post Share on other sites
najtema 1 Posted January 8, 2020 10 minutes ago, okom3pom said: Bonjour, Et si le site est déjà vérolé que fait le module ? C'est soft non ? Je ne vois pas en quoi le module va corriger une faille, merci de respecter les utilisateurs de ce forum. Merci de ne pas poster quelque chose faisant penser au utilisateur que leur site est clean avec votre module. Totalement faux ! Quid des controllers modifiés pourtant dans le blog prestashop ! STOP AU CHARLATAN ( SAVOIR PARTAGE ) Put1 que ça me gonfle les mecs qui sortent des solutions bancals désolé pour les mots mais c'est la vérité ! SVP lisez le POST de @prestashop Tu as raison prise de tête sachant que 2 on posté le même blabla surtout de recevoir des notif pour ce genre de poste Share this post Link to post Share on other sites
Eolia 3,110 Posted January 8, 2020 (edited) Si un modérateur peut clore ce topic, je pense que tout a été dit et que les infos sont assez complètes. Inutile de laisser le premier venu poster des liens vers des modules inutiles ici Merci Edited January 8, 2020 by Eolia (see edit history) 2 Share this post Link to post Share on other sites
Prestashop Addict 41 Posted January 8, 2020 Inutile d'être virulent et insultant. Nous avons juste indiqué que le module efface les dossiers incriminés et détete si le site a été hacké et efface les fichiers connus à ce jour. Nul part est indiqué que nous protégeons et réparons un site déjà hacké ! Merci de respecter les personnes qui aident à maintenir Prestashop et aider les utilisateurs de Prestashop. Tout les utilisateurs de Presta ne sont pas des développeurs... Share this post Link to post Share on other sites
DDM 1 Posted January 8, 2020 Bonjour, Je ne trouve pas de dossier vendor a la racine de mon site en passant par Filezilla En revanche dans module >> /www/modules/autoupgrade/vendor Je tombe sur un dossier phpunit que j'ai supprimé. Ensuite j'ai contrôle tout les modules et dans les dossier vendor il n'y avait pas de phpunti. En lisant votre topic je n'ai vu personne parler du module autoupgrade et qu'il y avait aussi des phpunit.xml.dist qui ne fallait pas effacer. Du coup je me demande si j'ai bien fait ou si dans la précipitation je n'aurait pas effacer un phpunit.xml.dist par exemple. Votre avis svp? Share this post Link to post Share on other sites
doekia 1,499 Posted January 9, 2020 En 1.6 il n'y a pas de répertoire vendor à la racine - normal Dans autoupgrade il y a aussi un vendor/bin/phpunit - répertoire vendor/bin à supprimer un fichirr xml ne s'execute pas donc sans conséquences Share this post Link to post Share on other sites
sebwvs 6 Posted January 9, 2020 Il y a 16 heures, doekia a dit : Je rapelle que le plus simple est de configurer un filtre fail2ban http://area51.enter-solutions.com/snippets/81 Merci doekia je vais me renseigner la dessus 😉 Share this post Link to post Share on other sites
ttoine 212 Posted January 9, 2020 @Eolia tu me confirmes que je peux fermer ce topic ? Share this post Link to post Share on other sites
Eolia 3,110 Posted January 9, 2020 Oui je pense que le principal a été dit et que les nombreux liens permettent d'avoir toutes les informations nécessaires. Share this post Link to post Share on other sites
ttoine 212 Posted January 9, 2020 locked. merci à toutes et à tous pour vos réponses et le fait que cette discussion soit restée calme et constructive ! Share this post Link to post Share on other sites