Résumé

Une vulnérabilité critique d'Inclusion de Fichiers Locaux (LFI) a été divulguée dans le thème WordPress Learnify affectant les versions ≤ 1.15.0 (CVE-2025-60085). Le défaut permet aux attaquants non authentifiés d'inclure et d'afficher des fichiers locaux depuis le serveur web. Cette vulnérabilité présente une gravité élevée (CVSS 8.1) et peut être exploitée largement — exposant des fichiers tels que wp-config.php, fichiers d'environnement, et d'autres fichiers lisibles côté serveur. Les conséquences peuvent inclure la divulgation de données d'identification, la compromission de la base de données, et potentiellement la prise de contrôle complète du site selon l'environnement.

Si votre site utilise Learnify, considérez cela comme urgent. Les conseils ci-dessous expliquent la vulnérabilité, les techniques d'exploitation, les indicateurs de détection, les atténuations immédiates, et les étapes de réponse aux incidents adaptées pour les propriétaires et administrateurs de sites.

Qu'est-ce que l'inclusion de fichiers locaux (LFI) ?

L'Inclusion de Fichiers Locaux se produit lorsque l'entrée contrôlée par l'utilisateur détermine quel fichier côté serveur une application inclut ou lit, sans validation adéquate. Dans les applications basées sur PHP, cela peut ressembler à :

• include($_GET['template']);
• require_once($_REQUEST['page']);

Si un attaquant contrôle cette entrée, il peut forcer l'application à lire des fichiers locaux arbitraires. Impacts courants :

• Divulgation de secrets (identifiants de base de données, clés API).
• Collecte d'informations pour des attaques ultérieures.
• Exécution de Code à Distance (RCE) potentielle lorsqu'elle est enchaînée avec d'autres erreurs de configuration ou wrappers vulnérables (par exemple, php:// wrappers).

Pourquoi cette LFI Learnify est dangereuse

Faits clés :

• Impact : Thèmes Learnify ≤ 1.15.0.
• CVE : CVE-2025-60085.
• Privilège requis : aucun (non authentifié).
• CVSS : 8.1 (Élevé).
• À la divulgation : aucun correctif garanti du fournisseur disponible — les propriétaires de sites doivent appliquer les atténuations rapidement.

Cette LFI est une priorité élevée car elle est non authentifiée, facilement scannée à grande échelle, cible des fichiers qui contiennent souvent des identifiants (comme wp-config.php), et peuvent être enchaînés pour s'intensifier en compromis plus graves.

Détails techniques (comment les attaquants exploitent généralement LFI)

Les attaquants suivent des étapes communes lors de l'exploitation de LFI. Comprendre le schéma aide à la détection et à l'atténuation.

1. Trouver le point d'entrée
   Recherchez le code du thème qui inclut des fichiers utilisant des variables influencées par les paramètres de la requête, par exemple :
   include( $theme_dir . '/' . $_GET['tpl'] );
2. Traversée de chemin
   Les charges utiles incluent des séquences de traversée pour atteindre des fichiers sensibles :
   ../../../../etc/passwd ou ../../../../wp-config.php.
3. Utilisation de wrappers pour lire des fichiers
   Les wrappers comme php://filter peuvent forcer une sortie imprimable :
   ?tpl=php://filter/convert.base64-encode/resource=../../../../wp-config.php.
4. Octet nul et astuces d'encodage
   Older servers might be targeted with null byte (%00) truncation or encoded payloads:
   ?tpl=../../../../wp-config.php%00.
5. Post-exploitation
   Les identifiants extraits peuvent être utilisés pour accéder à la base de données, créer des utilisateurs administrateurs, installer des portes dérobées ou télécharger des shells PHP si des zones écrites existent.

La divulgation indique que la logique d'inclusion de Learnify ne validait pas suffisamment les chemins fournis par l'utilisateur, permettant les méthodes ci-dessus.

Indicateurs et modèles de requêtes malveillantes à rechercher

Recherchez ces modèles dans les journaux :

• php://filter/convert.base64-encode/resource=
• Appels répétés ../ ou des variantes encodées comme ..%2F..%2F
• Tentatives de byte nul : %00
• Requêtes aux fichiers PHP de thème avec des paramètres de requête comme ?tpl= ou ?page=
• Longues chaînes base64 dans les réponses HTML normales (contenu des fichiers encodé)

Exemple de requête suspecte:

GET /wp-content/themes/learnify/somefile.php?template=php://filter/convert.base64-encode/resource=../../../../wp-config.php HTTP/1.1

Si vous voyez ce modèle, traitez-le comme une priorité élevée et enquêtez immédiatement.

Liste de contrôle des actions immédiates (premières heures)

Si votre site utilise Learnify ≤ 1.15.0, effectuez ces étapes maintenant :

1. Mettez le site en mode maintenance ou appliquez des contrôles d'accès temporaires (liste blanche IP) pour réduire l'exposition.
2. Passez à un thème propre (par défaut de WordPress) ou retirez le thème vulnérable des répertoires accessibles au public. Ne laissez pas le thème vulnérable actif.
3. Si un correctif officiel est publié, appliquez-le immédiatement. Sinon, utilisez les atténuations ci-dessous.
4. Appliquez des règles au niveau du serveur pour bloquer les séquences de traversée et php:// les tentatives de wrapper (patching virtuel au niveau du serveur web).
5. Ne changez pas les identifiants de la base de données tant que vous n'avez pas de sauvegardes fiables et que vous n'avez pas vérifié les signes de compromission ; lorsque c'est sûr, faites tourner les mots de passe et secrets de la base de données.
6. Faites tourner les clés secrètes et les sels dans wp-config.php après avoir remédié et vérifié l'intégrité.
7. Scannez à la recherche de webshells, de fichiers suspects et de timestamps modifiés.
8. Restaurez à partir d'une sauvegarde propre vérifiée si vous détectez une compromission.
9. Augmentez la surveillance : activez les vérifications d'intégrité des fichiers, les journaux d'audit et les alertes.

Si vous manquez de capacités internes, contactez votre fournisseur d'hébergement ou un consultant en sécurité de confiance et partagez les indicateurs ci-dessus.

Comment détecter si votre site a été exploité

Même après avoir supprimé le thème vulnérable ou appliqué des correctifs, vérifiez les traces de compromission :

• Fichiers nouveaux ou modifiés sous wp-content/uploads, wp-content/themes, wp-content/plugins, ou des emplacements inattendus.
• Nouveaux utilisateurs administrateurs dans WordPress (inspectez le wp_users le tableau).
• Tâches programmées suspectes ou entrées cron stockées dans la base de données.
• Connexions sortantes vers des IP inconnues depuis le serveur (vérifiez les journaux du pare-feu/hôte).
• Utilisation inhabituelle du CPU/IO ou pics de trafic.
• Requêtes de base de données provenant de comptes inconnus ou requêtes inattendues dans les journaux lents.
• Fichiers PHP inconnus ou scripts encodés utilisant eval, base64_decode, ou gzinflate.

Actions recommandées : outils d'intégrité des fichiers, analyses de logiciels malveillants et inspection manuelle des fichiers critiques (wp-config.php, .htaccess, points d'entrée des thèmes et des plugins).

