Sécurité Magento 2 : corriger, détecter et bloquer ClickFix, PolyShell et CosmicSting
Les boutiques Magento 2 et Adobe Commerce sont une cible permanente des campagnes d'exploitation automatisées. Chaque nouvelle version 2.4.x embarque une série de correctifs de sécurité, et les attaquants analysent ces correctifs en quelques jours pour construire des exploits fonctionnels contre les boutiques qui n'ont pas encore été mises à jour. Cet article décrit les menaces les plus marquantes observées ces derniers mois, la manière de reconnaître les traces qu'elles laissent sur un serveur et les étapes concrètes pour les éliminer et prévenir la prochaine intrusion.
Pourquoi les installations 2.4.x non corrigées sont la cible principale
Adobe publie à intervalle régulier des bulletins de sécurité pour Magento Open Source et Adobe Commerce, et chaque bulletin énumère les vulnérabilités corrigées dans la version concernée. Le délai entre la publication d'un correctif et l'apparition d'une preuve de concept publique se compte désormais en heures et non en semaines. Une boutique qui reste sur un niveau de correctif ancien exécute de fait des vulnérabilités déjà publiées et armées. La première contre-mesure est donc toujours la même : mettre le cœur à jour vers la dernière version sécurisée et appliquer tous les correctifs et correctifs urgents publiés pour votre branche.
ClickFix : la fausse case de vérification humaine
ClickFix est une technique d'ingénierie sociale qui n'exploite pas Magento directement, mais abuse de la confiance que les visiteurs accordent à une interface familière. Sur une boutique compromise, la page de commande ou la page d'atterrissage est modifiée pour afficher un faux widget Cloudflare « vérifiez que vous êtes humain ». Le visiteur coche la case exactement comme sur une page de vérification légitime, et un script est copié silencieusement dans le presse-papiers. Rien de dangereux ne se produit à cet instant, et la page peut même sembler continuer normalement.
Le danger survient à la deuxième étape. La fausse page demande au visiteur d'ouvrir une fenêtre de terminal sous macOS ou Windows et d'y coller le contenu copié pour terminer la vérification. S'il obtempère, la commande collée télécharge et exécute une charge de second niveau sur la machine du client. La règle pour les utilisateurs est simple et absolue : ne jamais coller dans un terminal une commande provenant d'une page web. La règle pour les administrateurs est de trouver le script injecté, de le supprimer et de fermer le point d'entrée qui a permis la modification.
Compromission côté serveur : PolyShell, CosmicSting et env.php
Plusieurs familles de vulnérabilités dominent les rapports d'incident Magento 2. PolyShell exploite les téléversements de fichiers sans restriction via l'API REST pour déposer des fichiers polyglottes qui sont à la fois des images valides et du PHP valide. CosmicSting vise le moteur de templates et peut conduire à une exécution de code à distance sans authentification. StyleSmuggler et BlockStrap suivent des schémas similaires d'injection dans les templates et de contournement de filtres. Dans les cas les plus graves, l'attaquant lit env.php, en extrait les clés cryptographiques et forge des jetons d'administrateur valides, ce qui lui assure un accès persistant au back-office même après la fermeture du chemin vulnérable.
| Vulnérabilité | Vecteur d'attaque | Impact |
|---|---|---|
| PolyShell | Téléversement sans restriction via l'API REST | Fichier PHP polyglotte stocké dans pub/media |
| CosmicSting | Injection dans le moteur de templates | Exécution de code à distance sans authentification |
| StyleSmuggler | Contournement de templates et de filtres | Injection de code et fuite de données |
| BlockStrap | Défaut de validation des entrées | Accès au back-office et vol de clés |
| ClickFix | Script injecté côté frontend | Logiciel malveillant exécuté sur les machines des visiteurs |
Rechercher du code obfusqué dans app, vendor et cache
Le code malveillant est rarement évident. Les attaquants le dissimulent dans des templates .phtml standard, dans les modules du cœur et dans les fichiers générés des répertoires cache et var. Une recherche textuelle des mots-clés habituels ne renvoie souvent rien, car la charge est assemblée à l'exécution à partir de chaînes base64 ou de plusieurs fragments concaténés. Un cas récent concernait un fichier .phtml infecté dans le dossier vendor, modifié très légèrement, avec la chaîne malveillante répartie sur plusieurs variables.
Comparez votre installation à une copie propre de la même version. Utilisez un contrôle d'intégrité des fichiers, examinez les dates de modification et inspectez tout fichier qui diffère du paquet officiel. Lorsque vous trouvez un fichier infecté, ne vous contentez pas de supprimer la charge : restaurez la version d'origine depuis l'archive officielle, puis mettez à jour ou bloquez le chemin vulnérable qui a permis l'écriture.
pub/media ne doit jamais contenir de PHP
Le répertoire media est destiné à stocker des images, des PDF et d'autres ressources statiques. Aucune raison légitime ne justifie la présence d'un fichier .php, .php7, .phtml ou .phar sous pub/media. Les attaquants en déposent pourtant en permanence, et les cachettes favorites sont pub/media/custom_options/ et pub/media/custom_options/quote/, où sont enregistrés les fichiers d'options téléversés. Analysez ces répertoires de manière récursive, supprimez tout fichier exécutable et vérifiez que la configuration des téléversements rejette les extensions inattendues.
Bloquer en amont avec Cloudflare, Nginx et Apache
Nettoyer le serveur ne suffit pas si le point d'entrée reste ouvert. Bloquez les chemins vulnérables avant que la requête n'atteigne Magento. Dans Cloudflare, vous pouvez créer une règle WAF qui refuse les requêtes vers /pub/media/custom_options/ et les répertoires similaires, ou qui soumet à un défi toute requête tentant d'atteindre un fichier PHP dans le chemin media. Sur le serveur d'origine, ajoutez des règles équivalentes dans Nginx ou Apache afin que la protection reste active lorsque le trafic contourne le CDN.
Gardez à l'esprit qu'une règle en amont n'arrête que les requêtes que vous connaissez déjà. Associez-la au correctif, à la surveillance des fichiers et à un audit périodique du code.
Liste de contrôle de remédiation
| Étape | Action |
|---|---|
| 1 | Mettre Magento à jour vers la dernière version 2.4.x et appliquer tous les correctifs de sécurité |
| 2 | Analyser app, vendor, cache et var à la recherche de fichiers obfusqués ou modifiés |
| 3 | Restaurer les fichiers d'origine depuis le paquet officiel |
| 4 | Supprimer tout fichier PHP, php7, phtml et phar de pub/media |
| 5 | Renouveler les clés de chiffrement et invalider les sessions administrateur existantes |
| 6 | Bloquer les chemins vulnérables dans Cloudflare, Nginx ou Apache |
| 7 | Supprimer et régénérer tous les caches et le code compilé |
Conclusion
La sécurité de Magento est un cycle, pas une tâche unique. Corrigez rapidement, vérifiez l'intégrité de vos fichiers, gardez le code exécutable hors du répertoire media et bloquez les chemins dont vous n'avez pas besoin. Si vous soupçonnez une injection ClickFix, avertissez immédiatement vos clients : le moyen le plus rapide de limiter les dégâts est de veiller à ce que personne ne colle quoi que ce soit dans un terminal.
Travaillons ensemble
Vous avez besoin de plus d'informations, d'aide pour votre projet ou pour développer une idée?
Qu'il s'agisse d'une question simple, d'un doute rapide ou d'une discussion de 5 minutes, envoyez-moi un message—cela ne coûte rien et je suis toujours prêt à vous aider. J'aime comprendre un problème, être créatif dans les solutions et me concentrer sur des idées simples, fiables et faciles à réaliser rapidement.
Me contacter →