Cancel

Sarah Gooding

WP GDPR Compliance Plugin Patches Privilege Escalation Vulnerability

At the end of last week, a plugin called WP GDPR Compliance sent out a security update for a privilege escalation vulnerability that was reported to the WordPress Plugin Directory team on November 6. The plugin was temporarily removed and then reinstated after the issues were patched within 24 hours by its creators, Van Ons, a WordPress development shop based in Amsterdam.

The changelog for the most recent release states that previous versions are vulnerable to SQL injection due to “wrong handling of possible user input in combination with unsafe unserialization.” The fixes are in version 1.4.3, which includes the following:

  • Security fix: Removed base64_decode() function
  • Security fix: Correctly escape input in $wpdb->prepare() function
  • Security fix: Only allow modifying WordPress options used by the plugin and by the user capabilities

Van Ons said they requested the Plugin Directory team do a forced update but they said it was not an option in this case.

WP GDPR Compliance has more than 100,000 active installs. According to Wordfence, the vulnerability is being actively exploited in the wild and many users are reporting new administrator accounts being created on their affected sites. The Wordfence blog has a breakdown of how attackers are taking advantage of these sites:

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.

Wordfence has seen multiple malicious administrator accounts present on sites that have been compromised, with variations of the username t2trollherten. Several WP GDPR Compliance plugin users have commented on the Wordfence post saying they were victims of the exploit, having found new admin users with a backdoor and file injections added.

The plugin has its own website where the vulnerability was announced. Its creators recommend that anyone who didn’t update right away on November 7, 2018, should look for changes in their databases. The most obvious symptom of attack is likely to be new users with administrator privileges. Any unrecognized users should be deleted. They also recommend restoring a complete backup of the site before November 6 and then updating to version 1.4.3 right away.

The WP GDPR Compliance plugin lets users add a GDPR checkbox to Contact Form 7, Gravity Forms, WooCommerce, and WordPress comments. It allows visitors and customers to opt into allowing the site to handle their personal data for a defined purpose. It also allows visitors to request data stored in the website’s database through a Data Request page that allows them to request data to be deleted.

While the name of the plugin includes the word “compliance,” users should note that the plugin details includes a disclaimer:

“ACTIVATING THIS PLUGIN DOES NOT GUARANTEE YOU FULLY COMPLY WITH GDPR. PLEASE CONTACT A GDPR CONSULTANT OR LAW FIRM TO ASSESS NECESSARY MEASURES.”

A relatively new amendment to section 9 of the plugin development guidelines restricts plugin authors from implying that a plugin can create, provide, automate, or guarantee legal compliance. Heather Burns, a member of WordPress Privacy team, worked together with Mika Epstein last April to put this change into effect. This guideline is especially important for users to remember when a plugin author uses GDPR Compliance in the name of the plugin. It isn’t a guarantee of compliance, just a useful tool as part of larger plan to protect users’ privacy.

Category: ,
Tags: ,
11

