WordPress GDPR Compliance Plugin Exploit Vulnerability

2.7 (54.29%) 7 votes

 WordPress GDPR Compliance Plugin Exploit Vulnerability Hack

The General Regulation of Data Protection (GDPR), is the legislation in force since May 25, 2018 that guarantees the protection of the data that people provide to Companies, Governments, Institutions, Organizations and any organisation based in the European Economic Community or that manages data of its citizens.

As we know, this Regulation has forced WordPress websites to make a series of changes that can guarantee WordPress GDPR Compliance with the principles of transparency of information (say who you are, where you are, what do you do with the data and for how long), have express consent of your users to collect and use their data, provide facilities for users to exercise their rights and report information leaks.

For example, Google Analytics, responsible for the processing of data from a large number of pages within the world of digital marketing, has initiated a series of changes in its configurations.

Recently, the WP GDPR Compliance plug-in was briefly removed from the WordPress.org repository after the discovery of critical security issues affecting its users.

Here, we provided some details about WordPress GDPR compliance plugin hack and showed how serious this exploit or vulnerability is, and effective ways to tackle this Privilege Escalation Flaw In WP GDPR Compliance Plugin .

What data does WordPress collect?

WordPress collects as personal data:

Comments, Registries, subscriptions, contact Forms, as well as third-party add-ons such as web analytics, security, etc., plugins, cookies and other tracking codes, among other external services integrated into your website.

Also Read :

What are the specific actions that you must perform in order to comply with the Regulation?

  1. Update your version of WordPress to 4.9.6 or higher, where there is an initial adaptation to some aspects of the GDPR.
  2. Present evidence that you have the express consent of your users for the use and control of their personal data. This is one of the main objectives of the WordPress plugins created to guarantee compliance with the Law.
  3. Have privacy policies, legal notice and updated cookies
  4. Offer the possibility that users see their data and can choose what to do with them
  5. Use checkboxes and a brief summary of the privacy policy in all forms on your website. Almost all plugins bring this option.
  6. In the direct purchase pages, you must add the privacy text to the pages of My Account and Finish Purchase
  7. Integration with the data exporter created in WordPress, also to comply with the GDPR
  8. Tools to delete and anonymize old orders that do not need more billing processes
  9. Tools with which to remove optional fields at the end of the purchase, in the payment process
  10. You must put a link to the policies of the third party services that you are using on your website: Email Marketing, Google Analytics, Facebook ads, etc.

What is the WordPress GDPR Hack?

 WordPress GDPR Compliance Plugin vulnerability-flaws

The WordPress GDPR hack allows a hacker to do what he wants with the site. Activating this plugin does not guarantee you fully comply with GDPR. You can contact us to assess necessary measures and prevent your site from such attacks by following the General Regulation of Data Protection (GDPR) appropriately.

This WordPress exploit affects WP GDPR Compliance versions up to and including 1.4.2. The patched version, 1.4.3, is now available within the WordPress plugin repository. 

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.
According to security blog Sucuri’s Pedro Peixoto – The exploit resulted in malicious actors adding administrator accounts that are normally a variation on ‘t2trollherten’ and ‘t3trollherten’, as well as ‘superuser’. The exploit has also been associated with uploading a malicious webshell, named wp-cache.php, to allow attackers unauthorised access to sites.

How harmful is GDPR plugin Hack for your WordPress?

This vulnerability is very serious and more and more sites are getting actively targeted by GDPR plugin hack.

For example, see a the following screenshot of his hacked site.  

The screenshot reveals following facts:

  • Hackers were able to create two administrator-level users on their website.
  • An administrative-level user can do anything he wants on a WordPress website.
  • Facebook user has confirmed that this site uses the WP GDPR Compliance plug-in.
  • Victim reports that the hacking appeared to be automated. Hackers had not yet installed backdoor and unreliable pages.
  • Deleted the unauthorised administrator accounts.
  • Then deleted his old WordPress installation, installed a new version and updated the plug-in.
  • The site was quickly put online without the effects of piracy.

By considering above given points, it seems that hackers may be using robots whose role is limited to hacking WordPress sites via the WP GDPR Compliance plug-in vulnerability and then registering administrator accounts. It was later that they began to create unreliable web pages. Nevertheless, it is important to update this plugin as soon as possible.

