Make (anciennement Integromat Connector) <= 1.5.10 — Téléchargement de fichiers arbitraires par un administrateur authentifié (CVE-2025-6085)

Date : 2025-09-03

Auteur : Expert en sécurité de Hong Kong

Résumé

CVE-2025-6085 affecte les versions du plugin Make (précédemment Integromat Connector) jusqu'à et y compris 1.5.10. Un administrateur authentifié peut télécharger des fichiers arbitraires sur le site via les points de terminaison de téléchargement du plugin. Bien que l'exploitation nécessite des identifiants d'administrateur, les conséquences peuvent être graves : webshells, exécution de code à distance, persistance et compromission totale du site.

Cet avis fournit une analyse technique, des scénarios d'attaque réalistes, des indicateurs de détection, un plan d'intervention en cas d'incident et des atténuations pratiques que vous pouvez appliquer immédiatement — avec un accent sur le durcissement opérationnel côté serveur et le patching virtuel lorsque cela est approprié.

Pourquoi les propriétaires de sites devraient s'en soucier même lorsque des privilèges d'administrateur sont requis

• Les identifiants d'administrateur sont souvent réutilisés, divulgués ou phishés ; un seul compte administrateur compromis permet une exploitation directe.
• De nombreux sites ont plusieurs administrateurs (développeurs, sous-traitants) ce qui augmente l'exposition.
• Les attaquants peuvent enchaîner d'autres bugs (XSS, CSRF, fixation de session) pour obtenir des sessions administratives et ensuite exploiter ce défaut de téléchargement.
• Une fois qu'un attaquant peut placer des fichiers exécutables sous le répertoire webroot, il peut exécuter du code, persister et pivoter à travers l'environnement.

Traitez cette vulnérabilité comme une priorité élevée même si elle nécessite une authentification d'administrateur.

Analyse technique (ce que signifie “téléchargement de fichiers arbitraires” ici)

Les vulnérabilités de téléchargement de fichiers arbitraires se produisent lorsque les téléchargements de fichiers sont stockés sans validation suffisante côté serveur de :

• Type de fichier et type MIME
• Extension de fichier
• Répertoire de destination
• Contenu du fichier (pour empêcher le code exécutable)
• Nom de fichier (pour empêcher le parcours de chemin)
• Vérifications d'autorisation sur le point de terminaison de téléchargement

Dans Make <= 1.5.10, le point de terminaison de téléchargement permettait à un administrateur authentifié de placer des fichiers arbitraires sur le disque. Si la destination est accessible via le web (uploads, répertoire des plugins), un attaquant peut télécharger un webshell PHP et l'invoquer via HTTP. Alternativement, les fichiers téléchargés pourraient être inclus plus tard par d'autres logiques d'application, entraînant une exécution de code à distance.

Composants typiques d'une telle exploitation :

• Un point de terminaison de téléchargement acceptant des données de fichier via POST
• Absence de vérifications strictes de type/extension/contenu côté serveur
• Destination de téléchargement accessible au serveur web
• Permissions de fichier permissives ou configuration du serveur web permettant l'exécution

Scénarios d'attaque réalistes

1. Administrateur malveillant ou compte administrateur compromis :

   Un compte administrateur de fournisseur ou de contractant compromis est utilisé pour télécharger un webshell PHP via le plugin, puis l'attaquant exécute des commandes pour persister et escalader.

2. Chaîne CSRF / XSS stocké :

   Un attaquant incite un administrateur à effectuer des actions ou exploite un XSS stocké pour obtenir une session privilégiée, puis télécharge une charge utile.

3. Backdoors persistants / abus de la chaîne d'approvisionnement :

   Les backdoors téléchargés survivent aux mises à jour ou sont utilisés pour altérer d'autres plugins/thèmes/fichiers principaux.

CVSS et contexte de risque

Le score CVSS publié est de 7.2. Le score reflète un impact élevé (possible exécution de code à distance / compromission du site) tandis que la complexité de l'attaque est modérée par l'exigence de privilèges administratifs. En pratique, les petits sites sont souvent à un risque plus élevé en raison d'une hygiène des identifiants faible et d'une surveillance limitée.

Détection : signes que vous avez peut-être été exploité

• Nouveaux fichiers PHP ou fichiers modifiés dans :
  • /wp-content/uploads/
  • /wp-content/plugins/make-connector/ (ou le nom du dossier du plugin)
  • Autres répertoires de plugins ou de thèmes
