Boutique PrestaShop piratée : pourquoi un nettoyage ne suffit pas à sécuriser une boutique – Cas « Mandoline »
Une boutique PrestaShop compromise, un web skimmer pour voler les numéros de carte de paiement, un nettoyage réalisé par le développeur … et un pirate toujours installé.
Ce retour d’audit montre pourquoi « nettoyé » ne veut pas dire « sécurisé », et ce qu’il faut vérifier avant de considérer un incident comme clos.
Le contexte
Le scénario est malheureusement classique. Une boutique PrestaShop est compromise et le pirate y installe un web skimmer : un malware qui vole les numéros de carte de paiement saisies par les clients et les exfiltre vers un serveur qu’il contrôle.
Le développeur de la boutique identifie le script, le supprime et remet la boutique en ligne. Prudent, le responsable de la boutique « Mandoline » nous mandate pour un audit. Il veut s’assurer que le site ne sera pas compromis dans la foulée. Il avait raison de douter.
C’est contre-intuitif, mais un nettoyage n’a rien de dissuasif. Le pirate sait que la majorité des nettoyages sont incomplets : on supprime le symptôme visible : le web skimmer, parfois le vecteur d’entrée, rarement la persistance.
Lors de la première intrusion, un pirate prépare habituellement leur retour : mise en place de backdoors dissimulées dans le code et collecte d’informations sensibles.
Le fait qu’il a été identifié n’a rien d’effrayant ; il y a très peu de chances qu’il y ait des suites judiciaires et/ou qu’on puisse remonter sa trace.
La mission
Un premier nettoyage ayant déjà eu lieu, reconstituer le mode opératoire initial devient difficile : fichiers supprimés ou remplacés, traces écrasées. Et comme la boutique a évolué depuis, ce travail de forensic aurait de toute façon une valeur limitée.
Notre mission consiste donc à déterminer si la boutique est complètement sécurisée. Pour cela, nous suivons habituellement 3 axes :
- État de l’application et du serveur : versions de PrestaShop et des modules, intégrité des fichiers, configuration serveur, tâches planifiées, comptes et accès.
- Technical data disclosure : informations exposées publiquement qui facilitent une attaque (versions, fichiers de configuration, sauvegardes, logs, répertoires listables, en-têtes HTTP trop bavards).
- Test d’intrusion (Pentest) : recherche de faiblesse et tentative d’exploitation, pour mesurer le risque réel et non théorique.
Ce que nous avons trouvé
1. Un pirate toujours installé
Malgré le nettoyage, nos outils ont identifié 4 malwares, actifs ou en attente, sur le serveur :
- Un webskimmer a été réinstallé
- Un outil d’exfiltration des accès Back Office, à chaque login
- Un outil de création de compte Back Office (backdoor) non utilisé, mais déposé pour un usage ultérieur
- Une tâche cron qui vérifie la présence de la backdoor et la remet en place si supprimée
Ce dispositif illustre une persistance en couches : l’exfiltration des identifiants permet de se reconnecter même si les mots de passe sont changés, la backdoor dormante sert de solution de repli, et la tâche cron protège l’ensemble contre le nettoyage.
Le cron est l’élément le plus instructif. Une tâche planifiée se configure au niveau du système ou de l’hébergement (crontab, panneau d’administration), un endroit qu’un nettoyage centré sur le code de la boutique n’inspecte généralement pas.
Conséquence directe : changer les mots de passe avant d’avoir supprimé ces mécanismes ne sert à rien. Les nouveaux identifiants partent chez le pirate dès la première connexion.
2. Une surface d’attaque largement ouverte
Au-delà de la compromission active, l’audit a révélé de nombreuses faiblesses. Aucune n’est complexe. Cumulées, elles expliquent à la fois l’intrusion initiale et la facilité avec laquelle le pirate s’est propagé.
Des modules avec des failles publiques
Plusieurs modules installés présentaient des vulnérabilités publiquement documentées : c’est très probablement le vecteur d’entrée initial. Sur PrestaShop, les modules tiers sont la première source de compromission. Une faille publiée est exploitée à grande échelle par des scans automatisés, souvent dans les jours qui suivent son identification.
Pour rappel : ni la désactivation ni la désinstallation d’un module ne suppriment les fichiers du serveur, et leurs scripts PHP restent souvent appelables directement par URL. Un module inutilisé doit être supprimé, fichiers compris.
Aucune protection sur les accès sensibles
Ni le cPanel, ni le FTP, ni le back-office ne bénéficiaient de protections complémentaires : pas de restriction par IP, pas d’authentification à deux facteurs. Une fois un premier identifiant obtenu, le pirate pouvait rebondir d’un accès à l’autre sans obstacle.
Une configuration serveur trop permissive
- Aucune politique d’inclusion de ressources externes. Sans en-tête Content-Security-Policy, le navigateur charge n’importe quel JavaScript ou iframe injecté, depuis n’importe quel domaine. Des directives script-src, frame-src et connect-src restrictives auraient empêché le skimmer de charger son code ou d’envoyer les données vers un domaine tiers.
- Une configuration TLS trop permissive, mise en évidence par un test SSL Labs. L’objectif : n’accepter que TLS 1.2 et 1.3 avec des suites de chiffrement modernes, et activer HSTS.
- Aucune restriction d’accès aux fichiers. Les fichiers qui n’ont pas vocation à être servis (configuration, logs, archives, dumps SQL) doivent être bloqués au niveau du serveur web, et l’exécution de PHP interdite dans les répertoires d’upload.
- Aucune restriction sur les API des services tiers. Certaines API permettaient d’obtenir des informations sensibles, voire de récupérer des données des clients. Quand le service le permet, il faut restreindre l’accès à l’API aux adresses IP de l’éditeur dudit service.
Pas d’outil de blocage ni de détection
Aucun WAF ni outil de surveillance de connexion au Back Office, ni outil de surveillance d’intégrité des fichiers (FIM) n’était en place. Un WAF comme Prestefence aurait pu bloquer l’exploitation des failles de modules connues. Un outil de surveillance de connexion au Back Office (intégré à Prestafence) aurait permis de détecter les connexion suspectes. Un FIM aurait signalé la création ou la modification de fichiers : le skimmer, les scripts d’exfiltration, la backdoor redéposée par le cron.
Des sauvegardes stockées sur le serveur
Des sauvegardes étaient conservées sur le serveur lui-même. À portée du pirate, elles exposent la base complète (clients, commandes, hash des mots de passe) et les fichiers de configuration, dont la cookie key. Les sauvegardes doivent être externalisées, et jamais placées dans le webroot.
Pas de procédures de sécurité
Aucune revue régulière des accès sensibles (comptes BO, FTP, SSH, hébergeur, clés API), et aucune rotation des éléments de sécurité comme l’URL du back-office ou la cookie key (attention à ne faire que si vous savez ce que vous faites).
À retenir
Un bon développeur n’est pas automatiquement un spécialiste de la cybersécurité.
Ce n’est pas une question de compétence ; c’est un autre métier, qui exige une veille permanente sur les méthodes et les outils des attaquants. Nous réalisons plusieurs nettoyages de boutiques PrestaShop chaque mois : c’est ce volume qui nous permet de maintenir notre expertise.
Au delà du rapport et des recommandations, nous avons organisé un partage d’expérience avec le développer pour l’aider sur ses prochains projets.
Sans outil, vous travaillez dans le noir.
Les pirates font tout pour rester invisibles. Sans outil, il est très difficile de détecter une activité anormale. PrestaFence supervise notamment les connections au Back Office et alerte en cas de comportement anormal.
Le nettoyage ne fait pas fuir le pirate.
Bien au contraire : cela fait pleinement partie du cycle de vie de l’exploitation parasite d’une boutique en ligne.