CVE-2025-4396 - Toolkit d'injection SQL aveugle basée sur le temps pour WordPress Relevanssi

Vue d'ensemble

Ce dépôt contient un toolkit pratique de recherche et de validation pour CVE-2025-4396, une injection SQL aveugle basée sur le temps non authentifiée affectant le plugin WordPress Relevanssi via le paramètre cats.

Le projet a été conçu pour des engagements Purple Team autorisés afin de :

• valider l'exploitabilité de manière contrôlée,
• démontrer différents niveaux de techniques d'attaquant,
• mesurer la couverture de détection du SOC,
• extraire un hash de mot de passe WordPress de manière réaliste,
• et automatiser le flux de travail de cassage hors ligne une fois le hash récupéré.

Le dépôt comprend :

• un script d'extraction standard,
• un script d'extraction plus rapide par recherche binaire,
• et un script d'assistance pour préparer et casser le hash WordPress 6.8+ extrait avec Hashcat.

Avertissement
Ce projet est fourni uniquement à des fins éducatives, de validation défensive et de tests de sécurité autorisés.
Ne l'utilisez pas contre des systèmes que vous ne possédez pas ou pour lesquels vous n'avez pas d'autorisation écrite explicite d'évaluation.

Environnement de test

• Serveur : Debian 11
• WordPress 6.9.1,
• Plugin Relevanssi 4.24.4 (téléchargé depuis https://wordpress.org/plugins/relevanssi/advanced/),
• PoC utilisé depuis le système d'exploitation Kali Linux.

---

Description de la CVE

CVE-2025-4396 est une vulnérabilité d'injection SQL affectant la fonctionnalité de recherche Relevanssi dans WordPress.

Dans le scénario testé, le problème est accessible via le flux de recherche et plus précisément via le paramètre cats. Le chemin de code vulnérable permet à une entrée contrôlée par l'attaquant d'influencer la requête SQL générée par le plugin.

Étant donné que le point d'accès vulnérable est accessible sans authentification préalable, la faille peut être exploitée par un attaquant distant pour réaliser une injection SQL non authentifiée.

L'impact pratique comprend :

• la manipulation de requêtes de base de données,
• l'injection SQL aveugle basée sur le temps,
• l'extraction de données sensibles telles que les hashs de mots de passe,
• et, selon l'environnement, une éventuelle élévation de privilèges via la récupération d'identifiants valides.

---

Comment fonctionne la vulnérabilité

Cause racine

La vulnérabilité existe parce que l'entrée contrôlée par l'utilisateur provenant d'un paramètre lié à la recherche n'est pas traitée de manière sécurisée avant d'être incorporée dans une requête SQL.

En pratique, cela signifie qu'un attaquant peut injecter des expressions SQL dans la logique de requête du backend et forcer la base de données à évaluer des conditions supplémentaires.

Pourquoi elle est aveugle

La vulnérabilité est exploitée en mode aveugle, ce qui signifie que l'application n'affiche pas directement les erreurs SQL ni les résultats bruts de la base de données.

Au lieu de lire la sortie de la requête sur la page, l'attaquant pose à la base de données une série de questions vrai/faux et observe un effet secondaire :

• si la condition est vraie, la base de données dort pendant quelques secondes,
• si la condition est fausse, la réponse revient immédiatement.

Pourquoi elle est basée sur le temps

L'exploitation repose sur des fonctions SQL telles que SLEEP() pour créer une différence mesurable dans le temps de réponse du serveur.

Cela permet à un attaquant de déduire des données sans jamais les voir directement.

Par exemple, l'attaquant peut poser des questions telles que :

• « Le premier caractère est-il égal à $ ? »
• « La valeur ASCII du deuxième caractère est-elle supérieure à 77 ? »
• « Les N premiers caractères correspondent-ils à ce motif ? »

En répétant ce processus, l'attaquant peut reconstruire un hash complet caractère par caractère.

---

Comment fonctionne l'exploitation

Logique d'extraction standard

L'approche standard parcourt un jeu de caractères connu et teste chaque candidat un par un.

Pour chaque position dans le hash cible :

1. Construire une condition SQL ciblant un caractère.
2. Déclencher un délai serveur uniquement si la supposition est correcte.
3. Mesurer le temps de réponse.
4. Renvoyer la même requête pour réduire les faux positifs causés par la gigue réseau.
5. Ajouter le caractère confirmé au hash extrait.
6. Passer à la position suivante.

Cette méthode est simple et fiable, mais relativement lente car elle peut nécessiter de nombreuses requêtes par caractère.

Logique d'extraction par recherche binaire

L'approche plus rapide utilise la recherche binaire sur la valeur ASCII de chaque caractère.

Au lieu de demander :

• « Le caractère est-il égal à a ? »
• « Le caractère est-il égal à b ? »
• « Le caractère est-il égal à c ? »

elle demande :

• « La valeur ASCII est-elle supérieure à 79 ? »
• « Est-elle supérieure à 55 ? »
• « Est-elle supérieure à 43 ? »

Cela divise l'espace de recherche par deux à chaque requête et réduit considérablement le nombre de requêtes HTTP.

Résultat pratique

L'attaque permet à l'opérateur d'extraire la valeur user_pass de wp_users, généralement pour un ID utilisateur WordPress choisi tel que :

• 1 pour l'administrateur par défaut,
• ou un autre ID passé en ligne de commande.

Dans les versions récentes de WordPress, cette valeur peut utiliser le nouveau pipeline de mots de passe WordPress 6.8+, qui combine :

• une étape de pré-hachage utilisant HMAC-SHA384,
• l'encodage Base64,
• et un hash bcrypt final.

---

Scripts inclus

1. CVE_2025_4396.py

Il s'agit du script d'extraction standard.

Objectif :

Il effectue une injection SQL aveugle basée sur le temps classique et extrait le hash cible caractère par caractère à l'aide d'une recherche linéaire sur un jeu de caractères fixe.

Caractéristiques clés :

• simple et facile à comprendre,
• fiable dans des environnements stables,
• logique de double vérification pour réduire les faux positifs,
• utile comme référence pour l'ingénierie de détection et les démonstrations de PoC.

Comment ça marche :

Pour chaque position de caractère :

• il parcourt un jeu de caractères prédéfini,
• construit une condition SQL correspondant à un seul caractère,
• attend la réponse du serveur,
• et confirme la correspondance avec une seconde requête.

Prérequis :

• python3
• requests
• urllib3

Installation :

pip3 install requests urllib3

Utilisation :

python3 CVE_2025_4396.py -t "https://target.local/?s=test&cats=" -u 1 -s 3 -v

Arguments :
    -t, --target : vulnerable target URL including the injectable parameter
    -u, --userid : WordPress user ID to target
    -s, --sleep : sleep threshold in seconds
    -v, --verbose : enable debug logging

2. CVE_2025_4396_Stealth.py

Il s'agit de l'édition à recherche binaire.

Objectif :

Il poursuit le même objectif d'extraction que le script standard, mais remplace la recherche linéaire caractère par caractère par une recherche binaire sur les valeurs ASCII.

Caractéristiques clés :

• nettement moins de requêtes HTTP,
• empreinte réseau plus réduite,
• inclut toujours une étape de double vérification pour éviter les faux positifs.

Comment ça marche :

Pour chaque position :

• Définir une plage ASCII imprimable.
• Tester le point médian.
• Demander si le caractère cible est supérieur à ce point médian.
• Réduire la plage en conséquence.
• Continuer jusqu'à ce que le caractère exact soit identifié.

Prérequis :

• python3
• requests
• urllib3

Installation :

pip3 install requests urllib3

Utilisation :

python3 CVE_2025_4396_Stealth.py -t "https://target.local/?s=test&cats=" -u 1 -s 3 -v

Quand l'utiliser :