Recommandé
Recommandé
Contenu connexe
Similaire à Conférence Cyberattaques PrestaShop–1 an de harcèlement : FoP Day 2023
Similaire à Conférence Cyberattaques PrestaShop–1 an de harcèlement : FoP Day 2023 (20)
Plus de ChristopheVidal15
Plus de ChristopheVidal15 (8)
Conférence Cyberattaques PrestaShop–1 an de harcèlement : FoP Day 2023
- 1. Cyberattaques PrestaShop 1 an de harcèlement
- 2. Présentation Clotaire Renaud Directeur Technique @clotairer Membre #FOPsecurity 202 ecommerce Agence partenaire PrestaShop à Paris depuis 2012 2
- 3. Définition agissements malveillants et répétés à l’égard d’autrui Un harcèlement… 3
- 4. Sondage Sécurité = préoccupation de chaque instant pour 33% des sondés + 60% “souvent” ! > 50% des agences au moins un PrestaShop hacké sur un an ! … systémique, industrialisé, mais aussi moral. 4 * réalisé du 13 avril 2023 au 2 mai 2023. 66 participants
- 5. Qu’est ce qui nous arrive ? 5
- 6. Le business du piratage Gain direct ● Numéro de carte bancaire 10$/carte ● Données personnelles (e- mails, adresses, téléphone) 100$/10M ● Vente d’accès backoffice Investissement ● Données techniques (cookie key, pwd mysql) ● Sources des modules installés permettent de trouver des vulnérabilités Preston EASY TO HACK ! 6 Source : https://bit.ly/3WJCj0Z
- 7. …versus les risques ressentis 7 En décalage avec la réalité observée
- 8. Le podium des malwares PrestaShop Web skimmer de carte bancaire Loader dormant (filemanager) Webshell Envoyez nous les signatures des malwares pour analyse et documentation 8
- 9. Exemple de web skimmer Ajout d’un faux formulaire de CB ⇒ Récupération sur le site marchand ⇒ Transfert sur site distant 9
- 10. Remonter la piste par une étude par 202 FORENSIC (logs) 1. Découverte d’un fichier txt contenant les numéros de CB. 2. Recherche du fichier qui créé ce txt 3. Recherche dans les logs serveur depuis quand exploité ? 4. Recherche des fichiers modifiés du module de paiement (diff) mais date bidouillée par le hacker 5. Une date était restée OK... Recherche logs Apache quel appel et on a trouvé la backdoor. On récupère les IPs… Accès BO Installation Skimmer Récup num CB 10
- 11. Quel coût ? pour remonter un site 1. Étude FORENSIC 2. Nettoyage du site 3. Changement de tous les mots de passe et clés API, … 4. Certification SAQ A (TPE) 5. CNIL // Info clients => 5 jours à plusieurs mois de fermeture de la boutique + Ce qui n’a pas de prix La réputation, la peur que ça recommence, le stress, … 11
- 12. Niveau de vulnérabilité du parc Magento ? Projection à partir de l’étude de Forgenix 250 000 sites monitorés En mai 2019 0.8% des sites compromis 88% faciles à hacker En avril 2021 0,5% des sites compromis 58% faciles à hacker 12 Source: http://bit.ly/42lEn0b
- 13. Quel est le niveau de vulnérabilité réelle du parc PrestaShop ? ● Sondage : hack > 1 agence sur 2 ● 100% des nouveaux clients entrant chez (202) et Touch Web depuis sept 2022 possèdent au moins un module avec vulnérabilité critique non corrigée. ● Pic d’exploration en avril ● 3 à 5 modes opératoires de hacks ● Un parc obsolète aggravant ● Manque de data consolidée 13
- 14. La riposte, une mobilisation communautaire ? 17 baisser la part de PrestaShop vulnérable < 50% en 3 ans
- 15. FOP Security Une cellule dédiée aux problématiques de sécurité Vocation : - Analyse de hack ou de code - Veille - Support - … Merci notamment à : - 202 ecommerce - 772424 - Profileo (Module PrestaScan) - TouchWeb - Creabilis, OHweb, StoreCommander, Vitalyn, @Okom3pom Thomas, … 18
- 16. La prévention des marchands Mettre à jour PrestaShop et ses modules Mettre en place des headers CSP Protéger le Backoffice (2FA, IP, …) Nettoyer les modules inutiles … 19
- 17. Les CVEs Divulguer pour se protéger - Découverte faille - Documentation - Contact auteur / PrestaShop Addons - Demande CVE ID via Mitre.org - Suivi dossier 20 h de travail / vulnérabilité 2 mois de délais minimum Organisez votre veille ! 20
- 18. Les palmes à saluer ou à éviter… 21
- 19. Se former pour éviter les failles triviales 22 Une charte qualité / sécurité pour PrestaShop Marketplace soutenu par Friends Of Presta ?
- 20. Une infogérance de qualité Coût de la sécurité Plan d’atténuation des risques ● Avant juillet 2022 > OK ● Après juillet 2022 > les solutions existent ! ⇒ une infogérance est une valeur ajoutée qui se paye… 23
- 21. Évolution du core Apporter un cadre Fait ● 1.7.8.8 fin du multi requêtes ;) Idées soumises ● Stockage des données sensibles ● Interdire php modules ● 2FA natif en back office ● Rassembler les domaines CSP 24
- 22. Des raisons d’espérer… Tisser une toile pour capturer les vulnérabilités avant qu’elles ne soient exploitées 25 CVEs Sensibilisation marchands Roadmap Core orienté sécurité Implication des Agences (veille et partage) Charte éditeurs de modules et thèmes Infogérances PrestaScan, outil de monitoring Purge du catalogue Presta Marketplace Autres initiatives ?
- 23. Merci ! PLACE AUX QUESTIONS & RÉPONSES avec Vincent de TouchWeb et Xavier de Profileo et 772424
- 24. Bibliographie ● Combien valent vos données personnelles sur le darkweb ? https://bit.ly/3WJCj0Z ● Forgenix Magento website security report (avril 22) http://bit.ly/42lEn0b ● Securinet https://sucuri.net/wp-content/uploads/2022/04/sucuri-2021-hacked-report.pdf ● 202 ecommerce : Knowledge Base, sécuriser ses modules https://202ecommerce.github.io/security-advisories/kb/ 27
Notes de l'éditeur
- En préparant cette conférence, je me suis demandé si le titre n’était pas un peu trop racoleur ! Et en fait je me suis aperçu qu’il reflétait encore plus la réalité. Les observations montrent un accroissement des cas de piratage en plusieurs vagues successives depuis un an. Juillet 2022 est une date à retenir pour PrestaShop car c’est une date de non retour qui place le logiciel comme cible de réseau criminel qui ont investi pour attaquer les boutiques et qui sont désormais installés et compte bien rentabiliser leur investissement. Mais pour cette intro je voulais vous faire part d’un chiffre qui m’a étonné quand j’ai lu les résultats du sondage que je vous ai soumis en avril. Or le sondage a été une surprise pour moi puisque finalement on s’aperçoit qu’on était pas seul à être préoccupé par la situation.
- 60% des agences (si on prend les décisionnaires,…) indiquent que la sécurité est une préoccupation souvent voire à chaque instant pour 33% d’entre elles. Or une préoccupation à chaque instant c’est que le sujet est une obsession qui demande une hyper vigilance permanente. On pourrait se dire que le sentiment d’insécurité est finalement infondé mais le sondage nous révèle que +50% des agences en avril s’est retrouvé confronté au piratage d’un de ses clients dans l’année écoulée. Et les remontées de terrain que l’on a c’est que certaines agences ont pris plusieurs vagues. Au harcèlement technique s’ajoute une charge mentale harcèlement moral
- Ce qu’on va essayer de faire durant ces 45 minutes c’est de comprendre ce qui se passe, comprendre la menace, revenir sur l’année écoulée. Déconstruire certaines idées reçues. J’ai fait de recherches pour quantifier et comparer avec Magento et WordPress. On va essayer de poser un diagnostic et évoquer ce qui nous attend pour les mois à venir et faire le tour des initiatives pour engager la communauté PrestaShop vers un cadre plus sécurisé sur le plan individuel mais aussi sur le plan communautaire.
- Pour se défendre efficacement, il est essentiel de comprendre la menace. Un hacking est un crime et tous les crimes ont un mobile. L’exploitation directe : ⁃ La vente de données personnelles (e-mails, adresses, téléphone) 100$/10M ⁃ La vente de numéro de carte bancaire (10$/+ données personnelles associées) ⁃ La vente d’accès backoffice (pack 700$ les 1500 accès). Investissement : ⁃ Revente de données techniques (cookie key/pwd mysql) ⁃ Les sources des modules installés permettent de trouver des vulnérabilités On est finalement sur une économie parfaitement circulaire où les vagues s’amplifient dans une effet boule de neige. Cela explique comment une agence qui a un module vulnérable ou travail avec un thème favori sur plusieurs sites peut se faire attaquer tous ses clients. Ce à quoi on échappe (dixit WordPress) : ⁃ Malware SEO ⁃ Malware de tests de validité de cartes bancaires ⁃ Les SIM jacking
- On s’aperçoit que les risques sont ressentis plus intensément quand le marchand est lui-même touché. Ainsi le vol des accès BO est très nettement considéré comme risque majeur. En revanche, le vol de CB reste pour 40% un risque considéré comme faible à modéré. On pourrait se dire que c’est parce que le marchand n’a rien à perdre sur le vol de CB, mais le vol de données personnelles plus majoritairement considéré comme majeur. C’est donc qu’il y a une méconnaissance de ce type de hack. Voyons donc les malwares trouvés sur PrestaShop.
- Le changement du module de paiement par un module frauduleux qui permet de capter au passage les numéros de cartes bancaires est dans les scénarii de hacking le plus courant. C'est pas étonnant, ça rapporte gros ! A ma connaissance il y a au moins deux formes : une simple, la plus courante, elle injecte dans la page de checkout un formulaire de saisie de CB pour détourner l’enregistrement. une version sophistiquée crée un formulaire dans le module de paiement pour rediriger le client sur ce formulaire et proxyfie le vrai formulaire du TPE. Ainsi les commandes sont confirmées car les paiements sont régulièrement encaissés y compris avec 3DS. Le formulaire peut passer des mois sans être détecté par le marchand. Indétectable, alors comment remonte-t-on la piste ? Voyons ce cas concret…
- Attention ce n’est qu’un exemple, certes le plus répandu mais il y a une multitude de hackers à l'affût.
- Cet exemple montre que la majorité des cas actuel est simple voire grossier mais que la complexification des attaques est une vraie menace pour les mois / années à venir.
- xx% (donnée réservée aux présents à la conférence) des PrestaShop seraient à date facilement hackable, c’est à dire qu’il possèdent au moins une critique sur un module non patché. Plusieurs dizaines de milliers d’IP d'attaques sont engagés par au moins trois réseaux criminels. Un pic d’explorations malicieuses en avril. Un manque de données pour établir un prévisionnel d’attaques. Mais il y a aujourd’hui soit des outils des hackers qui ont des filets trop gros, soit et c’est plus vraisemblablement collecte des data pour attaquer plus tard. Une prévision à 3 ans pessimiste.
- On est entre nous, on se dit tout. Moitié d’accord et moitié pas d’accord. Quand le core ajoute une fonctionnalité de suppression des requêtes multiples séparera des ;cela tue 90% des injections sql malicieuses.
- Assainir l’écosystème PrestaShop va prendre du temps et l'objectif ambitieux mais raisonnable serait d’atteindre la réduction de 30 points la part de boutique facilement hackable.
- C’est évidemment une question rhétorique. La question n’est pas de savoir si la réponse doit être communautaire, mais plutôt si tout le monde va mouiller le maillot devant l’urgence de la situation. De la pertinence et de la vigueur de la riposte dépendra la solidité du projet PrestaShop pour les 5 prochaines années. Le premier frein à lever c’est le facteur humain qu’on appelle effet témoin ou dilution de la responsabilité. Une boutique PrestaShop est est ligne parcequ’il y a l’équipe core, des addons de plusieurs éditeurs, une agence, un hébergeur… plus il y’a d’acteurs plus chacun se dit que l’autre va faire quelques choses et moins on a de chance que ça bouge. Sauf que sécurité, ce doit être l’affaire de tous et chacun va devoir prendre sa part car la défaillance d’un maillon remet en cause la solidité de toute la chaîne.
- Découvrir une faille, c’est finalement la partie la plus facile. En revanche traiter avec rigueur la divulgation c’est un effort colossal qui est produit à chaque fois. Chaque éditeur qui a une faille doit créer ses propres CVE et ne plus cacher ses failles. Les vuln font partie du développement. Il faut former pour minimiser. Vous devez être sous tension. Aujourd’hui, les réseaux ont une longueur d’avance et hack avant qu’ont ait la possibilité de publier une CVE.
- Travailler sur une vulnérabilité c’est un travail ingrat, on travaille pendant des heures pour quelques rares remerciements en retour de nombreux rejets. C’est un vrai travail de taupin. De plus, il faut ajouter le doute permanent de tout développeur sérieux qui le rend humble. Quand on a commencé, on hésitait , partagé sur le bénéfice risque des CVE sans jamais être sur d’être sur la bonne voie, constamment dans un syndrome de l’imposteur. Mais les chiffres sont là. Il n’y a qu’une voie possible, celle d’assumer pour purger les vulnérabilités et pouvoir passer à autre chose. Malgré la pédagogie et les heures passées à expliquer le bien fondé de la démarche, certains éditeurs ne jouent pas le jeu. Or la honte doit changer de camp, je vais donc citer XXX qui refuse que nous publions une CVE les concernant, XXX et XXX qui fait de l’obstruction volontaire à nos demandes de correction, Webbax qui refuse de corriger des modules gratuits et publiques qu’il sait vulnérable. Carton rouge également aux revendeurs Envato Themeforest et les auteurs des thèmes Léo, Joomaster, … A contrario, j’adresse mes félicitations à Store commander, Opart qui publient leurs propres CVE ainsi qu’à PayPal et Shoppingfeed qui nous soutiennent et ont accepté de publier sur les repo de leur module leurs CVE et ont également montré la voie à suivre.
- - Déphasage de plus en plus fort entre le besoin de compétence et le niveau de compétence par refus d'apprendre aux développeurs à attaquer ce qui par effet de bord, les empêchent de savoir défendre. Si vis pacem, para bellum. - Refus de payer pour des plans d'atténuation des risques professionnels - l'infogérance / hébergement coûte toujours trop cher - Pourquoi payer quelqu'un d'invisible et donc inutile ?