CVE-2023-3460 - Nicht autorisierter Admin-Zugriff für Ultimate Member Plugin POC

CVSS-Score: 9.1

Datum: 07.04.2023

Was ist das Ultimate Member Plugin?

Das Ultimate Member Plugin ist ein beliebtes Mitgliedschafts-Plugin zur Registrierung von Benutzern. Das Plugin hat über 200.000 aktive Installationen.

Schnellprüfung

Am 7. Juli wurde eine kritische Schwachstelle im Ultimate Member Plugin entdeckt. Der Angreifer konnte durch eine Technik zur Rechteausweitung ein Administratorkonto erstellen, was zur Übernahme der WordPress-Website führen konnte.

Wie funktioniert der Exploit?

Wenn wir uns die Rollen und Fähigkeiten von WordPress ansehen, gibt es eine Reihe von Rollen, die ein Benutzer haben kann: , , , , , . Wie können wir also Administratorrechte erlangen? Zuerst sehen wir uns an, wie das Ultimate Member Plugin funktioniert. Zuerst müssen Sie das Plugin konfigurieren, damit es ordnungsgemäß funktioniert. Dazu müssen wir im Bereich einige Seiten erstellen und diese dann mit Ultimate Member > Einstellungen verknüpfen. Danach können wir neue Rollen erstellen oder die Standardrollen des Ultimate Member Plugins verwenden.

Inzwischen sollte das Plugin funktionieren. Nun wollen wir uns die Hände schmutzig machen und sehen, wie das im Backend funktioniert. Ich habe einen normalen Benutzer mit der Rolle Abonnent registriert. Wenn wir uns die Tabelle wp_usermeta in MySQL ansehen, sehen wir, dass der Wert von wp_capabilities auf ein serialisiertes Array gesetzt ist, und daraus wird unsere Rolle definiert, in diesem Fall Abonnent.

Wie können wir also den Wert von wp_capabilities ändern? Wir können wp_capabilities als Parameter in der POST-Anfrage während der Registrierung übergeben, etwa so:

Aber damit ist es noch nicht getan. Es gibt eine Funktion namens is_metakey_banned, die einige Werte wie "cap_key", "wp_capabilities", "wp_user_level", "user_activation_key" usw. überprüft. Uns interessiert wp_capabilities, aber wenn es in unserem Anforderungstext enthalten ist, wird dort ausgelöst, um uns daran zu hindern, unsere Rolle zu ändern.

Von hier aus können wir versuchen, einige verschiedene Kodierungsarten zu verwenden, aber es wird nicht funktionieren. Nach einiger Recherche und mit etwas Hilfe von KI habe ich herausgefunden, dass WordPress standardmäßig Akzentzeichen akzeptiert, Zeichen wie à, è, ì, ò, ù, À, È, Ì, Ò, Ù. Wenn wir also diese Zeichen in unserem Anforderungstext verwenden, etwa wp_càpabilities=administrator, was passiert dann? Nun, es erreicht den Haltepunkt in Zeile 182 in class-user.php nicht, und wir können die Funktion is_metakey_banned umgehen.

Wenn wir MySQL überprüfen, sehen wir, dass wir den Wert geändert haben.

Aber wir sind kein Administrator – tatsächlich haben wir überhaupt keine Rolle.

Wir haben etwas getan, aber um Administrator zu werden, müssen wir genau denselben Wert wie der Administrator haben, der so aussieht: a:1:{s:13:"administrator";b:1;}. Versuchen wir es und übergeben diesen direkt an unseren Parameter.

Wenn wir erneut MySQL überprüfen, haben wir den Wert von wp_capabilities gesetzt, aber das ist nicht das, was wir erwartet haben.

Es hat unseren Wert genommen und in einen serialisierten String umgewandelt. Wenn wir uns jedoch den wp_capabilities-Wert des Administrators ansehen, sehen wir, dass es sich um ein serialisiertes Array handelt – das wollen wir. WordPress hat seine eigene Serialisierung, also können wir diese nutzen, um unseren Wert als Array zu übergeben, und WordPress erledigt den Rest für uns. So sieht unser Payload aus: wp_càpabilities[administrator]=1.

Am Ende sehen wir, dass der Wert von wp_capabilities zu a:1:{s:13:"administrator";s:1:"1";} geändert wurde, sodass wir uns jetzt als Administrator anmelden können.

Und jetzt können wir uns als Administrator anmelden.