Réponse aux incidents : manuel étape par étape

1. Contenir
   • Mettez le site hors ligne ou bloquez le trafic pour éviter d'autres dommages.
   • Révoquez les identifiants compromis et les clés API.
   • Isolez le serveur du réseau si possible.
2. Mettez le site hors ligne (mode maintenance) si possible.
   • Sauvegardez les journaux (serveur web, base de données, application) et, si nécessaire, les images disque.
   • Conservez les horodatages pour l'analyse judiciaire ; ne pas écraser les journaux.
3. Éradiquer
   • Supprimez les portes dérobées, les shells et les scripts malveillants.
   • Réinstallez le cœur de WordPress, les plugins et les thèmes à partir de sources vérifiées et propres.
   • Reconstruisez les serveurs à partir d'images propres si une persistance au niveau du serveur est suspectée.
4. Récupérer
   • Restaurez à partir d'une sauvegarde propre (d'avant la compromission).
   • Appliquez des correctifs de sécurité et des mesures de durcissement.
   • Changez tous les mots de passe et faites tourner les clés et les sels.
5. Post-récupération
   • Renforcez la surveillance et la journalisation.
   • Réalisez un post-mortem pour identifier les contrôles échoués et combler les lacunes.
   • Mettez à jour les plans de réponse aux incidents et formez l'équipe.
6. Notifiez
   • Informez les parties prenantes et votre fournisseur d'hébergement. Suivez les exigences de notification réglementaires ou contractuelles locales le cas échéant.

Recommandations de durcissement pour réduire le risque LFI