Two Exploits of WP GDPR plugin

Data collected from WP Hacked Help malware scans, activity, and site cleanup reports revealed two primary types of operations.

  • The first case, identified at the beginning of our research and mentioned in yesterday’s message, concerns the modification of user registration parameters.
  • Second case, captured and logged by the new firewall rule for this vulnerability, injects malicious scheduled actions to be executed by WP-Cron. The examples we saw of both types of attacks use backdoor scripts named wp-cache.php, although the contents of these backdoor files differ between the two methods.

Administrator access via changed settings

The most common attack attempts against this vulnerability at the time of writing this article directly exploit the ability to modify arbitrary parameters on affected sites. By enabling the registration of new users and changing the default role of new users to administrator, attackers can simply create a new privileged user, and log in and take action on the newly compromised site.

Interestingly, automated attempts to run this activity also override changes to the settings. The following screenshot contains the relevant access log entries for such an attack.  

In this log, we first see a GET request on the home page of the site. This first request is necessary to produce the nonce “ajaxSecurity” required by the plug-in to perform AJAX actions. Then two POST requests are sent to /wp-admin/admin-ajax.php. The data stored in the POST bodies are not visible in the access logs. However, during our research, we were able to acquire samples of these data. The first two AJAX requests contain the below-given data:

action = wpgdprc_process_action & data = {"type": "save_setting", "append": false, "option": "users_can_register", "value": "1"} and security = [edited]

action = wpgdprc_process_action & data = {"type": "save_setting", "append": false, "option": "default_role", "value": "administrator"} & security = [redid]

In the first action, the attacker enables the users_can_register option, which adds functionality to the wp-login.php page of a site, allowing users to create new accounts. Then, the default_role option is set to ‘administrator’, which means that any new user registered on the site is automatically assigned full administrator access.

The following log entries show that the attacker has sent a POST request to /wp-login.php?action=register, as well as the subsequent redirection to “Registration completed.” Please check your email “dialogue. 

Finally, two other AJAX requests containing the following instructions are made: 

action = wpgdprc_process_action & data = {"type": "save_setting", "append": false, "option": "users_can_register", "value": "0"} and security = [edited]

action = wpgdprc_process_action & data = {"type": "save_setting", "append": false, "option": "default_role", "value": "subscriber"} & security = [edited]

Here we see the attacker reversing the configuration changes that allowed him to create an administrator account, first by disabling the user registration and then setting the default user role to “subscriber”.

This helps prevent other attackers from creating their administrator accounts, as well as reducing the chances that the site administrator will notice a problem.  

Several hours after the new user is created, the attacker connects to his new administrator account and can start installing other backdoors. In our case examples, we have seen attackers upload a robust PHP web structure to a file wp-cache.php. 

Check the screenshot of the shell user interface.  

With a file manager, PHP eval features and a terminal emulator, a script like this one on a site can allow an attacker to deploy other payloads as he requires.

Backdoor Installation Via Injected Cron

The second type of exploitation we are seeing is less simple and more difficult to identify at a glance. By injecting malicious actions into a site’s WP-Cron schedule, these attackers can install a persistent backdoor that can be overwritten if it is removed. Although various malicious actions can be stored and executed via WP-Cron, the cases we have seen so far are based on the presence of another popular WordPress plug-in, WooCommerce.

The following line contains a body part of an AJAX request blocked by the Wordfence firewall for attempting to insert a malicious WP-Cron job: 

"Woocommerce_plugin_background_installer": {"[redacted]": {"time": "time", "args": ["2mb-autocode", {"repo-slug": "2mb-autocode"}], "interval": 3600}} 

This recurring task attempts to use WooCommerce’s built-in woocommerce_plugin_background_installer action to install the 2MB Autocode plug-in, which allows arbitrary PHP code injection into all publications in a site. Since the injection code is stored by 2MB Autocode as an option in the database, the next step is to modify this parameter using the same vulnerability: 

{"Type": "save_setting", "option": "2mb_autocode_topstring", "value": "[malicious_php]"} 

