Privilege Escalation Flaw In WP GDPR Compliance Plugin Exploited In The Wild
After its removal from the WordPress plugin repository yesterday, the popular plugin WP GDPR Compliance released version 1.4.3, an update which patched multiple critical vulnerabilities. At the time of this writing, the plugin has been reinstated in the WordPress repository and has over 100,000 active installs. The reported vulnerabilities allow unauthenticated attackers to achieve privilege escalation, allowing them to further infect vulnerable sites. Any sites making use of this plugin should make it an immediate priority to update to the latest version, or deactivate and remove it if updates are not possible.
In typical use, the plugin handles a few types of actions which can be submitted via WordPress’s
admin-ajax.php functionality. These actions include making the sort of data access requests and deletion requests required by GDPR, but also includes functionality for changing the plugin’s settings from within the WordPress admin dashboard.
However, unpatched versions of WP GDPR Compliance (up to and including version 1.4.2) fail to do capability checks when executing its internal action
save_setting to make such configuration changes. If a malicious user submits arbitrary options and values to this endpoint, the input fields will be stored in the options table of the affected site’s database.
In addition to the storage of arbitrary options values, the plugin performs a
do_action() call using the provided option name and value, which can be used by attackers to trigger arbitrary WordPress actions.
Disclosures of this flaw have been reporting it as two distinct vulnerabilities: first the arbitrary options update and second the arbitrary action calls, but with both potential exploits living in the same block of code and executed with the same payload, we’re treating this as a single privilege escalation vulnerability.
Exploits In The Wild
We’ve already begun seeing cases of live sites infected through this attack vector. In these cases, the ability to update arbitrary options values is being used to install new administrator accounts onto the impacted sites.
By leveraging this flaw to set the
users_can_register option to 1, and changing the
default_role of new users to “administrator”, attackers can simply fill out the form at
/wp-login.php?action=register and immediately access a privileged account. From this point, they can change these options back to normal and install a malicious plugin or theme containing a web shell or other malware to further infect the victim site.
In several of the cases we’ve triaged since the disclosure of this vulnerability, we’ve seen malicious administrator accounts present with the variations of the username t2trollherten. This intrusion vector has also been associated with uploaded webshells named wp-cache.php. While these are common IOCs (Indicators of Compromise), these exploits are of course subject to change as attacks grow in sophistication.
Until the patch was released yesterday, more then a hundred thousand WordPress sites using the WP GDPR Compliance plugin were vulnerable to this type of attack. It is of critical importance that any site using this plugin performs the update as soon as possible.
At this time, the Wordfence Threat Intelligence team has released a new firewall rule preventing exploitation of this flaw for all premium users. Users of the free version of Wordfence will receive the new rule following a thirty-day delay, but as always they can protect themselves by updating their site’s plugins.
If you believe your site has been impacted by this vulnerability, please do not hesitate to reach out to our site cleaning team to begin the remediation process. Also, please consider sharing this post with your peers to improve awareness of this issue.
Many thanks for this alert: I've circulated within my online community.
I'm a victim. I had three sites running the plugin and updated them this morning but it was too late for one of the sites. I already had two new Admin user accounts added with the name t2trollherten and t3trollherten.
I found two new admin accounts with that name on my site this morning. I deleted them and changed all of my passwords. I also updated the plugin for the gdpr cookie consent.
How can I tell if the hacker was able to insert malicious code into my site?
Hi Lisa, the Wordfence scanner detects the malware we're seeing related to this vulnerability. If you haven't run a scan since you deleted the accounts and updated the plugin we recommend you run one now.
Thanks for this. I had a client get hit with it this morning on two sites on different hosts. They used the username t2trollherten on both. We caught it pretty soon, but I thought it was odd that registration had been turned on when I knew it hadn't been before.
I have been hit (I don't have WF premium due to not being a commercial site). It seems wordpress needs a priority flag for updates. Normal or Security Fix.
We could then choose to auto update on Security fixes, and or receive an email with a subject that a security fix is available / been auto installed.
I would prefer my site to be updated for a security issue automatically and risk having the fix break the site rather than a hacker break the site and get info. Not all off us are awake and or available 24/7 so unless there is a mechanism for automatic security updates then there is always a window for hackers.
I note the authors put a message on their forum, but it doesn't seem a robust way to get the message out.
I got a Wordfence info email that the plugin needed updating yesterday but no indication of the severity of this issue. Could wordfence plugin parse the changelog looking for "Security" and modify the email subject as a security fix? This might require wordpress enforcing changelog standards.
I did immediately read the wordfence message publicizing this post, (So that Subject worked) but its now too late for my sites.
Thanks as always for your diligent and quick response to emerging threats. Wordfence saved us in this case by flagging this plugin as having been removed from the WP repository before the author had even started taking action. We promptly removed and replaced the plugin before any exploits hit and managed to avoid the fallout. Win!
Thanks for your report here. Very helpfull. We been hit with three pages. I hope we solved it now with your help.
Will a scan detect the issue if you only have the free version installed?
It might. Only Wordfence Premium is guaranteed to detect the malware that the attackers exploiting the GDPR plugin are depositing on websites.
Thx for keeping us updated so quickly! Just had the first hack with 180 script injections in the files (php & js), a database ijection in all posts and a backdoor in /wp-content/uploads/.../wp-upd.php
The added username was t2trollherten like described.
reports of problems around users : SEE 4 UR SELF
Thanks alot for the info
Our website also has been hacked by the same newly added admin.
Not sure how this is going to end.
I hope we can take control of our website. Or can we?
Thanks for this post! I've been busting my head all morning trying to figure out how a site belonging to one of our partners has been compromised and the answer was lying in my mail. It's exactly as the post says: the t2trollherten user and the wp-cache.php shell.
Thank you for this information. On one of my sites I found the user t2trollherten. But on my other site I found the webshell that you mention.
Here some more information about the webshell: wp-cache.php
To anyone trying to recover from this problem by using a backup prior to 6.11.18 as advised by the WP GDPR COMPLIANCE PLUGIN under: https://www.wpgdprc.com/wp-gdpr-compliance-1-4-3-security-release/
I think in some cases this might not be enough and you have to use a backup before 13.10..
Here is why:
If you find a Plugin installed called: 2MB Autocode
You probably also find a file called wp-cache.php in your /wp-content/plugins directory.
On the support forum of the 2MB Autocode Plugin the first incidents are dated to 13.10.18.
They discovered also the WP GDPR COMPLIANCE PLUGIN as the source of the problem.
I found the wp-cache.php file (webshell) with the date of 15.10.18 and half an hour later the 2MB Autocode Plugin got installed.
I think these are two different attacks using the same weakness in the WP GDPR COMPLIANCE PLUGIN
Wow, i just had one site attacked, deleted the admins and the wp-cache.php file, but did not see the file you mentioned. How did you check for all the injections in the files ?
doing a wordfence scan now
Maybe wordfence can add option to auto disable plugin with critical security. really appreciated. I was hacked and I check my site often. good thing it didn't work well. it seems my site url option was changed to another site. but it didn't redirect.
3 websites of my clients were attacked. At 2 websites new admins were created. I deleted these fake admins, generated new passwords and deleted the plugin. The site number 3 was completely destroyed and I would have to restore them via a backup. Thanks for your notification, without that I would react much later
To fix this (especially if you cannot access WP) you should perform a rollback via your server host to a previous backup. Then log in to WP. Then delete the GDPR Plugin. Then change your passwords.
I had the user t2trollherten added to my users also. Fortunately my Securi Security plugin notified me. I was able to go in within minutes and delete the user. I was also able to see the failed attempt to log into that user later that day.
Have updated plugin on all sites, and have since been affected, the following is found in error log:
[10-Nov-2018 13:14:47 UTC] WordPress database error Table 'swclient_c84012.sweb_wpgdprc_access_requests' doesn't exist for query ALTER TABLE `sweb_wpgdprc_access_requests`
ADD column `token` text NOT NULL AFTER `ip_address`; made by require('wp-blog-header.php'), require_once('wp-load.php'), require_once('wp-config.php'), require_once('wp-settings.php'), do_action('plugins_loaded'), WP_Hook->do_action, WP_Hook->apply_filters, call_user_func_array, WPGDPRC\WPGDPRC->init, WPGDPRC\WPGDPRC::handleDatabaseTables
And the site URL was changed to a .de domain name (have changed back now via phpmyadmin and didn't copy it down).