1. Principe du moindre privilège
   Assurez-vous que les permissions de fichiers et de répertoires sont minimales. La plupart des fichiers WordPress doivent être lisibles par le serveur web mais pas modifiables. Seulement wp-content/uploads doit être modifiable pour les téléchargements.
2. Configuration PHP
   Désactiver autoriser_inclusion_url, restreindre via open_basedir, et désactiver les fonctions inutiles comme exec, shell_exec, si elles ne sont pas requises par votre environnement.
3. Désactivez l'éditeur intégré
   Ajouter à wp-config.php:

   define('DISALLOW_FILE_EDIT', true);

4. Sécurisez les téléchargements
   Empêchez l'exécution de fichiers PHP dans wp-content/uploads avec des règles serveur (exemples ci-dessous).
5. Faire tourner les sels et les clés
   Utilisez des sels forts et uniques et faites-les tourner après remédiation pour invalider les sessions existantes.
6. Sauvegardes et tests
   Maintenez des sauvegardes régulières hors site et testez les restaurations périodiquement.
7. Revue de code et mises à niveau par étapes
   Examinez les thèmes/plugins tiers avant le déploiement ou limitez leur utilisation jusqu'à vérification.

Règles WAF pratiques et atténuations au niveau du serveur

Les blocs au niveau du serveur web (patching virtuel) peuvent gagner du temps lorsqu'un patch officiel n'est pas disponible. Testez les règles sur un système de staging avant de les appliquer en production.

Modèles importants à détecter et à bloquer :

• Toute valeur de paramètre contenant php://filter
• Paramètres avec plusieurs ../ séquences
• Tentatives de byte nul (%00)
• Requêtes tentant d'inclure wp-config.php, .env, /etc/passwd

Exemple de règle de style ModSecurity/CRS :

# Block common LFI attack signatures
SecRule REQUEST_URI|ARGS|ARGS_NAMES|REQUEST_HEADERS "@rx (?i)((\.\./)|(\.\.\\)|php://filter|php%3A%2F%2Ffilter|%00|/etc/passwd|wp-config.php)" \
    "id:1009001,phase:1,deny,status:403,log,msg:'Potential LFI attempt blocked',severity:2,tag:'LFI',tag:'OWASP_TOP_10_A03'"

Exemple de règle Nginx :

if ($request_uri ~* "(php://filter|%00|\.\./){1,}") {
    return 403;
}

Apache .htaccess extrait pour bloquer l'exécution de PHP dans les uploads :

# Protéger les uploads - empêcher l'exécution de PHP

Appliquez ces règles avec précaution — des règles trop larges peuvent casser des fonctionnalités légitimes. Priorisez le staging/testing et le déploiement progressif.

Exemples de regex de détection et conseils d'analyse des logs

Utilisez ces modèles pour le scan automatisé des logs (insensible à la casse) :

(?i)(php%3A%2F%2Ffilter|php://filter|(\.\./){2,}|(\.\.\\){2,}|%00|wp-config\.php|/etc/passwd)

Alertez sur les entrées de log telles que :

• GET /wp-content/themes/learnify/… ?…=php://filter/convert.base64-encode/resource=../../../../wp-config.php
• Toute demande utilisant php:// des wrappers
• Les réponses retournant du contenu encodé en base64 dans des pages HTML normales

Exécutez des analyses quotidiennes des journaux pour ces signatures et informez les administrateurs lorsque des correspondances se produisent.

Test sûr pour vérifier la vulnérabilité (propriétaires de sites uniquement)

N'effectuez ces vérifications que sur des sites que vous possédez ou gérez. Ne testez pas des sites tiers.

1. Utilisez une demande non destructive php://filter ciblant un fichier connu et inoffensif (par exemple un thème readme).
2. Exemple de demande :

GET /wp-content/themes/learnify/index.php?tpl=php://filter/convert.base64-encode/resource=inc/readme.html

Si la réponse inclut une chaîne base64 qui se décode en contenu de fichier, la fonction d'inclusion est vulnérable. Arrêtez les tests et procédez immédiatement à l'atténuation.

Arbre de décision pour la remédiation

Choisissez le chemin approprié en fonction de la disponibilité d'un correctif officiel :

• S'il existe une version corrigée : mettez à jour immédiatement, puis vérifiez l'intégrité (analyses de fichiers, rotations de mots de passe).
• S'il n'existe pas de correctif : retirez le thème de l'utilisation active, appliquez des règles au niveau du serveur pour bloquer l'exploitation, et envisagez de remplacer le thème par une alternative maintenue.
• Si le thème ne peut pas être retiré : appliquez des contrôles d'accès stricts (liste blanche d'IP), appliquez des règles serveur strictes, et augmentez la surveillance et les vérifications fréquentes de l'intégrité.