The [malicious_php] placeholder in the example above contains a PHP backdoor script that performs the following actions in order: 

  • Receive the encrypted entries stored in the attacker request in the form of an “HTTP_X_AUTH” header, which declares the locations used in the following steps.
  • Make a request to http: // pornmam [.] Com / wp.php
  • Disable and remove the 2MB Autocode plugin
  • Decode the answer and save the resulting PHP backdoor as wp-cache.php
  • Clear the WP-Cron event associated with the attack
  • Include the main file /wp-admin/includes/file.php
  • Delete the 2mb_autocode_topstring option containing this code.

Although the backdoor script observed in these cases shares the name wp-cache.php with other methods, the content is very different.

Instead of a standalone web shell, this script contains decoding functions and runtime syntax, but none of the useful data that is executed is stored in the file.

Instead, the load to be decoded and executed is stored as a POST variable or in a cookie. 

Without any query captured in this script, we cannot know exactly what the desired behavior is. However, given its possible call and nature of the script to eval (), it is expected that any arbitrary code can be executed via this backdoor. 

Note: The plugin has been installed more than 100,000 times, depending on the information from the WordPress plugins portal. The vulnerability was fixed on 7 November 2018 with the release of version 1.4.3.

The plugin has recorded an additional 42,334 downloads (at the time of writing) since its last release, although currently, wordpress.org does not distinguish between updated and new installations.

This leaves a large number of sites vulnerable to this attack.

Also Read :

WordPress GDPR Plugin Exploit Removal

At this point, Google returns more than 5,000 results for the query [“erealitatea [.] Net”]. Many of these results come from infected sites that have begun to load resources from this area.

The URL change itself is a bit of a headache because the site will stop loading properly. WordPress uses the siteurl option to generate links to static content such as scripts, CSS, and images. The erealitatea [.] Net site is currently out of service.

As a result, infected loading sites takes a very long time – after which they look corrupted because none of the static resources is loaded. On the other hand, if the malicious site were in place, it could transmit any malicious content to infected websites.

The same problem occurs if you try to connect to the backend of the site, which means that the site owner loses access to the site and can not even solve the problem.

Change URL of the site

Resolving the URL parameter change is rather simple, however:

All you need to do is manually change the database table of the wp_options site. Look for a record where option_name is equal to “siteurl”. From here, you will find the changed domain in the option_value field. 

Simply update the option_value field with the correct domain and the site will load normally.

Here’s a handy SQL query to do it: 

UPDATE `wp_options` SET option_vaue = 'https: // YOUR-SITE-DOMAIN-HERE' WHERE option_name = 'siteurl'; 

Keep in mind that your actual database may have variations because the table prefix (used here as “wp_”) may have been configured differently. If in doubt, consult the developer / maintainer of your site before taking any immediate action and always make a backup first.

Correcting this database record is the appropriate way to solve the problem. If you are not comfortable with manual database editing, you can solve this problem by setting constants in your wp-config.php file. 

Add the following lines at the beginning, but after opening “<? Php” tag of your configuration file: 

define ('WP_HOME', 'http: // YOUR-SITE-DOMAIN-HERE');

define ('WP_SITEURL', 'http: // YOUR-SITE-DOMAIN-HERE');

Do not forget to change YOUR-SITE-DOMAIN-HERE with your domain! =) 

It is also important to note that this URL change is not the only hacking executed through this vulnerability. We have seen that sites running the compromised version of this plugin also have some malicious administrative users, created with different login names:  

This is usually a variant of ‘t2trollherten’ and ‘t3trollherten’, but we have also seen variants of ‘superuser’ and a malicious wp-cache.php file at the root of the WordPress installation.

You must also disable user registrations and ensure that the default user role is not set to Administrator. This can be accomplished by unchecking the box under Settings> Membership from the WordPress Dashboard. You will also need to replace the role under New Default Role with one user per Subscriber. 

It is also important to indicate that this is not the first case of a plug-in vulnerability or a disclosed theme. We’ve seen famous tagDiv themes and the popular WordPress Duplicator plugin, which has vulnerabilities, allowing attackers to hack many sites around the world.

A very effective way to stay protected is to use the WP Hacked Help protection analyzer to filter malicious content even before it reaches the hosting server.

If you think that the WP GDPR vulnerability has an impact on your site and you need help, contact us.

Leave a Reply

Your email address will not be published. Required fields are marked *