Injection SQL dans les modules PrestaShop : comment détecter les faux administrateurs

Vous ouvrez la liste des employés dans le back-office et vous voyez des comptes que vous n'avez pas créés. Parfois un seul, parfois plusieurs à la suite, avec des adresses e-mail similaires et tous avec le profil SuperAdmin. Personne ne s'est connecté avec votre mot de passe : un programme les a écrits directement dans la base de données, en exploitant un module présentant une faille d'injection SQL.

C'est l'un des schémas d'attaque les plus fréquents contre PrestaShop. Voyons comment il fonctionne, comment le détecter et que faire.

Ce qu'est une injection SQL, dans une boutique

Un module reçoit une donnée de la requête (un identifiant, un texte de recherche, un filtre) et l'insère dans une requête à la base de données sans la nettoyer. Si, au lieu du nombre attendu, arrive un morceau de SQL, la base de données l'exécute. Dans PrestaShop, la défense de base est simple : convertir en entier ce qui doit être un nombre et passer par pSQL() ce qui est du texte. Le problème, c'est que tous les modules ne le font pas à chacun de leurs points d'entrée.

Les plus dangereux sont les contrôleurs front des modules : des URL publiques, accessibles sans connexion, prévues pour le panier, une recherche en Ajax, un filtre ou le retour d'une passerelle de paiement. Si l'un d'eux présente la faille, n'importe qui sur Internet peut l'exploiter.

À quoi ressemble une campagne typique

1. Scan massif. Un robot parcourt des milliers de boutiques à la recherche de modules présentant des vulnérabilités connues. Il ne vous choisit pas : il lui suffit que vous ayez installé la version vulnérable.
2. Exploitation. Il envoie la requête qui injecte un INSERT dans la table des employés, ou un UPDATE qui élève le profil d'un compte existant.
3. Rafale. Comme le robot ne sait pas si cela a fonctionné, il recommence. C'est pourquoi on trouve souvent plusieurs comptes créés presque en même temps, avec des identifiants consécutifs.
4. Utilisation ultérieure. Avec le compte, quelqu'un entre dans le back-office, installe un module qui est en réalité une porte dérobée, modifie les données d'un moyen de paiement ou injecte un skimmer dans le template du checkout.

Comment le détecter dans ps_employee

La table des employés (avec le préfixe de votre boutique, généralement ps_) est petite et facile à vérifier. Depuis phpMyAdmin ou l'outil de base de données de votre hébergeur :

SELECT id_employee, firstname, lastname, email, id_profile, active, last_passwd_gen FROM ps_employee ORDER BY id_employee DESC;

Ce qu'il faut regarder :

• id_profile = 1 correspond au profil SuperAdmin. Comptez combien vous en avez et vérifiez que vous les reconnaissez tous.
• Des identifiants consécutifs en fin de liste que personne de votre équipe n'a créés.
• Des adresses e-mail hors de votre domaine ou avec des noms génériques.
• Des prénoms et noms vides ou répétés, ce qu'une création depuis le back-office ne permet pas.
• last_passwd_gen avec des dates qui ne correspondent à aucune création dont vous vous souvenez.
• D'anciens comptes dont le profil a changé : un employé de la logistique qui devient soudain SuperAdmin.

Lors de la même vérification, regardez aussi les comptes webservice (Paramètres avancés → Webservice). Une nouvelle clé d'API avec droit d'écriture sur la configuration est une porte qui survit au changement de tous les mots de passe et qui n'apparaît pas dans le menu des employés.

Que faire si vous en trouvez un

1. Ne supprimez pas tout de suite : désactivez. Rendez le compte inactif et conservez ses données. Elles vous serviront à savoir depuis quand et ce qu'il a fait.
2. Vérifiez ce qu'il a touché. Les modules installés récemment, les modifications de la configuration des moyens de paiement (IBAN du virement, clés de passerelle), les templates du checkout, les employés et le webservice, ainsi que les URL de la boutique.
3. Cherchez de nouveaux fichiers. En général, une fois l'accès obtenu, une porte dérobée a été laissée sur le disque. Comparez le cœur et les modules avec leurs paquets d'origine.
4. Identifiez le module vulnérable. Les journaux d'accès du serveur montrent généralement des requêtes étranges vers un contrôleur de module juste avant l'apparition du compte. Ce module doit être mis à jour ou retiré.
5. Changez les identifiants : les mots de passe de tous les employés, les clés webservice et, s'il y a des indices que la configuration a été lue, le mot de passe de la base de données.
6. Vérifiez les commandes récentes auprès de la banque ou de la passerelle, au cas où de l'argent aurait été détourné.

Pourquoi la prévention passe par la mise à jour des modules

Les campagnes massives n'utilisent presque jamais de failles inconnues. Elles utilisent des vulnérabilités publiées, souvent avec un correctif disponible depuis des mois. Le robot fonctionne parce que beaucoup de boutiques ne mettent pas à jour leurs modules, ou parce que le module vulnérable a été abandonné par son auteur et que personne ne l'a remplacé.

Quelques mesures concrètes :

• Un inventaire des modules avec leur version et leur origine. Savoir ce que vous avez est la première étape pour savoir ce qui vous concerne quand un avis est publié.
• Mettez à jour d'abord sur une copie puis en production, mais mettez à jour. Un module sans mise à jour depuis deux ans est un pari.
• Retirez ce que vous n'utilisez pas, y compris les dossiers de modules désinstallés qui restent sur le disque.
• Suivez les avis de sécurité de PrestaShop et des auteurs de vos modules.
• Gardez PrestaShop et PHP sur des versions supportées. Beaucoup de modules cessent de recevoir des correctifs pour les anciennes versions : si votre boutique est encore en 1.6 ou en 1.7 ancienne, chaque nouvel avis a plus de chances de rester sans solution pour vous, et la migration devient aussi une mesure de sécurité.

Un pare-feu applicatif peut bloquer une partie des tentatives, mais il ne remplace pas le correctif : les variantes d'une même injection sont nombreuses, et il suffit qu'une seule passe.

Comment le résoudre dans PrestaShop

RKR Security Alert conserve un instantané des employés, des modules, de la configuration, des URL de la boutique et des comptes webservice, et le compare à l'état actuel à chaque chargement du back-office et par cron. C'est pourquoi il détecte un SuperAdmin créé par injection SQL même sans qu'aucun hook n'intervienne, et le signale par Telegram comme alerte maximale, séparée du reste ; de même lorsqu'un compte existant est élevé au rang de SuperAdmin ou qu'un nouveau compte webservice apparaît. Son scanner comprend un analyseur d'injection SQL qui signale les valeurs de la requête qui arrivent dans une requête SQL sans conversion ni échappement. Si vous avez déjà un soupçon ou un incident sur les bras, avec un forfait d'heures de support Rekire nous réalisons l'audit, localisons le module par lequel ils sont entrés, nettoyons et laissons la boutique à jour.