Des attaquants ont trouvé un moyen d’utiliser une vulnérabilité de sécurité pour effectuer une exécution de code arbitraire dans les serveurs hébergeant des sites PrestaShop. Pour plus de détails, veuillez lire l’article dans son intégralité.
Que se passe-t-il ?
L’équipe de maintenance a été informée que des acteurs malveillants exploitent une combinaison de vulnérabilités de sécurité connues et inconnues pour injecter du code malveillant dans les sites PrestaShop, ce qui leur permet d’exécuter des instructions arbitraires, et potentiellement de voler les informations de paiement des clients.
En enquêtant sur cette attaque, nous avons découvert une chaîne de vulnérabilités inconnue jusqu’alors, que nous sommes en train de corriger. Cependant, pour le moment, nous ne pouvons pas être sûrs que c’est le seul moyen pour eux de réaliser l’attaque. Dans l’état actuel de nos connaissances, ce problème semble concerner les boutiques basées sur les versions 1.6.0.10 ou supérieures, sujettes à des vulnérabilités d’injection SQL. Les versions 1.7.8.2 et supérieures ne sont pas vulnérables, à moins qu’elles n’exécutent un module ou un code personnalisé qui comporte lui-même une vulnérabilité d’injection SQL. Notez que les versions 2.0.0~2.1.0 du module Wishlist (blockwishlist) sont vulnérables.
Comment l’attaque fonctionne-t-elle ?
L’attaque nécessite que la boutique soit vulnérable aux exploits d’injection SQL. À notre connaissance, la dernière version de PrestaShop et ses modules sont exempts de ces vulnérabilités. Nous pensons que les attaquants ciblent les boutiques utilisant des logiciels ou des modules obsolètes, des modules tiers vulnérables, ou une vulnérabilité qui n’a pas encore été découverte.
D’après nos conversations avec des propriétaires de boutiques et des développeurs, le modus operandi récurrent ressemble à ceci :
- L’attaquant soumet une requête POST au point de terminaison vulnérable à l’injection SQL.
- Après environ une seconde, l’attaquant soumet une requête GET à la page d’accueil, sans paramètres. Cela entraîne la création d’un fichier PHP appelé blm.php à la racine du répertoire de la boutique.
- L’attaquant soumet maintenant une requête GET au nouveau fichier qui a été créé, blm.php, ce qui lui permet d’exécuter des instructions arbitraires.
Après avoir réussi à prendre le contrôle d’un magasin, les attaquants ont injecté un faux formulaire de paiement sur la page de paiement du front-office. Dans ce scénario, les clients du magasin peuvent saisir les informations de leur carte de crédit sur le faux formulaire et les envoyer sans le savoir aux attaquants.
Bien que cela semble être le modèle commun, les attaquants peuvent en utiliser un autre, en plaçant un nom de fichier différent, en modifiant d’autres parties du logiciel, en plaçant un code malveillant ailleurs, ou même en effaçant leurs traces une fois l’attaque réussie.
Ce qu’il faut faire pour assurer la sécurité de votre boutique
Tout d’abord, assurez-vous que votre boutique et tous vos modules sont mis à jour dans leur dernière version. Cela devrait empêcher votre boutique d’être exposée à des vulnérabilités d’injection SQL connues et activement exploitées.
Selon notre compréhension actuelle de l’exploit, les attaquants pourraient utiliser la fonctionnalité de stockage en cache Smarty de MySQL comme vecteur d’attaque. Cette fonctionnalité est rarement utilisée et est désactivée par défaut, mais elle peut être activée à distance par l’attaquant. Jusqu’à ce qu’un correctif soit publié, nous recommandons de désactiver physiquement cette fonctionnalité dans le code de PrestaShop afin de briser la chaîne d’attaque.
Pour ce faire, localisez le fichier config/smarty.config.inc.php sur votre installation PrestaShop, et supprimez les lignes 43-46 (PrestaShop 1.7) ou 40-43 (PrestaShop 1.6) :
if (Configuration::get(‘PS_SMARTY_CACHING_TYPE’) == ‘mysql’) {
include _PS_CLASS_DIR_.’Smarty/SmartyCacheResourceMysql.php’;
$smarty->caching_type = ‘mysql’;
}
Comment savoir si vous êtes concerné ?
Pensez à regarder le journal d’accès de votre serveur pour trouver le modèle d’attaque expliqué ci-dessus.
Voici un exemple partagé par un membre de la communauté :
- [14/Jul/2022:16:20:56 +0200] « POST /modules/XXX/XXX.php HTTP/1.1 » 200 82772 « – » « Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_1) AppleWebKit/602.2.14 (KHTML, like Gecko) Version/10.0.1 Safari/602.2.14 »
- [14/Jul/2022:16:20:57 +0200] « GET / HTTP/1.1 » 200 63011 « – » « Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.98 Safari/537.36 »
- [14/Jul/2022:16:20:58 +0200] « POST /blm.php HTTP/1.1 » 200 82696 « – » « Mozilla/5.0 (Windows NT 10.0; WOW64; rv:50.0) Gecko/20100101 Firefox/50.0 »
(Note : le chemin du module vulnérable a été modifié pour des raisons de sécurité)
Sachez que le fait de ne pas trouver ce schéma dans vos journaux ne signifie pas nécessairement que votre boutique n’a pas été touchée par l’attaque : la complexité de l’exploit signifie qu’il existe plusieurs façons de l’exécuter, et les attaquants peuvent également tenter de dissimuler leurs traces.
Pensez à contacter un spécialiste pour effectuer un audit complet de votre site et vous assurer qu’aucun fichier n’a été modifié et qu’aucun code malveillant n’a été ajouté.
Information complémentaire
Une version corrective est actuellement en cours de test, et devrait être publiée prochainement.
Nous aimerions profiter de l’occasion pour souligner une fois de plus l’importance de maintenir votre système à jour pour prévenir de telles attaques. Cela signifie la mise à jour régulière de votre logiciel PrestaShop et de ses modules, ainsi que de votre environnement serveur.
