CVE-2023-3460 - Accès administrateur non autorisé pour le plugin Ultimate Member POC

Score CVSS : 9.1

Date : 07/04/2023

Qu'est-ce que le plugin Ultimate Member ?

Le plugin Ultimate Member est un plugin d'adhésion populaire pour enregistrer des utilisateurs, le plugin a plus de 200 000 installations actives.

Vérification rapide

Une vulnérabilité critique a été découverte dans le plugin Ultimate Member le 7 juillet, l'attaquant pouvait créer un compte administrateur en utilisant une technique d'escalade de privilèges qui peut mener à la prise de contrôle du site WordPress.

Alors comment fonctionne l'exploit ?

Eh bien, si nous examinons les rôles et capacités de WordPress, il y a plusieurs rôles qu'un utilisateur peut avoir : Super Admin, Administrator, Editor, Author, Contributor, Contributor. Alors comment pouvons-nous obtenir le privilège admin ? D'abord, voyons comment fonctionne le plugin Ultimate Member. D'abord, vous devez configurer le plugin pour qu'il fonctionne correctement, donc nous devons créer quelques pages dans la section Pages puis lier ces pages à Ultimate Member > réglages, après cela nous pouvons créer de nouveaux rôles ou simplement utiliser les rôles par défaut qu'Ultimate Member offre.

À présent, nous devrions avoir un plugin fonctionnel. Maintenant, passons aux choses sérieuses et voyons comment cela fonctionne en backend. J'ai enregistré un utilisateur normal avec le rôle Subscriber et si nous regardons la table wp_usermeta dans MySQL, nous pouvons voir que la valeur wp_capabilities est définie comme un tableau sérialisé et à partir de là, elle définit notre rôle qui dans ce cas est Subscriber.

Alors comment pouvons-nous changer la valeur de wp_capabilities ? Eh bien, nous pouvons passer wp_capabilities comme paramètre dans la requête POST lors de l'enregistrement, comme ceci :

Mais cela ne s'arrête pas là, vous voyez qu'il y a une fonction nommée is_metakey_banned et cette fonction fonctionne en vérifiant quelques valeurs comme "cap_key", "wp_capabilities", "wp_user_level", "user_activation_key" etc... Ce qui nous intéresse est wp_capabilities mais si nous l'avons dans notre corps de requête, cela atteindra le break là pour nous empêcher de changer notre rôle.

À partir de là, nous pouvons essayer d'utiliser quelques types de décodage différents mais cela ne fonctionnera pas. Après un certain temps de recherche et un peu d'aide de l'IA, j'ai découvert que WordPress accepte les caractères accentués par défaut, des caractères comme à, è, ì, ò, ù, À, È, Ì, Ò, Ù. Alors maintenant, si nous utilisons ces caractères dans notre corps de requête, quelque chose comme wp_càpabilities=administrator, que va-t-il se passer ? Eh bien, cela n'atteint pas le point d'arrêt à la ligne 182 dans class-user.php et nous pouvons contourner la fonction is_metakey_banned.

En vérifiant MySQL, nous pouvons voir que nous avons changé la valeur.

Mais nous ne sommes pas admin, en fait nous n'avons aucun rôle du tout.

Nous avons fait quelque chose d'évident, mais pour devenir admin, nous devons avoir exactement la même valeur que l'admin qui ressemble à ceci a:1:{s:13:"administrator";b:1;}. Ok maintenant essayons et passons cela directement à notre paramètre.

En vérifiant à nouveau MySQL, nous avons bien défini la valeur de wp_capabilities mais ce n'est pas ce à quoi nous nous attendions.

Notre valeur a été prise et transformée en une chaîne sérialisée, mais en regardant le wp_capabilities de l'admin, nous voyons qu'il s'agit d'un tableau sérialisé, c'est ce que nous voulons. Donc WordPress a sa propre sérialisation, nous pouvons donc l'utiliser pour passer notre valeur sous forme de tableau, puis WordPress fait le reste pour nous. Voici à quoi ressemble notre payload : wp_càpabilities[administrator]=1.

À la fin, nous pouvons voir que la valeur de wp_capabilities a été changée en a:1:{s:13:"administrator";s:1:"1";} ce qui permet maintenant de se connecter en tant qu'admin.

Et maintenant nous pouvons nous connecter en tant qu'admin.