Faille critique sur Prestashop

Encore une faille 😰

Vous trouverez l'explication détaillée ici : https://build.prestashop.com/news/major-security-vulnerability-on-prestashop-websites/

En gros, il s'agit d'une faille extrêmement critique (au vue du nombre d'articles parus sur le sujet) permettant à un attaquant de prendre littéralement le contrôle du site....

Prenons l''exemple classique de cette attaque :

• Étape 1 : Le hacker envoie une requête sur l'URL vulnérable (injection SQL) de type POST (comme l'envoi de données dans un formulaire)
• Étape 2 : Une seconde après, le hacker envoie une requête à la page d'accueil et génère automatiquement un fichier nommée : blm.php à la racine du site
• Étape 3 : Le hacker utilise ce fichier pour prendre prendre le contrôle du site et lui faire faire ce qu'il veut comme : ajouter un nouveau formulaire de paiement ou récupérer les numéro de cartes bleues...

On retrouve donc dans les journaux du site, les requêtes suivantes (exemple issu de la communauté Prestashop)

[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"

Il faut donc rapidement modifier votre site pour bloquer l'attaque initiale. Le plus rapide est d'éditer le fichier : config/smarty.config.inc.php et de supprimer les lignes 43-46 (Prestashop 1.7) ou 40-43 (Prestashop 1.6). Demander à votre développeur d'intervenir au plus vite si vous ne vous sentez pas capable de faire vous-même les modifications !

if (Configuration::get('PS_SMARTY_CACHING_TYPE') == 'mysql') {
    include _PS_CLASS_DIR_.'Smarty/SmartyCacheResourceMysql.php';
    $smarty->caching_type = 'mysql';
}

Failles et sécurité

Comme vous le savez sans doute, il n'existe pas à ce jour de logiciel sans aucunes failles. Ainsi il arrive parfois que certains utilisateurs (ou "hackers") plus malins que d'autres trouvent certains moyens détournés pour utiliser de manière illicite votre site voir même le serveur entier ! J'ai, pour ma part, arrêté de compter le nombre d'attaques journalières sur notre infrastructure. En guise d'exemple simple, sachez qu'un serveur de base comptabilise plusieurs milliers d'attaques cumulées par jour (web, FTP, mail, SSH...) C'est pour cette raisons que nos serveurs sont monitorés 24h/24. Avec l'expérience, une simple fil d'attente de mails trop pleine nous permet d’identifier un site vulnérable.

En fait, notre travail, en temps d''hébergeur n'est malheureusement pas de rendre nos hébergements "étanches" aux failles car cela nécessiterai soit :

• De rendre nos serveurs inaccessibles sur le réseau : un comble pour un hébergeur dont l'objectif principal est de permettre de rendre disponibles dans les meilleures conditions possibles les sites sous sa garde !
• De complexifier les accès : on peut en effet multiplier les systèmes de protections successifs pour limiter les attaques: login, mot de passe, authentification à 2 facteurs, VPN,... mais si pour acheter une nouvelle paire de boucle d'oreilles, il vous faut passer par une dizaine de protection invasives successibles, le e-commerçant est sûr de louper sa vente, et on comprend bien pourquoi !

Bref, nous sommes donc toujours sur le fil entre sécurité et utilisation ! C'est donc dans cette zone grise que s'engouffre les "hackers" pour tenter de détourner à leur profit votre site. Une grosse partie de notre travail est donc de limiter les marges de manœuvre de ce dernier sans impacter l'expérience utilisateur, c'est véritablement un métier !

Le mot de la fin...

Dans ce cas précis, nous ne pouvons malheureusement empêcher votre site d'être piraté puisque le problème vient du code source du site. Toutefois, nous pouvons constater le piratage et restaurer une sauvegarde des fichiers avant l'intervention du hacker sur votre site.

Voici le genre de commandes que vous pouvez utiliser, pour les plus administrateurs d'entre vous, afin de constater si l'un de vos sites a été piraté. L'exemple très simple suivant fonctionne sur Ubuntu/Debian avec un serveur sous Apache 2.4 depuis une fenêtre shell :

cat /var/log/apache2/*.access.log |grep POST|grep blm.php
cat /var/log/apache2/*.access.log.1 |grep POST|grep blm.php
zcat /var/log/apache2/*.access.log.*.gz |grep POST|grep blm.php

Bon courage à tous !