Breaking News

WordPress-backdoor for all, exploit for many

We all know and should NEVER forget that WP is PHP/MySQL web application. Now, when we repeated this fact it is time to face its consequences caused mostly by “polite” people placed at the top of WordPress “community”.
I had already wrote that WP had tried to fix its protected meta and failed graceful, but secretive (few years in the row). The same issue there is applicable around complete WordPress code base. Reminder:
select ' _je_thank_you_matik' = '_je_thank_you_matik'

WordPress — reset password

WordPress allows registered users to reset their password. They can use their user_login or user_email in order to perform that task. What is wrong there? Let we see:
Two users, Administrator and Subscriber
This situation is presented this way in database:
See the two users, have empty user_activation_key
In case we want to place a backdoor or we exploit (yes we can, see at the bottom of this article) then we need only one operation e.g. to change Subscriberuser_login into something similar like Admin one.
UPDATE `wp_users` SET `user_login` = '   root   ' WHERE `wp_users`.`ID` = 3;
This is just a sample and Unicode character list gives us huge specter for “applicable” characters. Investigate ;-) At this moment on WP admin side we got:
We still have one Administrator and one Subscriber.
Log out from admin and go to reset your Subscriber password, use its email (my case subscriber@subscriber.scotch).
Now hit “Get New Password” and we are ready to see the magic! Log into your database management application and check the wp_users table. See the user_activation_key ?! They are the same for Administrator and Subscriber users, but we only requested for Subscriber. Real magic :-)
user_activation_key isn’t universal or is it?!

What happened?!

Grabbing the user data based on email, we will get the Subscriber 3 data
Later in the code
Preparing data for reset via get_password_reset_key function
But in the get_password_reset_key function we have the following:
See the update statement with user_login in WHERE clause?!
And this code means WHERE user_login = root => all of the rows that satisfy the condition will be updated, but not all of them will receive email for the update!!! This is very very important, because only attacker (our case Subscriber) will receive reset email.

What with reset email

Based on the WP code here attacker will need to hit wp-login.php with user_login (root in our case) and key he receives on his email as GET parameters and to change the Administrator password, email, to install plugins, ... :)

Is this super backdoor or exploitation is in game too

This way we show how on compromised WP instances attackers could plant a backdoor in a form of any valid Subscriber user_login . With the possibility to use user_email and all of those nice names etc etc, attacker could remain unnoticed for a long time, until decide to activate the attack — even then can go unnoticed.
Regarding exploitation aspect of this technique ofc. there is room for that and it is called: “WordPress sites that allow non ASCII only usernames”. Here we have all of the international WP setups, SSO based ones, but also some another setups are in game. What about sanitize_user function usage or filter hooking? :)
Cosmetic patch — WordPress style
$key_saved = $wpdb->update( $wpdb->users, array( 'user_activation_key' => $hashed ), array( 'ID' => $user->ID ) );
That is it :)

Promo

If you are wp developer or wp host provider or wp security product provider with valuable list of clients, we offer subscription list and we are exceptional (B2B only).

No comments

Please do not enter any spam link in comment box.