Un exploit récemment découvert pourrait permettre à des attaquants distants de prendre le contrôle de votre boutique.
Les attaquants ont trouvé un moyen d’utiliser une vulnérabilité de sécurité pour effectuer l’exécution de code arbitraire sur les serveurs exécutant les sites Web PrestaShop. Pour plus de détails, veuillez lire l’intégralité de l’article.
Que ce 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 Web PrestaShop, leur permettant 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 jusque-là inconnue que nous corrigeons. Pour le moment, cependant, nous ne pouvons pas être sûrs que ce soit le seul moyen pour eux d’effectuer l’attaque. À notre connaissance, 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 inclut 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 fonctionne l’attaque
L’attaque nécessite que la boutique soit vulnérable aux exploits d’injection SQL. A 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 magasins en utilisant des logiciels ou des modules obsolètes, des modules tiers vulnérables ou une vulnérabilité encore à découvrir.
D’après nos conversations avec les propriétaires de boutiques et les développeurs, le mode opératoire 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 se traduit par 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, lui permettant d’exécuter des instructions arbitraires.
Après que les attaquants aient réussi à prendre le contrôle d’un magasin, ils ont injecté un faux formulaire de paiement sur la page de paiement du front-office. Dans ce scénario, les clients de la boutique pourraient entrer leurs informations de carte de crédit sur le faux formulaire et l’envoyer sans le savoir aux attaquants.
Bien que cela semble être le modèle courant, les attaquants peuvent en utiliser un autre, en plaçant un nom de fichier différent, en modifiant d’autres parties du logiciel, en plantant du code malveillant ailleurs ou même en effaçant leurs traces une fois l’attaque réussie.
Que faire pour assurer la sécurité de votre boutique
Tout d’abord, assurez-vous que votre boutique et tous vos modules sont mis à jour avec 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 les fonctionnalités de stockage de cache MySQL Smarty dans le cadre du 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’à la publication d’un correctif, nous vous 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') {
inclure PS_CLASS_DIR.'Smarty/SmartyCacheResourceMysql.php' ;
$smarty->caching_type = 'mysql';
}
Comment savoir si vous avez été affecté
Pensez à consulter le journal d’accès de votre serveur pour 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, comme 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, comme 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"
(Remarque : le chemin du module vulnérable a été modifié pour des raisons de sécurité)Sachez que ne pas trouver ce modèle dans vos logs ne signifie pas nécessairement que votre boutique n’a pas été affecté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 essayer de cacher leurs traces. .
Pensez à contacter un spécialiste pour réaliser un audit complet de votre site et assurez-vous qu’aucun fichier n’a été modifié ni qu’aucun code malveillant n’a été ajouté.
Informations Complémentaires
PrestaShop 1.7.8.7 a été publié pour renforcer le stockage du cache MySQL Smarty contre les attaques par injection de code.
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 mettre à jour régulièrement à la fois votre logiciel PrestaShop et ses modules, ainsi que votre environnement serveur.
Article original en anglais sur le site de Prestashop : https://build.prestashop.com/news/major-security-vulnerability-on-prestashop-websites/