• Fichiers avec des noms étranges ou des doubles extensions (par exemple, .php.jpg, .phtml)
• Fichiers avec des horodatages correspondant à des connexions administratives suspectes
• Utilisateurs administrateurs non reconnus ou changements de rôle récents
• Tâches cron ou tâches planifiées suspectes
• Connexions sortantes du serveur web vers des IP ou des domaines inhabituels
• Journaux HTTP montrant l'accès à des fichiers nouvellement téléchargés ou des POST inhabituels vers des points de terminaison de plugin
• Fichiers .htaccess ou configurations de serveur modifiés permettant l'exécution

Outils de détection utiles : surveillance de l'intégrité des fichiers, journaux d'accès/d'erreur du serveur, scanners de logiciels malveillants et audits de base de données pour utilisateurs ou changements d'options suspects.

Étapes immédiates si vous exécutez le plugin affecté (triage des incidents)

1. Isoler et contenir
   • Mettre le site en mode maintenance ou le rendre hors ligne pour limiter les opérations de l'attaquant.
   • Si possible, bloquer l'accès HTTP public au niveau du pare-feu ou du serveur pendant l'enquête.
2. Préservez les preuves
   • Copier les journaux (accès/d'erreur web, FTP/SFTP, SSH), le dump de la base de données et les listings du système de fichiers dans un emplacement sécurisé pour l'analyse judiciaire.
   • Ne pas écraser les journaux ou redémarrer les systèmes critiques à moins que cela ne soit nécessaire pour le confinement.
3. Identifier et supprimer les fichiers suspects

   Rechercher des fichiers PHP récemment ajoutés et inspecter leur contenu. Préserver des copies judiciaires avant suppression.

   find /var/www/html/wp-content/uploads -type f -mtime -7 -print

   Rechercher des indicateurs de webshell comme base64_decode, eval, preg_replace avec /e, appels system/exec.

4. Changer les identifiants
   • Réinitialiser tous les mots de passe administrateurs et comptes de service (FTP, SSH, DB).
   • Forcer la déconnexion de tous les utilisateurs et expirer les sessions.
   • Faire tourner les clés API et les jetons utilisés par le site.
5. Vérifiez la persistance
   • Inspecter wp-config.php, mu-plugins, .htaccess et les fichiers PHP de thème/plugin pour du code injecté.
6. Restaurer à partir d'une sauvegarde connue comme bonne

   Si disponible, restaurer à partir d'une sauvegarde propre effectuée avant la compromission. Vérifier que le site restauré est corrigé et propre avant de se reconnecter à la production.

7. Mettez à jour ou supprimez le plugin

   1. S'il existe un correctif, appliquez-le immédiatement. S'il n'y a pas de solution disponible et que le plugin n'est pas essentiel, désinstallez-le et supprimez ses fichiers — la seule désactivation peut laisser des fichiers sur le disque.

8. Renforcer et surveiller
   • 2. Appliquez un durcissement côté serveur et mettez en place une surveillance continue pendant au moins plusieurs semaines après la remédiation.

3. Si vous n'avez pas confiance pour effectuer les étapes en toute sécurité, engagez votre fournisseur d'hébergement ou une équipe professionnelle de réponse aux incidents — un nettoyage incomplet peut laisser des portes dérobées persistantes.

4. Atténuations pratiques que vous pouvez appliquer immédiatement (aucun correctif au niveau du code requis)

5. Ces atténuations réduisent la surface d'attaque et limitent l'impact même lorsque le plugin vulnérable reste installé.

6. A. Bloquez les points de terminaison de téléchargement au niveau du WAF / serveur web

7. Créez des règles pour bloquer les requêtes POST vers les points de terminaison de téléchargement du plugin, sauf depuis des IP de confiance. Si votre pare-feu prend en charge le patching virtuel, bloquez les requêtes correspondant aux modèles d'exploitation (par exemple, POST vers admin-ajax.php avec un paramètre d'action spécifique).

8. Exemple de règle nginx pour refuser un URI de téléchargement de plugin spécifique :