11 responses to “WP GDPR Compliance Plugin Patches Privilege Escalation Vulnerability”

  2. What happened there is a good reminder of the usefulness of making sure plugins are up to date at all times, which you can set WordPress to do for you, since that would have protected websites from being hacked, where even something like Wordfence’s paid service Wordfence Premium didn’t stop websites from being hacked.

    You are behind in these vulnerabilities though, since we full disclosed a vulnerability of the same type in the plugin Kiwi Social Share, which has 30,000+ installs, earlier today. Anyone using that plugin would want to disable that plugin until a fix is released, since as that other vulnerability shows, that type of vulnerability will be exploited. We only full disclosed that vulnerability instead of working with the developer to fix it before disclosing it due to the WordPress teams’ continued refusal to clean up the inappropriate behavior of the moderators of the wordpress.org Support Forum.

    Create forum topic from comment

  3. Van Ons said they requested the Plugin Directory team do a forced update but they said it was not an option in this case.

    It would be good to know why? Didn’t WordPress.org already force update for a few plugins because of security issues?

    Create forum topic from comment

    • We didn’t say a forced update wasn’t possible, just that it would not have helped. They released the update a day earlier. By the time this was asked for, a third of the sites had already been updated. The timeline of updates is something we know very well, and since the exploiting was already underway, forcing it would not move the needle any faster.

      It isn’t that we can’t, it’s that it was too late. You need to plan for forced updates before releasing the fixes.

      Create forum topic from comment

      • Currently 13% of active installations are 1.3.x or older.

        The plugin has 100k+ active installations, 78k downloads during last week, that’s about since the incident.

        That means at least 22k are not at latest version yet, at least 9k of those are in 4.x.

        Result of quick math:

        An absolute minimum of 9k sites can still be taken over completely due to this vulnerability.

        Maybe over 22k sites, if the vulnerability also exists in 1.3.x version.

        The actual still vulnerable number is higher, the unknown real number behind 100k+ is actually more than 100k.

        Create forum topic from comment

      • Your team should have been the ones planning for forcing the update before it was released, seeing as the plugin was a possible vector for a previous exploitation and it had at least two vulnerabilities that were fixed that were likely to be exploited.

        There is the additional big issue with that process currently, which is that you are providing the new version of the plugins to hackers before websites can easily upgrade to it, since the new version gets added to the Subversion repository while the plugin is stilled closed. It usually is easy to work back from the changes being made to how to exploit the vulnerability being fixed if you know what you are doing.

        You really need to bring in additional people that have a better understanding of security or be willing to work with others, like us, that have a better understanding of it, so that your processes can be improved, because right now your team is making mistakes that should be easy to fix. Not just with this, but, for example, with your failure to make sure your manual security reviews of new plugins before they are allowed in the Plugin Directory don’t miss easy to spot exploitable vulnerabilities (we have repeatedly offered to help your team with that).

        Create forum topic from comment

  4. Oh, the irony…

    Government forces every website to implement complicated user and consent management.

    This forces even the most basic website to implement ways for users to accessing their information.

    The extra layer of user consent management makes basic websites orders of magnitude more open to unauthorised access.

    Create forum topic from comment

  5. I don’t understand what this plugin does that you can’t already achieved with the plugins it’s supposedly supports. You can ‘become compliant’ with the likes of Contact Form 7 and Gravity Forms by adding checkboxes with privacy statements in their respective form builders and ensuring you handle user data correctly and safely.

    From what I’ve read, this plugin just adds another layer on top of these contact form plugins (plus WooCommerce) which seems to just add complexity and in this case scenario, a vulnerability that could have been avoided.

    Van Ons said they requested the Plugin Directory team do a forced update but they said it was not an option in this case.

    I’d imagine this may have something to do with the fact that auto updating the plugin may have masked the need for some people to do a full post-mortem of the hack they suffered and left admin accounts and scripts lying around. I don’t see any other reason to prevent an auto update to affected sites.

    Create forum topic from comment

    • About time, there are more targets around just waiting. Lots of bad coded no-extra-value GDPR spam plugins, lots of Gutenberg mega-blocky-thing spam with similar code-quality far from any wordpress code guidelines… only due to low installs nobody cares, yet.

      Another problem in repository, there is currently no way to also push/provide an update with a small fix within an older branch of a plugin, e.g. after an incident.

      Some already exploited plugin with 100k+ installs still has 30% users on an older major branch, still vulnerable to full RCE, because the newer branch release of the plugin broke compatibility too hard for existing sites, so users simply stopped updating.

      Fun times, if you are evil.

      Create forum topic from comment

  6. We are seeing another wave of attacks, where attackers try to guess the passwords of the malicious users being inserted in the previous exploitation phase.
    Requests are made upon the XMLRPC interface “/xmlrpc.php” and look like this :

    wp.getProfile

    9999
    t2trollherten
    0rt8Ka7slborUi

    Create forum topic from comment

You may also like

Newsletter

Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.