Une faille PrestaShop est une erreur ou une fragilité dans le programme d'un site e-commerce, qui permet à un attaquant de contourner les protections normalement en place.
Concrètement, cela peut être :
Une faille PrestaShop ou également appelée vulnérabilité PrestaShop ne signifie pas qu'un site est déjà piraté, mais qu'il peut l'être, souvent sans que le marchand ne s'en rende compte.
Les failles PrestaShop apparaissent généralement au moment du développement, souvent à cause d'un oubli de validation des données dans un formulaire, une requête ou un lien.
PrestaShop en lui-même est très bien conçu, la quasi-totalité des failles exploitées provient de l'écosystème qui gravite autour de lui - modules gratuits ou mal maintenus, places de marché non officielles, souvent dépourvues de tout contrôle qualité professionnel.
Parmi la centaine de vulnérabilités PrestaShop que TouchWeb et son réseau ont détectées et faites corrigées, prenons pour exemple celle-ci de complexité faible (accessible à tous) :
CVE-2023-30199 - liée au module customexporter de Webbax et toujours activement exploitée.
Tous les programmes ont des fichiers sensibles - PrestaShop ne fait pas exception à la règle, tout comme WordPress, Magento, Joomla, etc.
Le fichier app/config/parameters.php est l'un des plus sensibles : il contient le login et le mot de passe de la base de données, mais aussi des secrets primordiaux, utilisés pour la génération d'autres secrets (tokens, clés, etc.).
Les programmes ont régulièrement besoin de lire des fichiers, et certains modules permettent à des tiers - n'étant pas administrateurs - de lire ces fichiers, parfois en leur laissant définir eux-mêmes le nom du fichier à lire.
Si cette pratique n'est pas rigoureusement encadrée, elle ouvre la voie à une classe de vulnérabilités appelée Path Traversal (identifiée sous le code CWE-22). Elle consiste à manipuler le chemin d'accès pour remonter dans l'arborescence du serveur et accéder à un fichier sensible.
Pour les plus techniques d'entre vous : nous reviendrons plus tard sur les classes de failles CWE-502 et CWE-918, qui peuvent aggraver l'impact d'une CWE-22.
Les failles de type CWE-22 peuvent naître d'un code aussi simple que celui-ci : readfile($_GET['nom_du_fichier']);.
Ici, une fonction de lecture de fichier combinée à l'absence de validation sur la variable nom_du_fichier permet à n'importe qui de lire n'importe quel fichier du serveur.
Dans le cas du module customexporter, la vulnérabilité se trouve dans le fichier suivant : modules/customexporter/download/download.php.
Pour récupérer le fichier maître de configuration de PrestaShop, il suffit de définir nom_du_fichier à cette valeur : ../../../app/config/parameters.php.
Cela permet aux attaquants de récupérer les accès à la base de données, puis de la piller si une interface d'administration est disponible (comme PHPMyAdmin, Adminer, etc.).
Plus sournois encore : cela donne également accès aux secrets primordiaux du Shop, qui servent à générer de nouveaux secrets permettant de déverrouiller des fonctionnalités sensibles d'autres modules.
Pour atténuer ce risque, une solution basique consiste à utiliser la fonction basename : readfile(basename($_GET['nom_du_fichier']));.
Cela tronque la variable pour n'en conserver que le nom de fichier, ici settings.inc.php, neutralisant ainsi l'exfiltration via path traversal.
Pour les plus techniques d'entre vous : nous vous encourageons à définir des politiques de sécurité basées sur des listes blanches aussi restrictives que possible. L'utilisation de basename reste perfectible, même si elle neutralise également certains schémas de chemin déclarés - comme ceux utilisés dans des variantes de la CWE-502 (exploitation via phar://) ou dans des attaques de type CWE-918 (SSRF).
Dans ce cas précis, s'il ne devait être possible de lire que des fichiers CSV, il aurait été préférable d'utiliser une expression régulière comme preg_match('#^[\w\-]+\.csv$#i', nom_du_fichier). Les expressions régulières sont vos alliées pour ce genre de contrôle. On sait que beaucoup d'entre vous les boudent, mais vous devriez faire l'effort : votre « vous » du futur vous remerciera.
Les groupes criminels explorent en continu les modules installés sur les shops exposés sur Internet.
La première étape d'une attaque est justement appelée phase d'exploration (ou P1 pour « phase 1 »).
Le mode opératoire varie selon le niveau de compétence des attaquants à la manœuvre, bien que la finalité soit toujours la même : confirmer la présence d'un module donné sur un shop.
config.xml ou logo.png à la racine des modules.
Après la phase 1, le criminel sait que vous utilisez le module qu'il cible. Plusieurs jours - voire plusieurs semaines - peuvent s'écouler avant le déclenchement de la phase 2. Celle-ci consiste à confirmer que la version du module utilisée est bel et bien toujours vulnérable.
La manœuvre peut être périlleuse : le criminel sait qu'il ne doit pas se faire repérer pendant cette phase. Il fera donc tout pour éviter d'envoyer des charges offensives susceptibles de déclencher une réponse de l'infrastructure de défense, comme par exemple un WAF.
Dans le cadre d'une faille de type CWE-22 (Path Traversal), le pirate sait que la quasi-totalité des tiers refusent d'allouer des budgets pour traiter les charges primordiale associées à cette classe - comme, par exemple, bloquer efficacement la séquence ../ (le propos vaut pour la plupart des classes).
Il sait également qu'il existe des variantes de certaines classes de vulnérabilités qui sont, par nature, très difficiles à neutraliser. C'est le cas de la CWE-98, variante “asset inoffensif”, qui exploite des appels vers des fichiers anodins - typiquement une image comme logo.png - pour contourner les protections classiques.
Partant de ces deux postulats, et dans une logique de minimisation du risque de détection, la charge non offensive utilisée pour confirmer la vulnérabilité ressemblera très probablement à ceci : ../logo.png.
Après la phase 2, le criminel sait que vous utilisez le module vulnérable qu'il cherche à exploiter. De nouveau, plusieurs jours - voire plusieurs semaines - peuvent s'écouler avant que la phase 3 ne débute.
C'est ici que l'attaque commence - ou, plus précisément dans le cas des CWE-22, que débute le pillage.
Les profils juniors, ainsi qu'une grande partie des pirates confirmés, tenteront de se connecter à vos interfaces d'administration de base de données (phpMyAdmin, Adminer…) pour extraire directement les données, faute de savoir exploiter les secrets primordiaux.
En revanche, les plus dégourdis des confirmés, ainsi que les profils seniors, sauront tirer parti de ces secrets primordiaux pour activer ou détourner des fonctionnalités critiques d'autres modules, souvent sans laisser de trace visible.
Pour la suite, nous vous prions de partir du principe que la quasi-totalité des CMS sont concernés par ce propos. Il ne s'agit pas d'un problème spécifique à PrestaShop, mais d'une fragilité structurelle liée à la génération de secrets secondaires à partir d'un secret primaire (ou primordial), lui-même souvent non blindé contre l'exploitation via une seule classe de vulnérabilité.
Nous vous invitons également à garder à l'esprit que certains processus - comme la protection des tâches planifiées (CRON) - ne peuvent pas s'en affranchir si facilement : par nature, ces processus ne sont généralement pas capables de gérer une authentification forte.
Les réseaux criminels professionnels ont déjà eu accès à des centaines de modules de l'écosystème et ont mené des analyses approfondies pour identifier tous ceux qui reposent sur des secrets dérivés d'un secret primordial.
Comment ? Simplement en scannant les dépendances dans les fichiers sources des modules.
Si vous souhaitez itérer cette analyse, il vous suffit de rechercher l'usage de certaines constantes et méthodes pour évaluer votre exposition potentielle en cas de fuite d'un secret primordial :
COOKIE_KEY : l'un des secrets primordiaux définis par PrestaShop.Tools::hash et Tools::encrypt : deux méthodes courantes appliquant une simple transformation de type MD5 sur un secret primordial pour générer un nouveau secret.Tools::getAdminToken : souvent utilisé par les développeurs qui ne passent pas par les AdminControllers.
Pour les plus techniques d'entre vous : find -L modules/ -type f -name "*.php" -exec grep -Pi 'cookie_key|tools::(getadmintoken\(|hash|encrypt)' {} \; -print
Après analyse des résultats, vous serez en mesure de distinguer ce qui est accessible à tout visiteur, de ce qui est restreint aux administrateurs. Vous comprendrez alors pourquoi il est crucial de changer les secrets primordiaux dès qu'une compromission est suspectée.
Nous rappelons que la plupart des failles CWE-22 de l'écosystème PrestaShop - notamment dans certains modules de Webbax ou Common-Services - sont activement exploitées depuis des années. Si vous ne pouvez pas garantir que vos secrets primordiaux ont été modifiés depuis, faites-le immédiatement.
À défaut, surveillez étroitement tous les modules qui utilisent ce type de secret, et restreignez-en l'accès par adresse IP de manière proactive.
Nous vous recommandons également la mise en place d'une surveillance continue des appels contenant des secrets réservés aux administrateurs, afin de détecter en amont les comportements suspects émanant d'acteurs malveillants organisés.
Les criminels professionnels ne cherchent ni la gloire ni le bruit : ils fuient la lumière, opèrent dans l'ombre, et misent sur votre inattention.
C'est justement là qu'il faut regarder. Ce n'est pas dans ce qui est visible que résident les plus grandes menaces, mais dans ce qui est ignoré, laissé sans surveillance, considéré comme anodin.
Éclairer les endroits les plus sombres de votre écosystème - secrets, modules, chemins d'accès oubliés - c'est reprendre l'initiative.
Ce que les criminels redoutent le plus, ce n'est pas un pare-feu. C'est la vigilance et la lumière qu'elle projette là où ils pensaient rester invisibles.
Retrouvez la suite de cet article ici : Pourquoi votre PrestaShop a subi un hack ?