9. location ~* /wp-admin/admin-ajax.php {

if ($request_method = POST) {.

if ($args ~* "action=make_upload") {

return 403;

10. Confirmez les noms d'action et les URI en inspectant la source du plugin et testez les règles d'abord sur un environnement de staging.

11. B. Désactivez l'exécution PHP dans les répertoires de téléchargement

Nginx (bloc serveur) :

12. Empêchez l'exécution de PHP à partir des fichiers téléchargés en configurant le serveur web :

13. Apache (.htaccess) pour /wp-content/uploads/ :.

14.

php_flag engine off.

D. Harden admin access

• .
• Supprimez les comptes administratifs inutilisés et limitez le nombre d'administrateurs au minimum.
• Utilisez des mots de passe forts et uniques ainsi qu'un gestionnaire de mots de passe.
• Restreignez l'accès à wp-admin par IP ou en utilisant l'authentification HTTP Basic si cela est opérationnellement possible.

E. Moindre privilège pour les processus PHP et les permissions de fichiers

• Assurez-vous que le serveur web fonctionne avec un compte utilisateur non privilégié.
• Définissez les permissions du système de fichiers de sorte que wp-content soit modifiable uniquement là où c'est nécessaire et que les fichiers de plugin ne soient pas modifiables par le monde ou le serveur web, sauf lors de la mise à jour.

F. Sauvegardes régulières et copies immuables

• Conservez des sauvegardes hors site quotidiennes et au moins un instantané immuable que le serveur web ne peut pas modifier.
• Testez les restaurations périodiquement.

G. Surveillance et alertes

• Utilisez la surveillance de l'intégrité des fichiers pour alerter sur les fichiers PHP nouveaux ou modifiés.
• Surveillez les connexions sortantes et les modèles de trafic anormaux.

WAF et patching virtuel : ce qu'ils font et pourquoi ils sont importants ici

Le patching virtuel applique des règles au niveau du pare-feu pour intercepter et bloquer les tentatives d'exploitation sans modifier le code de l'application. Lorsqu'un patch officiel n'est pas encore appliqué (ou ne peut pas être appliqué immédiatement), les patches virtuels offrent une protection immédiate.

Tactiques de patching virtuel courantes pour cette vulnérabilité :

• Bloquez les POST vers l'action de téléchargement de plugin spécifique sauf en provenance d'IP administratives de confiance.
• Bloquez les téléchargements multipart qui incluent des balises d'ouverture PHP ou des noms de fichiers se terminant par .php.
• Bloquez les requêtes avec des charges utiles multipart suspectes ou des paramètres inattendus.

Le patching virtuel est précieux pour une protection à court terme pendant que vous appliquez un patch, retirez le plugin ou effectuez une remédiation contrôlée.

Exemples de signatures WAF (modèles conceptuels)

Ce sont des modèles illustratifs ; testez soigneusement sur un environnement de staging pour éviter les faux positifs.

• Détecter les noms de fichiers se terminant par .php dans le téléchargement multipart :

  Condition : multipart/form-data && filename =~ /\.php(\d+)?$/i

• Bloquer les téléchargements contenant des balises PHP :

  Condition : request_body contient “<?php”

• Bloquer les POST vers l'action de téléchargement du plugin :

  Condition : POST && request_uri contient “/wp-admin/admin-ajax.php” && args contient “action=make_upload”

Sécurité à long terme : liste de contrôle pour les développeurs et les propriétaires de sites

• Gardez le cœur de WordPress, les thèmes et les plugins à jour ; abonnez-vous aux flux de vulnérabilités pour une prise de conscience rapide.
• Limitez les comptes administrateurs et auditez régulièrement les rôles.
• Appliquez l'authentification à deux facteurs pour les utilisateurs privilégiés.
• Utilisez des mots de passe forts et uniques et changez les identifiants en cas de soupçon.
• Désactivez l'édition de fichiers dans l'administration WP :

  define('DISALLOW_FILE_EDIT', true);

• Scannez régulièrement à la recherche de logiciels malveillants et effectuez des vérifications d'intégrité des fichiers.
• Renforcez PHP : désactivez les fonctions dangereuses (exec, shell_exec, system) si elles ne sont pas nécessaires.
• Désactivez l'indexation des répertoires dans la configuration du serveur web.
• Utilisez des protections côté serveur telles que mod_security ou des ensembles de règles équivalents et un WAF correctement configuré.
• Maintenez des sauvegardes testées et des plans de restauration.
• Limitez l'accès SSH/FTP aux IP connues et utilisez SSH basé sur des clés.

Manuel de réponse aux incidents (flux de travail détaillé)

1. Triage (premières 24 heures)
   • Confirmez si le site exécute le plugin/version affecté.
   • Créez des instantanés judiciaires du serveur et de la base de données.
   • Limitez l'accès en changeant les mots de passe administratifs et en plaçant le site en mode maintenance.
2. Contenir (24–72 heures)
   • Appliquez des règles de pare-feu/WAF pour bloquer immédiatement les modèles d'exploitation.
   • Désactivez ou désinstallez le plugin s'il n'existe pas de correctif de confiance.
   • Préservez et supprimez les fichiers suspects après avoir pris des copies judiciaires.
   • Faites tourner les identifiants administratifs et système.
3. Éradiquer & Récupérer (72 heures – semaines)
   • Nettoyez ou restaurez les fichiers compromis ; si incertain, restaurez à partir d'une sauvegarde propre.
   • Corrigez et mettez à jour tous les composants logiciels.
   • Reconstruisez les systèmes si nécessaire et réémettez les clés et secrets API.
4. Post-incident
   • Effectuez une analyse des causes profondes pour comprendre comment les identifiants administratifs ont été exposés.
   • Améliorez la journalisation, la surveillance et la formation des administrateurs.
   • Envisagez des évaluations de sécurité régulières et des tests de pénétration.

Indicateurs de compromission (IoCs) — liste de contrôle rapide

• Nouveaux fichiers avec des noms suspects dans les répertoires de téléchargements ou de plugins
• Signatures de webshell : base64_decode, eval(base64_decode(…)), preg_replace avec /e, system/exec/passthru
• Journaux HTTP montrant l'accès à des fichiers suspects ou des POST vers des points de terminaison de plugins
• Connexions sortantes inattendues des processus PHP
• Utilisateurs admin non reconnus ou changements de rôle

Exemples de snippets de durcissement (à utiliser avec précaution)

Désactivez XML-RPC si ce n'est pas nécessaire :

add_filter('xmlrpc_enabled', '__return_false');

Désactivez l'édition des fichiers de plugin/thème dans wp-config.php :

define('DISALLOW_FILE_EDIT', true);

Si vous ne pouvez pas appliquer de correctif immédiatement — options défensives temporaires

• Désinstallez et supprimez complètement le plugin s'il n'est pas essentiel.
• Supprimez les fichiers du plugin après désactivation pour éviter le code résiduel.
• Bloquez les points de terminaison admin du plugin au niveau du serveur web ou du WAF.
• Restreignez wp-admin aux IP connues ou placez une authentification HTTP Basic devant wp-admin.
• Surveillez en continu les indicateurs d'exploitation.

Conseils de clôture d'un expert en sécurité de Hong Kong

Les chemins de code qui acceptent des fichiers et écrivent sous le répertoire web doivent être traités avec la plus grande prudence. Les vulnérabilités de niveau admin mènent souvent rapidement à un compromis complet car elles permettent aux attaquants de placer du code exécutable persistant. Si vous exécutez le plugin affecté et ne pouvez pas mettre à jour immédiatement, prenez des mesures conservatrices : désactivez ou supprimez le plugin, appliquez des restrictions au niveau du serveur, imposez l'authentification à deux facteurs et d'autres durcissements admin, et supposez un compromis jusqu'à preuve du contraire.

En cas de doute, impliquez votre fournisseur d'hébergement ou une équipe de réponse aux incidents de confiance pour garantir un nettoyage approfondi et professionnel.

Liste de contrôle finale — actions rapides à effectuer maintenant

1. Vérifiez la version du plugin : si <= 1.5.10, agissez immédiatement.
2. Si une version corrigée est disponible, mettez à jour sans délai.
3. S'il n'existe pas de correctif, désinstallez et supprimez les fichiers du plugin.
4. Imposer l'authentification à deux facteurs et des mots de passe forts pour tous les comptes admin.
5. Désactivez l'exécution PHP dans les téléchargements et bloquez les points de terminaison de téléchargement de plugins au niveau du serveur/WAF.
6. Scannez à la recherche de fichiers suspects et préservez les preuves pour l'analyse judiciaire.
7. Faites tourner toutes les identifiants et clés API après le nettoyage.
8. Activer la surveillance : intégrité des fichiers, trafic sortant et journaux d'accès.

Références et lectures complémentaires

• CVE-2025-6085 (avis public)
• Directives de renforcement de la sécurité de WordPress (documentation officielle)
• Meilleures pratiques de renforcement de PHP et du serveur web