Hack Prestashop avec XsamXadoo Bot

January 5

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 by Eolia (see edit history)

January 5

Bonsoir, que faut-il chercher dans le répertoire vendor ?

January 5

virez le sous-repertoire phpunit s'il existe

si vous êtes en 1.6 vous pouvez virer tout le répertoire

January 5

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

January 5

L'explication en détails pour ceux que ça intéresse: https://nvd.nist.gov/vuln/detail/CVE-2017-9841

January 5

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.

January 6

Il y a déjà du monde

https://www.zone-h.org/archive/notifier=Xsam Xadoo Bot/page=1

January 6

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.

January 6

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)

January 6

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

January 6

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.

January 6

Ç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"

January 6

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.

January 6

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

January 6

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 ?

January 6

45 minutes ago, ttoine said:

find . -type d -name "phpunit" -exec rm -rf {} \;

Avec un acces ssh

Edited January 6 by okom3pom (see edit history)

January 6

Il y a ce module qui scan le dossier /modules :

[DELETE]

Edited January 10 by Mediacom87
Le lien doit envoyer directement sur l'archive du module ou l'archive doit être jointe au message. (see edit history)

January 6

ok, je vais paraitre newbie mais tu fais comment pour avoir un accé SSH ?

January 6

@AAymeric merci de ton retour !

January 6

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

January 6

@okom3pom Oui le module liste les dossiers à supprimer, mais il ne permet pas de dire si la faille a été exploitée.

January 6

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 !

January 6

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

January 6

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 by ludoc (see edit history)

January 7

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 !

January 7

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.

January 7

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.

January 7

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.

January 7

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 !

January 7

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 !

January 7

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.

January 7

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.

January 7

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

January 7

https://github.com/PrestaShop/ps_facetedsearch/commit/47c4785a21ee3b1734b2d46f044f9659a151feca

January 7

L'article officiel à propos de ce problème:

https://build.prestashop.com/news/critical-security-vulnerability-in-prestashop-modules/

January 7

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

January 7

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 😉

January 8

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 !

January 8

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 ?

January 8

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

January 8

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.

January 8

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.

January 8

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 ?

January 8

1.5.6.2 je dirais normal

January 8

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 ?

January 8

eval-stdin.php

January 8

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

January 8

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 ?

January 8

bonjour,

moi j'ai vu le dossier dans------> vendor/symfony/symfony/src/Symfony/Bridge

dois-je le supprimer aussi?

January 8

@kokou z il suffit de lire et d'appliquer. on ne supprime que phpunit, pas le reste.

January 8

@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

January 8

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

January 8

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.

January 8

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

January 8

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

January 8

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

January 8

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.

January 8

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

January 8

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

January 8

Vous pouvez vérifier tous les répertoires par ce module gratuit

January 8

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

January 8

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

January 8

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

January 8

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 👎

January 8

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.

January 8

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

January 8

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.

January 8

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

January 8

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 ?

January 8

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

January 8

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 by okom3pom (see edit history)

January 8

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

January 8

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.

January 8

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

January 8

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

January 8

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 by doekia (see edit history)

January 8

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

January 8

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"

January 8

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

January 8

Erratum ici :

January 8

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.

January 8

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

January 8

STOP FAKE AVEC VOS MODULES !!!!

January 8

D'ailleurs j'ai un module pour vous :

Bonne soirée

January 8

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

January 8

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 by Eolia (see edit history)

January 8

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

January 8

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?

January 9

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

January 9

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 😉

January 9

@Eolia tu me confirmes que je peux fermer ce topic ?

January 9

Oui je pense que le principal a été dit et que les nombreux liens permettent d'avoir toutes les informations nécessaires.

January 9

locked.

merci à toutes et à tous pour vos réponses et le fait que cette discussion soit restée calme et constructive !

Hack Prestashop avec XsamXadoo Bot

Recommended Posts

Eolia 3,070

Share this post

Link to post

Share on other sites

Gu1llaume 6

Share this post

Link to post

Share on other sites

Eolia 3,070

Share this post

Link to post

Share on other sites

Gu1llaume 6

Share this post

Link to post

Share on other sites

Eolia 3,070

Share this post

Link to post

Share on other sites

okom3pom 682

Share this post

Link to post

Share on other sites

okom3pom 682

Share this post

Link to post

Share on other sites

david. 5

Share this post

Link to post

Share on other sites

Eolia 3,070

Share this post

Link to post

Share on other sites

Eolia 3,070

Share this post

Link to post

Share on other sites

okom3pom 682

Share this post

Link to post

Share on other sites

Gu1llaume 6

Share this post

Link to post

Share on other sites

ttoine 208

Share this post

Link to post

Share on other sites

okom3pom 682

Share this post

Link to post

Share on other sites

matth_87 0

Share this post

Link to post

Share on other sites

okom3pom 682

Share this post

Link to post

Share on other sites

AAymeric 6

Share this post

Link to post

Share on other sites

matth_87 0

Share this post

Link to post

Share on other sites

matth_87 0

Share this post

Link to post

Share on other sites

okom3pom 682

Share this post