Faille Prestashop 2ème : des utilisateurs donnent leurs données de carte bleue (bien malgré eux)

Prestashop est un CMS (système de gestion de contenu) open-source permettant de créer des sites e-commerce. Il est utilisé sur plus de 300 000 projets.

Il y a 3 semaines, dans notre article précédent, nous vous avons parlé d’une faille permettant d’accéder aux données stockées dans la base de données et de la possibilité de les modifier. Une faille supplémentaire qui utilise cet accès à la base de données a été découverte en juillet 2022.

Elle permet à un attaquant d’accéder au serveur de l’application et de modifier le site internet. Ainsi, certains attaquants ont pu créer de faux formulaires de paiement pour récupérer les cartes bancaires des utilisateurs.

Cette faille nécessite auparavant que l’attaquant ait un accès à la base de données. Elle a donc pu être exploitée en se basant sur l’injection SQL dont nous avons parlé mi-août. Si vous avez manqué notre newsletter, n’hésitez pas à aller la lire!
Toute autre injection SQL présente sur le site attaqué permet également d’exploiter cette faille.

🕵️ Explication de la faille

Prestashop a observé un pattern commun dans les attaques menées:

• L’attaquant effectue une requête POST sur la route vulnérable à une injection SQL
• L’attaquant va sur la page d’accueil (requête GET sans paramètres) et un fichier blm.php est créé dans le dossier du site e-commerce.
• L’attaquant envoie une requête sur le fichier créé ce qui lui permet d’exécuter ensuite l’ensemble des actions de son choix car il a accès à un terminal de commandes (reverse shell)

Nous avons tenté de comprendre et nous avons fait des hypothèses sur le fonctionnement de la faille permettant à l’attaquant de prendre ensuite le contrôle d’un compte sur le serveur.

La faille est due aux données de paramétrage du cache de Smarty, le moteur de template de Prestashop. Ces paramètres sont mis dans la base de données et sont donc ensuite récupérés par Smarty Cache. Lors de cette récupération, Smarty Cache va lire les commandes qui ont été ajoutées par l’attaquant dans la base de données à son intention.

Ainsi, l’attaquant demande à Smarty Cache de créer un fichier avec un point d’entrée auquel il peut accéder, c’est le fichier blm.php.

Comme l’attaquant a ensuite accès au code, il peut récupérer des informations sur le serveur et il peut ajouter un formulaire de paiement pour récupérer les cartes des utilisateurs qui sont le plus souvent chiffrées dans la base de données et donc non exploitables. Les cartes sont ensuite envoyées au serveur de l’attaquant, c’est une attaque d’e-skimming.

Pour corriger cette faille, les développeurs de Prestashop ont ouvert une PR pour passer les paramètres de Smarty dans un fichier plutôt que dans la base de données. Elle a été mergée hier, mardi 13 septembre, par les développeurs de Prestashop et devrait être dans la prochaine release.

🛡 Comment se protéger ?

En tant que développeur utilisant Prestashop:

• Mettre à jour Prestashop et passer minimum à la version 1.7.8.7
• Mettre à jour lorsque la prochaine version sortira et choisir de sauvegarder la configuration de Smarty Cache dans le filesystem plutôt que dans la base de données.
• Désactiver Smarty Cache si vous ne l’utilisez pas.

En tant que développeur:

• Ne pas stocker la configuration des outils dans la base de données, surtout si ces outils ont des droits étendus comme créer des fichiers ou accéder au code.

En tant qu’utilisateur:

• Une fois vaut mieux que deux. Si le formulaire de paiement par carte bleue vous demande d’entrer deux fois de suite vos informations bancaires, il y a probablement quelque chose de louche. Contactez le site et votre banque.
• Vérifiez le niveau de langue. Tout comme pour les emails de phishing, les formulaires des attaquants sont parfois mal traduits ou même non traduits et présentent des erreurs de grammaire ou d’orthographe. Vous pouvez aussi comparer le design avec le reste du site.
• Réduire la page. Le formulaire de l’attaquant peut être assez simpliste (et être contenu dans une iframe) et ne pas s’adapter correctement à la modification de la taille de la page.
• Pour les utilisateurs un peu plus expérimentés. Un coup d’œil dans les outils de développement peut permettre de détecter un comportement inhabituel dans les requêtes envoyées par le formulaire de paiement. Une petite précision néanmoins : le simple fait d’ouvrir les outils de débogage sur une page de paiement suffit parfois à bloquer le fonctionnement du script malveillant.

🏹 Pour aller plus loin

• PR dans laquelle le problème a été remonté
• PR pour passer la configuration du cache Smarty dans un fichier
• Rapport sur la faille dans Prestashop et sa criticité 
• Rapport de Prestashop

Nous avons pour ambition de sécuriser le web, et pour atteindre cet objectif, nous avons besoin de vous ! Si vous avez des questions, des suggestions ou le moindre doute, n'hésitez pas à contacter notre équipe sécurité : security@theodo.fr.