Publié le

Vulnérabilité majeure de sécurité sur les sites PrestaShop

Une nouvelle faille de sécurité découverte sur PrestaShop

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 :

  1. L'attaquant soumet une requête POST au point de terminaison vulnérable à l'injection SQL.
  2. 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.
  3. 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.

Pour une mise ne oeuvre rapide sur votre boutique du correctif proposé, n'hésitez pas à me contacter.

Source

[Mise à jour 25/07/2022]

Version Patch disponible

Prestashop propose une nouvelle version 1.7.8.7 qui patch une partie du problème généré par cette faille.

Solutions tierces

Suite à l'alerte exposée par PrestaShop, plusieurs membres de la communauté se sont investis pour apporter une solution simple pour corriger la faille.

S'il existe, à ma connaissance, deux modules disponibles sur les comptes GitHub de leur créateur, ils semblent très restreints dans leurs actions et ne me semblent pas apporter de solution viable aux portes ouvertes dans PrestaShop.

Je vous les liste tout de même pour que vous puissiez vous faire votre propre opinion :

Et comme souvent, la meilleure solution semble venir d'Eolia qui propose un script simple à mettre en oeuvre :

  1. Télécharger l'archive
  2. La décompresser sur votre ordinateur
  3. Déposer le fichier cleaner.php à la racine de l'hébergement de votre boutique par FTP
  4. Appeler le fichier dans votre navigateur https://www.votre_domaine.tld/cleaner.php.
    https://www.votre_domaine.tld/ correspondant à l'url de la page d'accueil de votre boutique.
  5. Le fichier se mettra à jour automatiquement, pour profiter de la dernière version, puis lancera des scripts pour analyser votre installation et corriger les problèmes rencontrés, chaque problème sera identifié et accompagné d'une phrase explicative vous informant, si nécessaire, de la marche à suivre.

Pourquoi Eolia ne propose t il pas son script sous forme de module ?

Tout simplement pour éviter d'activer certains hacks puisqu'il faudrait lancer le backoffice de votre boutique et que certains fichiers pourraient être déjà hackés et donc activer ces hacks lors de leurs appels.

En gros, c'est plus sécuritaire de faire sans accéder à votre backoffice.

Discussions