soltanali0/cve-2024-12877-exploitDémonstration éducative de l'exploitation de CVE-2024-12877 pour l'injection d'objets PHP dans le plugin GiveWP de WordPress. Inclut l'analyse des causes racines, des techniques de contournement des regex et des pratiques d'exploitation sûres.
Semaine 66 | Auteur : Ali Soltani (soltanali0)
Bienvenue dans la semaine 66 de la série GO-TO CVE, où nous disséquons les vulnérabilités, analysons les causes profondes et démontrons des techniques d'exploitation pratiques dans un contexte pédagogique et sécurisé.
CVE-2024-12877 est une vulnérabilité d'injection d'objets PHP dans GiveWP, l'un des plugins de dons WordPress les plus utilisés. L'utilisation non sécurisée de unserialize() sur des entrées contrôlées par l'utilisateur permet aux attaquants de déclencher des méthodes magiques PHP (comme __wakeup()), pouvant potentiellement conduire à :
CVSS : 9.8 Critique | Vecteur : CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
GiveWP alimente des milliers de sites caritatifs, d'ONG et de plateformes de collecte de fonds. Comme il traite des données financières et de donateurs sensibles, une vulnérabilité ici a un impact considérable. Un attaquant exploitant une injection d'objets peut passer d'un simple plugin à la compromission de l'ensemble de l'installation WordPress et du serveur sous-jacent.
Cause racine : unserialize() sur des entrées non fiables.
Méthodes magiques PHP : PHP les invoque automatiquement pendant le cycle de vie des objets :
La vulnérabilité découle de l'utilisation non sécurisée de la fonction PHP unserialize() sur des entrées contrôlées par l'utilisateur. Bien que unserialize() soit conçue pour reconstruire les structures de données PHP, elle comporte un effet secondaire dangereux : lorsque des objets sont reconstruits, PHP invoque automatiquement les méthodes magiques.
__wakeup() – déclenchée lorsqu'un objet est désérialisé
__destruct(), __toString(), __get/__set(), __call/__callStatic() – peuvent être exploitées pour une exécution malveillante
Validation par regex : GiveWP a implémenté des contrôles par regex pour détecter les entrées sérialisées. Bien que la nouvelle regex détecte davantage de types de données, la regex ne peut pas empêcher de manière fiable l'injection d'objets.
Avec un objet sérialisé malveillant, l'attaquant définit les propriétés de l'objet, et PHP lui-même exécute la logique de l'attaquant en invoquant les méthodes magiques
GiveWP a implémenté une validation basée sur des regex pour vérifier si l'entrée était sérialisée. Ancienne regex (incomplète)
• Ne reconnaissait que les tableaux et les objets.
• Les autres types sérialisés (string, int, bool, float, null) contournaient la détection.
• Reconnaît tous les types sérialisés PHP.
• Bloque certains payloads triviaux.
• Mais le problème fondamental demeure : si unserialize() est utilisée sur des entrées utilisateur, la regex ne peut pas vous sauver.
Cet extrait a été écrit pour comparer deux implémentations différentes de regex :
• is_serialized_old() → l'ancienne version, qui ne détecte que les tableaux et les objets.
• is_serialized_new() → la version améliorée, qui reconnaît tous les types de données sérialisés PHP (arrays, objects, strings, integers, booleans, floats, and null). Nous créons un ensemble de valeurs de test (array, object, string, integer, boolean, float, null), les sérialisons, puis vérifions chacune d'elles avec les deux fonctions regex. En termes simples :
Et après avoir exécuté ce code sur votre docker, vous verrez ce résultat dans le navigateur
Étape 1
Étape 2 : Créer une classe vulnérable
Cette classe possède une méthode __wakeup() qui s'exécutera automatiquement lorsqu'elle sera désérialisée.
Étape 3 : Fabriquer le payload
Étape 4 : Sortie Après avoir enregistré le fichier, vous pouvez voir cet exploit dans ce fichier
Exploit :
• Ancienne regex : FALSE → n'a pas détecté le payload.
• Nouvelle regex : TRUE → l'a détecté comme entrée sérialisée.
• Exécution : Hello RCE! → Le payload a été désérialisé et la méthode magique __wakeup() a exécuté le code contrôlé par l'attaquant.
Prévention • N'utilisez pas unserialize() sur des entrées non fiables. Remplacez-la par json_decode() ou d'autres alternatives plus sûres.
• Maintenez GiveWP et tous les plugins WordPress à jour.
• Déployez un pare-feu applicatif (WAF) pour bloquer les payloads sérialisés malveillants.
• Suivez le principe du moindre privilège : exécutez PHP et les comptes de base de données avec les autorisations minimales requises.
Résultats :
Point clé : Ne vous fiez jamais à une regex pour sécuriser unserialize(). L'approche la plus sûre est d'éviter complètement de désérialiser des entrées non fiables.
unserialize() sur des entrées non fiables ; préférez json_decode() ou d'autres alternatives sûres.Je gère deux chaînes Telegram dédiées à la recherche et à l'exploitation de vulnérabilités :
GO-TO CVE – Épisodes hebdomadaires : Chaque semaine, nous approfondissons une nouvelle CVE et partageons des analyses détaillées, des démos et des informations. 🔗 Rejoignez-nous ici
CVEdb – Archive d'exploits : Cette chaîne archive les exploits 1-day et les PoC personnalisés pour les CVE. Une excellente ressource pour les chercheurs qui souhaitent voir les techniques d'exploitation actives. 🔗 Rejoignez CVEdb
Suivez les chaînes pour rester à jour sur les dernières CVE, les techniques d'exploitation et les informations issues de la recherche en sécurité.
Ce dépôt est strictement destiné à des fins éducatives et de recherche. Exploiter des vulnérabilités sans autorisation est illégal et contraire à l'éthique. L'auteur n'est pas responsable d'une mauvaise utilisation.