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 .
Table of Contents [TOC]
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 :
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.
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:
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.
Data collected from WP Hacked Help malware scans, activity, and site cleanup reports revealed two primary types of operations.
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.
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:
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 :
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.
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.