Après remédiation : valider et surveiller

Après avoir appliqué les correctifs :

1. Relancer les scanners automatisés de vulnérabilités et de logiciels malveillants.
2. Vérifier qu'aucun compte administrateur inattendu ou tâche planifiée n'existe.
3. Vérifier l'activité réseau sortante inattendue.
4. S'assurer que les sauvegardes sont propres et récentes.
5. Maintenir une surveillance accrue pendant au moins 30 jours après la remédiation.

Questions fréquemment posées (FAQ)

Q : LFI peut-il conduire à une exécution de code à distance ?

R : LFI est principalement une vulnérabilité de lecture/inclusion de fichiers. L'exécution de code à distance est possible si un attaquant peut inclure un fichier qu'il contrôle (par exemple, un fichier PHP téléchargé) ou enchaîner le LFI avec d'autres configurations non sécurisées (répertoires écrits, wrappers dangereux).

Q : J'utilise un thème enfant de Learnify — suis-je affecté ?

R : Possiblement. Les thèmes enfants héritent du code parent. Si la logique vulnérable existe dans le thème parent Learnify et que ce parent est ≤ 1.15.0, vous êtes probablement impacté. Vérifiez la version du thème parent et agissez en conséquence.

Q : J'ai corrigé le thème — dois-je toujours faire tourner les identifiants ?

R : Oui. Le patchage empêche de nouvelles exploitations mais ne supprime aucune compromission précédente. Faites tourner les mots de passe de la base de données, les clés API et les sels s'il y a eu une exposition.

Q : Comment puis-je être informé de vulnérabilités similaires ?

R : Abonnez-vous à des avis de sécurité réputés et à des listes de diffusion, activez les alertes automatisées de vulnérabilités pour les thèmes/plugins installés, et maintenez l'enregistrement et la surveillance actifs.

Dernières réflexions d'un point de vue de sécurité à Hong Kong

Cette divulgation LFI de Learnify met en évidence une réalité récurrente : les thèmes et plugins tiers peuvent introduire des faiblesses critiques. Dans l'environnement numérique en évolution rapide de Hong Kong, les priorités sont la rapidité et l'exhaustivité — agir rapidement pour contenir l'exposition et enquêter pleinement pour déterminer si des identifiants ou des systèmes ont été accédés.

Priorités pratiques : retirer ou isoler rapidement les composants vulnérables, appliquer des atténuations au niveau du serveur, vérifier l'intégrité, faire tourner les secrets et maintenir la surveillance. Si vous gérez plusieurs sites, considérez cette divulgation comme une incitation à inventorier les versions de thème et à appliquer un plan de mise à niveau ou de remplacement.

Pour les organisations sans capacité de sécurité interne, engagez un consultant en sécurité qualifié ou votre équipe de support d'hébergement pour aider à la containment, à la criminalistique et à la remédiation.

Annexe A : Liste de contrôle rapide (copier/coller)

• [ ] Identifier si Learnify ≤ 1.15.0 est installé.
• [ ] Passez à un thème différent ou désactivez Learnify.
• [ ] Appliquez les règles du serveur pour bloquer php://filter et les tentatives de traversée de chemin.
• [ ] Scannez à la recherche de webshells et de modifications de fichiers non autorisées.
• [ ] Faites tourner les identifiants de la base de données et les sels WordPress.
• [ ] Restaurez à partir d'une sauvegarde propre si une compromission est détectée.
• [ ] Mettez en œuvre le renforcement des permissions de fichiers.
• [ ] Activez la surveillance de l'intégrité des fichiers et les alertes.
• [ ] Surveillez les journaux pendant 30 jours après la remédiation.

Annexe B : Ressources et références supplémentaires

• Avis de CVE-2025-60085
• Meilleures pratiques de renforcement PHP (open_basedir, désactiver les fonctions dangereuses)
• Manuel de sécurité WordPress et guides d'administration
• Guides de réglage du WAF et de test des règles (testez sur la mise en scène avant la production)

Important : Les actions ci-dessus sont sensibles sur le plan opérationnel. Si vous soupçonnez une compromission et manquez des compétences pour suivre le plan d'incidents, demandez de l'aide à un répondant en sécurité professionnel de confiance ou à votre fournisseur d'hébergement.