Emergency WP 5.5.3 Release

The WordPress core team has released an emergency release of WordPress 5.5.3, just one day after the release of version 5.5.2. This emergency release was done to remedy an issue introduced in WordPress 5.5.2 making it impossible to install WordPress on a brand new website without a database connection configured. In preparing for this emergency release, a second issue caused a number of sites to be erroneously updated to version 5.5.3-alpha.

According to the release notes, between approximately 15:30 and 16:00 UTC on October 30, the WordPress auto-update system updated some sites from version 5.5.2 to 5.5.3-alpha. This occurred because the WordPress Core team disabled the download of the 5.5.2 release in an attempt to prevent new users from using this version. By disabling the download for 5.5.2, the wordpress.org API returned the alpha version 5.5.3-alpha-49449 as the version to which WordPress should update.

An analysis of the 5.5.3-alpha-49449 release found little difference between the WordPress 5.5.2 release and WordPress 5.5.3-alpha-49449 as much of the core functionality is the same. No reported site functionality was lost due to the error. However, with that autoupdate, a number of additional Twenty- themes were installed along with the Akismet plugin.

To fix both issues, the Core team initially re-enabled download 5.5.2 to prevent sites from updating to the alpha version followed by the emergency release of WordPress 5.5.3 to address the issue which prevented new installations.

What Should I Do?

If your site was updated to WordPress 5.5.3-alpha, you may have additional themes installed on your site. You might also have Akismet installed. These themes and plugin were not activated if installed as a part of the pre-release package. Check your themes and plugin installations. No other plugins would have been installed or removed.

Update your sites normally to WordPress 5.5.3, just as you would for any other WordPress update. If you are allowing your site to autoupdate, the 5.5.3 version may already be installed.

If you had not yet updated to WordPress 5.5.2, updating to 5.5.3 is essentially the same update with a minor fix. Updating your site is safe to do.

The post Emergency WP 5.5.3 Release appeared first on Wordfence.

Read More

Introducing Wordfence Central Teams

Last year, we introduced Wordfence Central and today thousands of WordPress site owners are using this free tool to manage their WordPress sites. Whether you’re using Wordfence Premium or still on the free plugin, Wordfence Central makes it possible for you to manage your sites’ security settings, tune your security alerts, and quickly assess security events all from one dashboard view.

With more businesses using these free features to manage their security alerts, we’re happy to announce another free feature: Wordfence Central Teams. Teams makes it possible to delegate access to your Central account by inviting trusted administrators onto your Team. Now, managing WordPress security across numerous sites is faster and easier than ever.

Why Wordfence Central Teams?

The core functionality of Wordfence Central makes managing more than one WordPress site easier. When you’ve got numerous team members managing site security, there can be numerous permutations of site management needs. Allowing a site to be managed by more than one individual as a part of a team not only makes managing numerous sites easier, but also improves account security. It is a security best practice to have individual logins rather than a shared login for authorization and accountability purposes.  Wordfence Central Teams improves upon security by providing individual logins for your site admins.

From one individual login, a Wordfence Central user can access multiple teams. This will make it easier for that user to get the security data they need to keep sites safe while also being able to configure Wordfence across numerous sites faster.

Getting Started with Wordfence Central Team Management

Site owners managing a number of sites can create a team and invite individuals to that team. There is no limit to the number of team members that can be on a Wordfence Central Team. An invitation is valid for 30 days from the initial invite, and a follow up email can be sent by the team owner/manager.

To get started, click on the account drop-down in the upper right, then click Team. Click Get Started under Start a Team. Choose a name for your Team and click Next. Once you’ve chosen a name for your team, it’s time to invite site managers. Just enter the email addresses of anyone you’d like to manage the sites in your Central account and click Send Invitation. An invitation email will be sent to the invited site manager(s), and Wordfence Central will list details about individual team membership.

Wordfence Central Teams Invitations and Members

If the invited person does not yet have a Wordfence Central account, they’ll be prompted to set up an individual account prior to accessing the sites within your team.

The team manager can revoke an individual’s Wordfence Central Team membership at any time. This won’t revoke the user’s access to a site’s wp-admin area. If that individual has access to a site’s administrative dashboard, you’ll need to revoke access there as well, if needed.

Joining a Wordfence Central Team

If you receive an invitation to join a Wordfence Central Team, click the link in the email to accept the invitation. You’ll be brought to the Wordfence Central dashboard where you can accept that invitation and access management of that team’s sites.

Wordfence Central Teams invitation email

An invited Wordfence Central user will have the same capabilities as the site owner for managing each site within the team including seeing security alerts, creating and applying templates to the individual sites, and configuring and tuning alerts for email, SMS, and Slack. They will not, however, have access to manage the overall team membership such as adding or removing team members, etc.

Accessing More than One Team

When you’re logged into your Wordfence Central account, you will have access to every team to which you’ve been granted access from that team’s manager, as well as capabilities to manage the team that you own.

Switching between the teams that you have access to is simple. By accessing the dropdown under “Account,” you have access to a list of all of the teams to which you have access.

Wordfence Central Teams Switching Account

You can also switch back to your own team and manage access to the team you’ve established.

Wordfence Central does not currently allow a team manager to create more than one team. However, each user can be a member of as many teams as they like, and users can join each other’s teams.

Wordfence Central is Free to Use

Wordfence has continuously made a commitment to providing many tools free of charge to the WordPress community, and Wordfence Central is no different. Whether your sites are secured by Wordfence Premium license or if you’re still using the free version, your WordPress development teams can utilize the features in Wordfence Central Teams without charge.

Many thanks to the Wordfence Premium customers who help fund continued development of new Wordfence features, Threat Intelligence, and education programs.

If You Haven’t Yet Tried Wordfence Central

If you have not yet gotten started with Wordfence Central, we invite you to try this free tool. To connect Wordfence Central to your WordPress site, just ensure Wordfence is installed. Authenticating to Wordfence Central is simple and easy. We have also developed demonstration videos to walk through the process.

The post Introducing Wordfence Central Teams appeared first on Wordfence.

Read More

WordPress Auto-Updates: What do you have to lose?

A new feature that will allow automatic updating of plugins and themes will be available in WordPress version 5.5, which is scheduled to be released on August 11, 2020. In this core release of the world’s most popular content management system, site owners will have the option to turn auto-updates on for individual plugins and themes directly from the WordPress admin dashboard.

In this post, we take a look at what happens in an automatic update, why WordPress core is adding this feature, the benefits and pitfalls of automatic updating, the three different approaches a site owner can take, and our overall recommendations from the Wordfence team to ensure the security and reliability of your WordPress websites.

What Happens During an Automatic Update?

Auto-updates for plugins and themes will be turned off by default upon release, meaning that auto-updates will not be automatically enabled when WordPress 5.5 is rolled out. Site owners will have to visit the theme or plugin dashboard to enable auto-updates and choose which packages to automatically update when a new version of the plugin or theme is available. Site owners can choose to turn on auto-updates for all of the installed plugins, choose to auto-update some of their plugins, or choose not to turn on auto-updates for any plugins whatsoever.

Auto-update option is a new feature available in WordPress 5.5.

Auto-updates in WordPress 5.5 will only have an off or on toggle. Site owners won’t have the option to select different types of updates, such as only applying security updates, or only updating to minor releases.

Updates will be triggered by the wp-cron process twice daily. If the process finds that there are plugins or themes with available updates, whether a minor security fix or a large scale feature update, the new version of the plugin or theme will be downloaded and automatically installed on the site. Updates only occur if auto-updates are turned on for that particular plugin or theme.

These automatic updates are what operations engineers refer to as “unattended updates,” meaning that the code of plugins and themes are updated and deployed without the site owner’s participation. They may get triggered while a site owner is on the site publishing, they may get triggered overnight when a site owner is asleep, or during the day when the site owner is in the middle of an important meeting. The site owner will receive an email that updates have taken place, but if they miss that email, they might not know until they log in again and see a new version of the updated plugin or theme.

This marks a major shift from the attended updates currently required in WordPress. Currently, each plugin and theme update requires that the site owner or administrator initiate the updating process to download and install a new version of a plugin or theme.

In rare cases, some plugins have auto-updates built in and are already updating automatically. Wordfence is one of these plugins. Wordfence has offered an optional auto-update feature for several years to help keep our customers secure.

Why is WordPress Core Adding Automatic Updates?

One of the most prolific vectors of WordPress malware infections is the presence of vulnerabilities in out-of-date plugins, themes, and less frequently, WordPress core. By adding automated updating features to WordPress plugins and themes in the WordPress 5.5 core release, the core team looks to improve the security of WordPress installations across the board and make maintenance easier for site owners. Rather than having to log in to your WordPress site regularly to perform required plugin and theme updates, your site will run “unattended” updates when updates to installed plugins and themes are made available within the WordPress repository.

Last year, WordPress core added fatal error protections to the built-in WordPress site health functionality. When a fatal error occurs, fatal error protection determines which plugin caused the fatal error, and emails the site administrator so that they can troubleshoot the site with the problematic plugin deactivated in order to try and fix the issue. The addition of this feature likely gave the WordPress core team confidence that the risks of auto-updates would be easily managed by fatal error protection.

Is This a Good thing?

Overall, our philosophy is that providing automated updates is a good thing for a subset of WordPress sites. Blogs and informational or promotional sites which can often go unattended for months or years are at higher risk of being hacked via outdated plugins or themes. For these sites, the risk of being hacked outweighs the risk of an automatic update gone awry. However, for other kinds of sites, automated updates may create problems.

Problems and Pitfalls of Automated Updating

Unattended auto-updating of any code base is not without possible problems, and WordPress themes and plugins are not unique in this respect. Even attended updates can present difficulties. When the health and safety of your site is at stake, making an informed decision is critical. As such, we developed a few scenarios where auto-updates could cause potential problems such as site outages, data corruption, malicious content, amongst other undesirable effects.

Not all of these scenarios may affect you and your WordPress site. Below are a few caveats to keep in mind when determining what risk level your organization faces by enabling auto-updates.

  1. Concurrent auto-updates can fail. If a number of plugins have updates within a few hours, and wp-cron triggers them all to auto-update concurrently, this could lead to auto-updates failing on a server where resources are over utilized. If a triggered auto-update fails for any reason, the site may experience fatal error messages. In rare cases, plugins might become deactivated, or a site could be taken offline or stuck in maintenance mode.
  2. Issues may be introduced that limit site functionality without the site owner’s knowledge. For example, let’s say you have a WooCommerce store, and your WooCommerce supportive plugins auto-update while you’re on vacation. One of those supportive plugins has just been auto-updated, and that auto-update makes product checkout on your site impossible. It’s August. You usually have a seasonal slowdown when many people are on vacation, so the drop in sales is not unexpected. Meanwhile, your ecommerce site is essentially not functioning properly and your vacation is interrupted when a customer writes to you days later.
  3. Difficulty determining “what changed.” Whenever a problem occurs in IT operations, the first question to ask when trying to troubleshoot the problem is “What changed?” If you have two or more unattended updates that have occurred, multiple things have changed and it can become much harder to isolate the root cause of the problem.
  4. Vulnerabilities can be introduced with new features. With a recent update to the wpDiscuz plugin, new features introduced new vulnerabilities affecting over 80,000 WordPress sites. If your organization does a code review on any new plugin code being deployed to your production WordPress site, auto-updating removes your opportunity to do this code review and potentially catch vulnerabilities before they are deployed.
  5. Major version releases could have compatibility problems. Occasionally a vendor will put out a major release that makes significant changes to the code, or the database, or both. These higher risk releases could introduce problems, as we have seen with plugins that have a large installation base like Yoast and Jetpack. In April 2020, popular SEO plugin Yoast SEO released version 14.0, a major version release that refactored how information was stored in the WordPress database. We talked about the upcoming major update with Yoast CEO Marieke van de Rakt and COO Michiel Heijmans at WordCamp US last fall. This major update caused some sites to have issues that required immediate patching. For major plugin releases, it may make sense to take a “wait and see” approach to ensure the release is stable before deploying. Auto-updates remove your ability to take this approach.
  6. QA resources vary among plugins. Some plugins have large teams of developers and software quality assurance (SQA or QA) engineers behind them. Other plugins have smaller teams or are powered by a single developer who may be a hobbyist. Enabling auto-updates for plugins with larger teams is lower risk, because the plugin’s own QA team has provided comprehensive test coverage and significantly reduced the risk of anything going wrong with the release. Plugins with individual developers that lack QA resources should be considered higher risk due to the lack of test coverage or lack of testing altogether.
  7. Lack of canary releasing to test for issues. Canary updates roll out code to a small percentage of sites to check for problems. Chrome/Chromium uses this model to protect the larger install base from catastrophic issues. If no issues are detected, the update then rolls out to the rest of sites. WordPress has not built this system into auto-updates in version 5.5, and thus the auto-updates for a plugin roll out at the same time to the entire user population. This does not provide an early warning system that will reveal a catastrophic problem with a plugin. If you run a mission critical website, you can emulate the canary release process by waiting a few days before updating, for non security related releases. This may be a reason to disable auto-updates, depending on your specific needs.

Auto-updates Sounds Like It Has Problems. Does It Really?

With all of these pitfalls, there are obvious questions about whether or not having auto-updates enabled is a good solution. The biggest question you might have is: why Wordfence and other security experts recommend keeping plugins updated if rapid updating could introduce so many issues?

At the moment, nearly every update you perform on your site is done as an attended update. This means that you initiate the update, you know when your site has updated, you can read the developer’s changelog to determine whether or not it is a critical security update, a bug fix update, or a major release update on which you might want to wait. You can also test your site after every plugin update, and you are more likely to to determine the source of any problems introduced by a problematic plugin update.

By using unattended auto-updates, you lose that control and human intelligence when an update occurs.

We introduced auto-updates for the Wordfence plugin several years ago. We did this because, as a security plugin, it is critically important that our free and paid customers have the latest threat intelligence and security capability on their site. Before we deployed auto-updates in our own plugin, we spent a lot of time and energy ensuring our QA team and QA process was incredibly robust, with test coverage that is wide and deep.

We test our plugin on a large number of hosting platforms and with a large number of configurations before releasing any code. This does a good job of mimicking the canary release process by running the plugin on a wide range of systems before deploying to the entire user population. Once we were satisfied that auto-updating our customer’s Wordfence plugins was low risk, we deployed this feature. We haven’t had a signficant problem since, while our customers have benefited from automatic updates to their mission critical security plugin.

We continue to invest heavily in our QA team, infrastructure and processes to keep the risk of auto-updates very low.

The Three Approaches

We believe that you should make an informed choice about WordPress plugin auto-updates, knowing the benefits and pitfalls.

There are three ways you can approach auto-updates:

  1. Turn auto-update on for all plugins.
  2. Turn auto-update on for some plugins.
  3. Turn auto-update off for all plugins.

Which Update Strategy Is Right for You?

WordPress is popular because WordPress is so flexible. You can have a site that is an enterprise level application with millions of users, a learning management system with hundreds of users or a niche membership site. WordPress enables publishers and businesses in an infinite number of ways. Your update strategy will depend on your particular circumstances and needs.

To help guide your decision making, we have developed personas that represent several kinds of WordPress sites and site owners, to help you make an informed decision about your auto-update strategy. With each persona comes a different level of risk tolerance, and with that comes with a different approach to enabling auto-updates.

Hobbyist Blogger Auto-update ON

Hobbyist/Blogger

You developed a site to write about something near and dear to you, but you hardly ever sign in, you don’t actively maintain your plugins, and you trust that the Wordfence firewall is just going to block any malicious attacks. You randomly update plugins on one day every few months when you log in.

For this Hobbyist WordPress user, we recommend that you turn auto-updates for all themes and plugins ON.

Why?

  • The risk is lower as you are not relying on your WordPress site for income or services.
  • You are not checking on your site as frequently, so auto-updates ensure your site remains up to date which improves security.
  • The cost of an auto-update impacting your users is low. Worst case is that your content goes missing for a period of time until you discover the problem and fix it.

Small Business Brochureware Site Auto-Update ON

Small Business Brochureware

An agency helped you design your site, but you perform maintenance and updates on your site yourself. You don’t update your site much, and rarely log in. Having your site unavailable for a short time would be noticed by few and your site serves mostly as a marketing vehicle.

For the Small Business Brochureware WordPress user, we recommend that you turn auto-updates for all themes and plugins ON.

Why?

  • The risk is moderate as you are not relying directly on your WordPress site for income or services, but rather for marketing.
  • You are not checking on your site as frequently so auto-updates can ensure your site remains up to date, which improves security.
  • User impact in the case of down-time is low. Worst case for users is that your marketing content goes missing for a period of time. Though an issue may occur with an auto-updating plugin, in the greater scheme of things, it’s more important that your plugins remain updated to improve security and stability.

Small Business Ecommerce Selectively ON

Small Business Ecommerce

Your site is an integral part of your business. It takes orders and payments from customers or has other interactive elements such as a membership site, a learning management site, or other interactive commerce elements that cause your site’s database to change frequently. You sign into the admin dashboard regularly, and you perform your own attended updates.

For the Small Business Ecommerce WordPress user, we recommend that you turn auto-updates for themes and plugins ON selectively, and only in rare cases. If you are confident that a plugin vendor has a robust QA team and process, and a strong reputation for releasing solid code, then you may consider turning auto-updates on for that vendor’s plugins. Doing this will help you benefit from a quick update to releases that may include security fixes.

We recommend that you continue to perform attended updates on plugins that do not have a strong QA team and process. In these cases you may want to wait to determine if the release is problematic before updating. You will also be performing an attended update, which ensures you are present and observing your site performance, so that you can catch issues early and fix them quickly.

Why?

  • The risk is higher as you are relying directly on your WordPress site for income and services. Thus you want to be careful implementing auto-updates so that it does not impact your revenue.
  • You are signing into, and checking on your site more frequently, so auto-updates are not as much of a necessity, provided you still update in a timely manner.
  • Keep in mind that the plugins that auto-update will be updated without you present, as an unattended update. If you trust the team behind the plugin to deploy quality code to your site on demand, then enabling auto-updates for that plugin is still appropriate.

Agencies Businesses Auto-Updates OFF

Agencies or businesses with many sites

You are managing sites for numerous customers and you have operations staff, QA personnel and QA processes in place to perform attended updates and test for problems before deploying new code. All the sites under your care are considered mission critical.

If this is your situation, we recommend that you continue to NOT use auto-updates as currently implemented.

Why?

  • The risk is much higher, as you or your customers are relying directly on the WordPress sites in your care for income and services. Thus you want to avoid using auto-update so that it does not impact your revenue or that of your clients.
  • You are actively maintaining each WordPress site and have the resources to do so. You already update WordPress core, plugins and themes as soon as is practicable.
  • User impact is costly. Website users may experience issues making purchases or signing up for services.

Enterprise Auto-Update OFF

Enterprise

You have staging servers, development servers, and you perform code reviews on new plugins to look for potential vulnerabilities introduced in all updates before deploying. Nothing ends up on production servers without being rigorously tested by a stellar QA team. Your processes are built for 24/7 availability and you have the resources and team to power them.

As an enterprise user, we recommend you do not use unattended auto-updates in the current implementation.

Why?

  • The risk is at its highest as your WordPress site is mission critical.
  • Your QA team rapidly evaluates and tests new plugin releases in your staging environment. Auto-updates would remove this step.
  • Your operations team rapidly deploys well tested code into production using attended updates. Auto-updates would remove this process.
  • The business impact of a website disruption is extreme. Customers may experience issues making purchases, signing up for services, or accessing your content and resources.

How to Begin Using Auto-Updates

Regardless of which persona you are, we recommend holding off on enabling auto-updates until a few weeks or months after WordPress 5.5 has been released. As with any major change to software, bugs or issues may be found and patched in the next few weeks. We recommend waiting to ensure that auto-updates in WordPress 5.5 has time to undergo rigorous real-world testing before enabling auto-updates.

Even with auto-updates on, we still recommend regular backups for your site. We also recommend using a service such as Website Pulse or StatusCake to monitor your site availability.

The Future of Auto-Updates

WordPress 5.5 is a preliminary implementation of auto-updates, and is useful for a subset of sites. We do expect continued development of auto-update tools, perhaps even with the addition of beta, alpha, and canary releases to add more functionality and reliability to the auto-update process.

We hope that this discussion has provided insight into the new auto-updates feature in WordPress 5.5 and will guide you to making an informed decision. As always, you are welcome to post questions and comments below.

Thank you to Chloe Chamberland, Ram Gall, Matt Rusnak and Kathy Zant for their research and contributions to this post.

The post WordPress Auto-Updates: What do you have to lose? appeared first on Wordfence.

Read More

WordPress Auto-Updates: What do you have to lose?

A new feature that will allow automatic updating of plugins and themes will be available in WordPress version 5.5, which is scheduled to be released on August 11, 2020. In this core release of the world’s most popular content management system, site owners will have the option to turn auto-updates on for individual plugins and themes directly from the WordPress admin dashboard.

In this post, we take a look at what happens in an automatic update, why WordPress core is adding this feature, the benefits and pitfalls of automatic updating, the three different approaches a site owner can take, and our overall recommendations from the Wordfence team to ensure the security and reliability of your WordPress websites.

What Happens During an Automatic Update?

Auto-updates for plugins and themes will be turned off by default upon release, meaning that auto-updates will not be automatically enabled when WordPress 5.5 is rolled out. Site owners will have to visit the theme or plugin dashboard to enable auto-updates and choose which packages to automatically update when a new version of the plugin or theme is available. Site owners can choose to turn on auto-updates for all of the installed plugins, choose to auto-update some of their plugins, or choose not to turn on auto-updates for any plugins whatsoever.

Auto-update option is a new feature available in WordPress 5.5.

Auto-updates in WordPress 5.5 will only have an off or on toggle. Site owners won’t have the option to select different types of updates, such as only applying security updates, or only updating to minor releases.

Updates will be triggered by the wp-cron process twice daily. If the process finds that there are plugins or themes with available updates, whether a minor security fix or a large scale feature update, the new version of the plugin or theme will be downloaded and automatically installed on the site. Updates only occur if auto-updates are turned on for that particular plugin or theme.

These automatic updates are what operations engineers refer to as “unattended updates,” meaning that the code of plugins and themes are updated and deployed without the site owner’s participation. They may get triggered while a site owner is on the site publishing, they may get triggered overnight when a site owner is asleep, or during the day when the site owner is in the middle of an important meeting. The site owner will receive an email that updates have taken place, but if they miss that email, they might not know until they log in again and see a new version of the updated plugin or theme.

This marks a major shift from the attended updates currently required in WordPress. Currently, each plugin and theme update requires that the site owner or administrator initiate the updating process to download and install a new version of a plugin or theme.

In rare cases, some plugins have auto-updates built in and are already updating automatically. Wordfence is one of these plugins. Wordfence has offered an optional auto-update feature for several years to help keep our customers secure.

Why is WordPress Core Adding Automatic Updates?

One of the most prolific vectors of WordPress malware infections is the presence of vulnerabilities in out-of-date plugins, themes, and less frequently, WordPress core. By adding automated updating features to WordPress plugins and themes in the WordPress 5.5 core release, the core team looks to improve the security of WordPress installations across the board and make maintenance easier for site owners. Rather than having to log in to your WordPress site regularly to perform required plugin and theme updates, your site will run “unattended” updates when updates to installed plugins and themes are made available within the WordPress repository.

Last year, WordPress core added fatal error protections to the built-in WordPress site health functionality. When a fatal error occurs, fatal error protection determines which plugin caused the fatal error, and emails the site administrator so that they can troubleshoot the site with the problematic plugin deactivated in order to try and fix the issue. The addition of this feature likely gave the WordPress core team confidence that the risks of auto-updates would be easily managed by fatal error protection.

Is This a Good thing?

Overall, our philosophy is that providing automated updates is a good thing for a subset of WordPress sites. Blogs and informational or promotional sites which can often go unattended for months or years are at higher risk of being hacked via outdated plugins or themes. For these sites, the risk of being hacked outweighs the risk of an automatic update gone awry. However, for other kinds of sites, automated updates may create problems.

Problems and Pitfalls of Automated Updating

Unattended auto-updating of any code base is not without possible problems, and WordPress themes and plugins are not unique in this respect. Even attended updates can present difficulties. When the health and safety of your site is at stake, making an informed decision is critical. As such, we developed a few scenarios where auto-updates could cause potential problems such as site outages, data corruption, malicious content, amongst other undesirable effects.

Not all of these scenarios may affect you and your WordPress site. Below are a few caveats to keep in mind when determining what risk level your organization faces by enabling auto-updates.

  1. Concurrent auto-updates can fail. If a number of plugins have updates within a few hours, and wp-cron triggers them all to auto-update concurrently, this could lead to auto-updates failing on a server where resources are over utilized. If a triggered auto-update fails for any reason, the site may experience fatal error messages. In rare cases, plugins might become deactivated, or a site could be taken offline or stuck in maintenance mode.
  2. Issues may be introduced that limit site functionality without the site owner’s knowledge. For example, let’s say you have a WooCommerce store, and your WooCommerce supportive plugins auto-update while you’re on vacation. One of those supportive plugins has just been auto-updated, and that auto-update makes product checkout on your site impossible. It’s August. You usually have a seasonal slowdown when many people are on vacation, so the drop in sales is not unexpected. Meanwhile, your ecommerce site is essentially not functioning properly and your vacation is interrupted when a customer writes to you days later.
  3. Difficulty determining “what changed.” Whenever a problem occurs in IT operations, the first question to ask when trying to troubleshoot the problem is “What changed?” If you have two or more unattended updates that have occurred, multiple things have changed and it can become much harder to isolate the root cause of the problem.
  4. Vulnerabilities can be introduced with new features. With a recent update to the wpDiscuz plugin, new features introduced new vulnerabilities affecting over 80,000 WordPress sites. If your organization does a code review on any new plugin code being deployed to your production WordPress site, auto-updating removes your opportunity to do this code review and potentially catch vulnerabilities before they are deployed.
  5. Major version releases could have compatibility problems. Occasionally a vendor will put out a major release that makes significant changes to the code, or the database, or both. These higher risk releases could introduce problems, as we have seen with plugins that have a large installation base like Yoast and Jetpack. In April 2020, popular SEO plugin Yoast SEO released version 14.0, a major version release that refactored how information was stored in the WordPress database. We talked about the upcoming major update with Yoast CEO Marieke van de Rakt and COO Michiel Heijmans at WordCamp US last fall. This major update caused some sites to have issues that required immediate patching. For major plugin releases, it may make sense to take a “wait and see” approach to ensure the release is stable before deploying. Auto-updates remove your ability to take this approach.
  6. QA resources vary among plugins. Some plugins have large teams of developers and software quality assurance (SQA or QA) engineers behind them. Other plugins have smaller teams or are powered by a single developer who may be a hobbyist. Enabling auto-updates for plugins with larger teams is lower risk, because the plugin’s own QA team has provided comprehensive test coverage and significantly reduced the risk of anything going wrong with the release. Plugins with individual developers that lack QA resources should be considered higher risk due to the lack of test coverage or lack of testing altogether.
  7. Lack of canary releasing to test for issues. Canary updates roll out code to a small percentage of sites to check for problems. Chrome/Chromium uses this model to protect the larger install base from catastrophic issues. If no issues are detected, the update then rolls out to the rest of sites. WordPress has not built this system into auto-updates in version 5.5, and thus the auto-updates for a plugin roll out at the same time to the entire user population. This does not provide an early warning system that will reveal a catastrophic problem with a plugin. If you run a mission critical website, you can emulate the canary release process by waiting a few days before updating, for non security related releases. This may be a reason to disable auto-updates, depending on your specific needs.

Auto-updates Sounds Like It Has Problems. Does It Really?

With all of these pitfalls, there are obvious questions about whether or not having auto-updates enabled is a good solution. The biggest question you might have is: why Wordfence and other security experts recommend keeping plugins updated if rapid updating could introduce so many issues?

At the moment, nearly every update you perform on your site is done as an attended update. This means that you initiate the update, you know when your site has updated, you can read the developer’s changelog to determine whether or not it is a critical security update, a bug fix update, or a major release update on which you might want to wait. You can also test your site after every plugin update, and you are more likely to to determine the source of any problems introduced by a problematic plugin update.

By using unattended auto-updates, you lose that control and human intelligence when an update occurs.

We introduced auto-updates for the Wordfence plugin several years ago. We did this because, as a security plugin, it is critically important that our free and paid customers have the latest threat intelligence and security capability on their site. Before we deployed auto-updates in our own plugin, we spent a lot of time and energy ensuring our QA team and QA process was incredibly robust, with test coverage that is wide and deep.

We test our plugin on a large number of hosting platforms and with a large number of configurations before releasing any code. This does a good job of mimicking the canary release process by running the plugin on a wide range of systems before deploying to the entire user population. Once we were satisfied that auto-updating our customer’s Wordfence plugins was low risk, we deployed this feature. We haven’t had a signficant problem since, while our customers have benefited from automatic updates to their mission critical security plugin.

We continue to invest heavily in our QA team, infrastructure and processes to keep the risk of auto-updates very low.

The Three Approaches

We believe that you should make an informed choice about WordPress plugin auto-updates, knowing the benefits and pitfalls.

There are three ways you can approach auto-updates:

  1. Turn auto-update on for all plugins.
  2. Turn auto-update on for some plugins.
  3. Turn auto-update off for all plugins.

Which Update Strategy Is Right for You?

WordPress is popular because WordPress is so flexible. You can have a site that is an enterprise level application with millions of users, a learning management system with hundreds of users or a niche membership site. WordPress enables publishers and businesses in an infinite number of ways. Your update strategy will depend on your particular circumstances and needs.

To help guide your decision making, we have developed personas that represent several kinds of WordPress sites and site owners, to help you make an informed decision about your auto-update strategy. With each persona comes a different level of risk tolerance, and with that comes with a different approach to enabling auto-updates.

Hobbyist Blogger Auto-update ON

Hobbyist/Blogger

You developed a site to write about something near and dear to you, but you hardly ever sign in, you don’t actively maintain your plugins, and you trust that the Wordfence firewall is just going to block any malicious attacks. You randomly update plugins on one day every few months when you log in.

For this Hobbyist WordPress user, we recommend that you turn auto-updates for all themes and plugins ON.

Why?

  • The risk is lower as you are not relying on your WordPress site for income or services.
  • You are not checking on your site as frequently, so auto-updates ensure your site remains up to date which improves security.
  • The cost of an auto-update impacting your users is low. Worst case is that your content goes missing for a period of time until you discover the problem and fix it.

Small Business Brochureware Site Auto-Update ON

Small Business Brochureware

An agency helped you design your site, but you perform maintenance and updates on your site yourself. You don’t update your site much, and rarely log in. Having your site unavailable for a short time would be noticed by few and your site serves mostly as a marketing vehicle.

For the Small Business Brochureware WordPress user, we recommend that you turn auto-updates for all themes and plugins ON.

Why?

  • The risk is moderate as you are not relying directly on your WordPress site for income or services, but rather for marketing.
  • You are not checking on your site as frequently so auto-updates can ensure your site remains up to date, which improves security.
  • User impact in the case of down-time is low. Worst case for users is that your marketing content goes missing for a period of time. Though an issue may occur with an auto-updating plugin, in the greater scheme of things, it’s more important that your plugins remain updated to improve security and stability.

Small Business Ecommerce Selectively ON

Small Business Ecommerce

Your site is an integral part of your business. It takes orders and payments from customers or has other interactive elements such as a membership site, a learning management site, or other interactive commerce elements that cause your site’s database to change frequently. You sign into the admin dashboard regularly, and you perform your own attended updates.

For the Small Business Ecommerce WordPress user, we recommend that you turn auto-updates for themes and plugins ON selectively, and only in rare cases. If you are confident that a plugin vendor has a robust QA team and process, and a strong reputation for releasing solid code, then you may consider turning auto-updates on for that vendor’s plugins. Doing this will help you benefit from a quick update to releases that may include security fixes.

We recommend that you continue to perform attended updates on plugins that do not have a strong QA team and process. In these cases you may want to wait to determine if the release is problematic before updating. You will also be performing an attended update, which ensures you are present and observing your site performance, so that you can catch issues early and fix them quickly.

Why?

  • The risk is higher as you are relying directly on your WordPress site for income and services. Thus you want to be careful implementing auto-updates so that it does not impact your revenue.
  • You are signing into, and checking on your site more frequently, so auto-updates are not as much of a necessity, provided you still update in a timely manner.
  • Keep in mind that the plugins that auto-update will be updated without you present, as an unattended update. If you trust the team behind the plugin to deploy quality code to your site on demand, then enabling auto-updates for that plugin is still appropriate.

Agencies Businesses Auto-Updates OFF

Agencies or businesses with many sites

You are managing sites for numerous customers and you have operations staff, QA personnel and QA processes in place to perform attended updates and test for problems before deploying new code. All the sites under your care are considered mission critical.

If this is your situation, we recommend that you continue to NOT use auto-updates as currently implemented.

Why?

  • The risk is much higher, as you or your customers are relying directly on the WordPress sites in your care for income and services. Thus you want to avoid using auto-update so that it does not impact your revenue or that of your clients.
  • You are actively maintaining each WordPress site and have the resources to do so. You already update WordPress core, plugins and themes as soon as is practicable.
  • User impact is costly. Website users may experience issues making purchases or signing up for services.

Enterprise Auto-Update OFF

Enterprise

You have staging servers, development servers, and you perform code reviews on new plugins to look for potential vulnerabilities introduced in all updates before deploying. Nothing ends up on production servers without being rigorously tested by a stellar QA team. Your processes are built for 24/7 availability and you have the resources and team to power them.

As an enterprise user, we recommend you do not use unattended auto-updates in the current implementation.

Why?

  • The risk is at its highest as your WordPress site is mission critical.
  • Your QA team rapidly evaluates and tests new plugin releases in your staging environment. Auto-updates would remove this step.
  • Your operations team rapidly deploys well tested code into production using attended updates. Auto-updates would remove this process.
  • The business impact of a website disruption is extreme. Customers may experience issues making purchases, signing up for services, or accessing your content and resources.

How to Begin Using Auto-Updates

Regardless of which persona you are, we recommend holding off on enabling auto-updates until a few weeks or months after WordPress 5.5 has been released. As with any major change to software, bugs or issues may be found and patched in the next few weeks. We recommend waiting to ensure that auto-updates in WordPress 5.5 has time to undergo rigorous real-world testing before enabling auto-updates.

Even with auto-updates on, we still recommend regular backups for your site. We also recommend using a service such as Website Pulse or StatusCake to monitor your site availability.

The Future of Auto-Updates

WordPress 5.5 is a preliminary implementation of auto-updates, and is useful for a subset of sites. We do expect continued development of auto-update tools, perhaps even with the addition of beta, alpha, and canary releases to add more functionality and reliability to the auto-update process.

We hope that this discussion has provided insight into the new auto-updates feature in WordPress 5.5 and will guide you to making an informed decision. As always, you are welcome to post questions and comments below.

Thank you to Chloe Chamberland, Ram Gall, Matt Rusnak and Kathy Zant for their research and contributions to this post.

The post WordPress Auto-Updates: What do you have to lose? appeared first on Wordfence.

Read More

Improper Access Controls in GDPR Cookie Consent Plugin

Description: Improper Access Controls
Affected Plugin: GDPR Cookie Consent
Affected Versions: <= 1.8.2
CVSS Score: 9.0 (Critical)
CVSS Vector:
CVSS:3.0/AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:H
Patched Version: 1.8.3

The following post describes how improper access controls lead to a stored cross-site scripting vulnerability in the GDPR Cookie Consent plugin that emerged after it was removed from the repository. The Wordfence team released a firewall rule to our Premium customers on February 10th.

To help create awareness of this issue, we are disclosing details of this vulnerability today, now that a fix has been released and users who do not use Wordfence Premium have a clear upgrade path. A technical description of the vulnerability in the “GDPR Cookie Consent” plugin follows.

GDPR Cookie Consent is a plugin providing site owners with the functionality to present an unintrusive modal to allow end users of the site to review and consent to receiving that site’s cookies. It’s useful for sites looking to be in compliance with EU GDPR/Cookie Law regulations. GDPR Cookie Consent currently has 700,000 active installs.

Earlier this week, the GDPR Cookie Consent plugin was closed “pending a full review” according to the plugin’s page in the directory. Normally when plugins are closed in the WordPress plugins directory without a clear reason, plugin users can be concerned or confused. Because plugins can often be closed due to security issues, we decided to investigate to see if this was the case. The development log showed the most recent revision with the log message “1.8.3 – PHP 7.4 compatibility – Security fix”, so we decided to dig further into the code changes to determine its severity to protect Wordfence users.

There were a number of code changes, but those relevant to security include a capabilities check added to an AJAX endpoint used in the plugin’s administration pages.

Because the AJAX endpoint was intended to only be accessible to administrators, the vulnerability allows subscriber-level users to perform a number of actions that can compromise the site’s security.

There are 3 actions that the vulnerability exposes to subscribers: get_policy_pageid, autosave_contant_data, and save_contentdata.

get_policy_pageid does not do much other than return the post ID of the plugin’s configured cookie policy page. There isn’t much risk with having this action available to subscribers.

autosave_contant_data is intended to define the default content that appears in the cookie policy preview page. The stored HTML content is unfiltered and can contain cross-site scripting (XSS) payloads. The cookie policy preview page is publicly accessible to all users, and these XSS payloads will be executed when visiting http://<wordpress-site>/cli-policy-preview/.

save_contentdata is designed to create or update update the corresponding post used as the GDPR Cookie Policy page that end users of the site would view to choose whether to accept cookies from the site. The action takes a page_id parameter along with a content_data parameter which contains the post content. The page_id parameter allows the attacker to update the post content of any post. Additionally, it will set the post status to draft, so attackers looking to use this vulnerability for defacement won’t be able to display the post content to normal end users of the site. It could potentially be used to remove posts and pages from the public-facing portion of the site though.

Since the post is in draft status, the post content will be visible to the post author, editors, and administrators. By default, when wp_insert_post is used for creating and updating posts, the post content is run through wp_filter_post_kses which is WordPress’s HTML whitelist. It’s designed to only allow specific HTML tags and attributes, and will strip out XSS payloads.

Because the post content can contain shortcodes, an attacker can however use GDPR Cookie Consent’s built-in shortcodes to bypass the KSES filter. These shortcodes are parsed when viewing the rendered post in the browser. Here’s an example shortcode that can included in the post content that will render a valid XSS payload in the browser when viewing the post:

[cookie_accept colour='" onmousemove=alert(/xss/);this.onmousemove=null; style="position:fixed;top:0;right:0;bottom:0;left:0;" test="']

Because the post itself will no longer be public on the site (since the post status has been changed to draft) the XSS payload can only be executed by authors, editors, and administrators who view the post.

Timeline

  • February 8, 2020 – GDPR Cookie Consent plugin is removed from the wordpress.org plugin directory.
  • February 10, 2020 8:02 AM UTC – A patch fixing the vulnerability is pushed to plugins.svn.wordpress.org.
  • February 10, 2020 6:37 PM UTC – We deploy a firewall rule to provide protection against this vulnerability to our Threat Defense Feed.
  • February 11, 2020 10:00 PM UTC – GDPR Cookie Consent is re-opened in the plugin directory with the patched version available for download.
  • March 11, 2020 – Wordfence users still using the free version receive the firewall rule to protect their site.

Conclusion

In today’s post, we detailed how a missing capabilities check can lead to stored cross-site scripting in the GDPR Cookie Consent plugin. This vulnerability has been fixed in version 1.8.3. We recommend that users immediately update to the latest version available. Sites running Wordfence Premium have been protected from attacks against this vulnerability since February 10th. Sites running the free version of Wordfence receive the firewall rule update on March 11th, 2020.

Additionally, the generic XSS protection built into our WAF blocked the XSS payloads sent to all AJAX endpoints tested with this vulnerability. This XSS protection is provided out of the box with the Wordfence WAF, and has been available all along to both premium and free users.

Special thanks to Matt Rusnak and Ryan Britton for handling the initial investigation into this vulnerability.

The post Improper Access Controls in GDPR Cookie Consent Plugin appeared first on Wordfence.

Read More

Critical Authentication Bypass Vulnerability in InfiniteWP Client Plugin

Description: Authentication Bypass
Affected Plugin: InfiniteWP Client
Affected Versions: < 1.9.4.5
CVSS Score: 9.8 (Critical)
CVSS Vector: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Patched Version: 1.9.4.5

A vulnerability has been discovered in the InfiniteWP Client plugin versions 1.9.4.4 or earlier. InfiniteWP Client is a plugin that, when installed on a WordPress site, allows a site owner to manage unlimited WordPress sites from their own server. InfiniteWP Client is currently installed on over 300,000 WordPress sites.

This is a critical authentication bypass vulnerability. A proof of concept was published this morning, January 14, 2020. If you are using InfiniteWP client version 1.9.4.4 or earlier we recommend immediately updating your installation to protect your site.

How the InfiniteWP Client Works

The InfiniteWP Client plugin works by allowing a central management server to authenticate to the WordPress installation so that site owners can manage the site. From a central location, site owners can perform maintenance such as one-click updates for core, plugins, and themes across all sites, backup and site restores, and activating/deactivating plugins and themes on multiple sites simultaneously. The InfiniteWP Client plugin authenticates the central management server to each WordPress installation.

The InfiniteWP Authentication Bypass

The vulnerability disclosed last week is an authentication bypass vulnerability, which could allow an attacker to use the authentication logic in the InfiniteWP Client plugin to authenticate and access the WordPress installation with InfiniteWP installed. An attacker would not need the InfiniteWP server installed to exploit this vulnerability; they could simply craft a request addressing the InfiniteWP logic to log in as any administrative user if they know the username.

Update to Wordfence

Normally the Wordfence threat intelligence team would create a firewall rule and deploy it to existing Wordfence installations. Due to the complexity and severity of this vulnerability, we had to integrate protection for this vulnerability into the Wordfence code base, which required us to release a new version of Wordfence.

On Monday, January 13, 2020, we released Wordfence version 7.4.3, which includes protection against the InfiniteWP Client authentication bypass vulnerability.

Technical Details

Here’s a basic proof of concept request which exploits the vulnerability.

POST / HTTP/1.1
Host: example.org
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:72.0) Gecko/20100101 Firefox/72.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: close
Upgrade-Insecure-Requests: 1
Cache-Control: max-age=0
Content-Type: text/plain
Content-Length: 93

_IWP_JSON_PREFIX_eyJpd3BfYWN0aW9uIjoiYWRkX3NpdGUiLCJwYXJhbXMiOnsidXNlcm5hbWUiOiJhZG1pbiJ9fQ==

The body of the request decodes to {"iwp_action":"add_site","params":{"username":"admin"}} which instructs the InfiniteWP client to run the add_site action, and also to login as the admin user. It requires no authentication and is relatively easy to exploit.

When a site is initially setup using InfiniteWP client, it needs to connect to the InfiniteWP server software. The InfiniteWP server sends a request to the InfiniteWP client and passes on a public key. The InfiniteWP server has the corresponding private key which is used to sign requests. Subsequent requests from the InfiniteWP server to the InfiniteWP client can be authenticated by the site by verifying the signature using the public key. The initial request from the InfiniteWP server uses one of two actions, add_site or readd_site. By design, these actions are unauthenticated (since we don’t yet have a public key). Unfortunately, the code is structured so that some features can still be used. In this case, InfiniteWP client provides a feature to automatically login as an administrator without supplying a password.

When a site is initially connected to the InfiniteWP server, the request made by InfiniteWP server to the site actually exploits this vulnerability (unintentionally). This mades it quite difficult to write a WAF rule to protect against this vulnerability since legitimate and malicious requests can be identical.

We opted to integrate protection for this vulnerability into Wordfence. From within Wordfence, we can determine if the site is already connected to an InfiniteWP server, and prevent the vulnerable code from running if either the add_site or readd_site actions are passed to InfiniteWP client.

So far, we have not seen evidence of this vulnerability being exploited in the wild, but we expect to see attempts in the near future.

Non-WordPress Firewalls Ineffective

As an additional note, the fix we have implemented for this vulnerability required tight integration with WordPress. Wordfence runs as a WordPress plugin and is therefore able to implement this kind of fix.

As a firewall vendor, our goal is to minimize false positives while blocking attacks. We don’t want to accidentally block legitimate traffic. Due to the nature of this vulnerability, it is extremely difficult to create a firewall rule that blocks attacks AND eliminates false positives for this vulnerability, without tight integration with the WordPress API.

We are bringing this to your attention because if you are using a cloud based WAF that does not tightly integrate with WordPress, you may not be protected against this vulnerability. Your cloud WAF does not have access to the WordPress API to implement this kind of fix.

Protection for All Users

Normally, we would release a firewall rule to as a part of our Threat Defense Feed which is deployed in real-time to our Wordfence Premium customers, and to the free community version of Wordfence within 30 days. Because protection for this vulnerability required code changes within Wordfence, we’ve opted to make it available to all users immediately.

Our recommendation at this time is to update your InfiniteWP Client plugin as soon as possible to version 1.9.4.5. Updating Wordfence to version 7.4.3 on sites using InfiniteWP Client will provide concurrent protection.

Thank you to Matt Rusnak and Ramuel Gall for contributing to this update.

The post Critical Authentication Bypass Vulnerability in InfiniteWP Client Plugin appeared first on Wordfence.

Read More

Stored XSS Patched in SyntaxHighlighter Evolved Plugin

Description: Stored XSS
CVSS Severity Score: 5.4 (Medium)
CVSS Vector: CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:N
Affected Software: SyntaxHighlighter Evolved
Plugin Slug: syntaxhighlighter
Affected Version: 3.5.0
Patched Version: 3.5.1

While doing a security audit of the plugins and themes we run on wordfence.com, I discovered a stored XSS vulnerability in SyntaxHighlighter Evolved. SyntaxHighlighter Evolved currently has around 40,000+ active installations. We use SyntaxHighlighter here at Wordfence for code samples within blog posts.

SyntaxHighlighter will, by default, create links for URLs within the shortcode body. The URL regex is loose enough where a javascript:// psuedo-protocol can be used to execute JavaScript when clicked. SyntaxHighlighter will process shortcodes in post comments, so an unauthenticated user can submit shortcodes containing an XSS payload. The XSS payload is then rendered within the comments section of the post, and the comments moderation page in WP Admin.

Proof of Concept:

[code]javascript://%0dalert%28document.cookie%29[/code]

This creates a link with the javascript: pseudo-protocol that can be used to execute arbitrary JavaScript when clicked. The vulnerability is actually with the regular expression used to match and auto-link URLs within the code block:

/&lt;\w+:\/\/[\w-.\/?%&=@:;]*&gt;|\w+:\/\/[\w-.\/?%&=@:;]*/g

The \w+ character class part of \w+:\/\/ is too loose and will create links with javascript:, data:, etc. The stored XSS payload when submitted through comments will be rendered in both the comments section of a post, and within the comments moderation section of the WordPress admin panel.

*.wordpress.com Sites Also Affected

I noticed Automattic listed as a contributor to SyntaxHighlighter. I decided to see if SyntaxHighlighter was one of the plugins covered under Automattic’s bug bounty program. It wasn’t in the list, so I checked to see if they were using SyntaxHighlighter on wordpress.com. They do, in fact, use it to render code blocks within comments for sites hosted with wordpress.com.

I submitted the vulnerability report to Automattic through HackerOne. Automattic triaged the report and deployed a fix to wordpress.com within 2 hours of the initial report. Version 3.5.1 of SyntaxHighlighter was released 4 days following the initial report. Automattic awarded a $300 bounty with a $50 bonus for the report.

Bounty Donated to OHSU in Memory of Alex Mills

The original developer of SyntaxHighlighter was a WordPress developer named Alex Mills. Sadly, he passed away earlier this year from leukemia. He worked for Automattic and was quite a prolific member of the WordPress community.

I decided to donate the bounty from Automattic to Oregon Health and Science University (OHSU) in memory of Alex Mills. OHSU played a key role in Alex’s care when undergoing treatment. You can read more about OHSU and about Alex on his blog.

Disclosure Timeline

  • October 4th, 2019 10:16am EDT – Vulnerability report sent to Automattic via HackerOne.
  • October 4th, 2019 12:05pm EDT – Automattic deploys fix to *.wordpress.com sites.
  • October 8th, 2019 – Automattic releases version 3.5.1 of SyntaxHighlighter.
  • October 9th, 2019 – Bounty awarded by Automattic and donated to OHSU.
  • October 21st, 2019 – Report (#707720) disclosed on HackerOne.

Conclusion

SyntaxHighlighter Evolved <= 3.5.0 contains a stored XSS vulnerability via specially crafted comments. The vulnerability was fixed in 3.5.1, and it is recommended that you update as soon as possible. This vulnerability is covered by our generic XSS firewall rule, so Wordfence users have been protected from this vulnerability all along.

The post Stored XSS Patched in SyntaxHighlighter Evolved Plugin appeared first on Wordfence.

Read More

Wordfence Now Works on WP Engine and with Load Balancers

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

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

WP Engine’s File System Locking

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

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

Load Balancers are now supported

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

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

Wordfence MySQL Storage Engine FAQ

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

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

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

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

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

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

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

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

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

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

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

The post Wordfence Now Works on WP Engine and with Load Balancers appeared first on Wordfence.

Read More

Details of an Additional File Deletion Vulnerability – Patched in WordPress 4.9.7

Today WordPress released version 4.9.7, a security release which addresses two separate arbitrary file deletion vulnerabilities requiring Author privileges. Some details can be found on the WordPress.org blog.

This post is Copyright 2018 Defiant, Inc. and was published on the wordfence.com official blog. Republication of this post without permission is prohibited. You can find this post at: https://www.wordfence.com/blog/2018/07/details-of-an-additional-file-deletion-vulnerability-patched-in-wordpress-4-9-7/

The first arbitrary file deletion vulnerability was disclosed June 26, 2018 on the RIPS Tech blog with no official patch to WordPress in place. We released a firewall rule the same day to protect Wordfence users from attacks against this vulnerability.

A Second Vulnerability Discovered

After developing a proof of concept of the attack to aid in writing the Wordfence firewall rule, we decided to have a closer look at the code used to create and delete attachments. During this review, we discovered a second arbitrary file deletion vulnerability exploitable by authors. We released a Wordfence firewall rule to our Premium customers on July 2nd to protect against this vulnerability.

The details of the second vulnerability are as follows: In WordPress core, there is an “upload-attachment” AJAX action used by the media uploader. The AJAX call will handle the file upload and pass an array of additional data about the attachment to wp_insert_post, since media attachments are a specific post type within WordPress.

function wp_ajax_upload_attachment() {
    
    ...
    
    // Post data from user input.
	$post_data = isset( $_REQUEST['post_data'] ) ? $_REQUEST['post_data'] : array();

	// If the context is custom header or background, make sure the uploaded file is an image.
	if ( isset( $post_data['context'] ) && in_array( $post_data['context'], array( 'custom-header', 'custom-background' ) ) ) {
		$wp_filetype = wp_check_filetype_and_ext( $_FILES['async-upload']['tmp_name'], $_FILES['async-upload']['name'] );
        
        ...
        
	}

	$attachment_id = media_handle_upload( 'async-upload', $post_id, $post_data );

The vulnerability lies in the way wp_insert_post populates the meta data for the attachment. The path to the attachment file is stored in the meta key _wp_attached_file. By supplying post_data[meta_input][_wp_attached_file] in the request to the “upload-attachment” AJAX action, we can pass in ../../wp-config.php which WordPress will treat as the attachment file.

Similar to the first arbitrary file deletion vulnerability, when an author deletes this attachment, the wp-config.php is deleted allowing the author to go through the initial WordPress installation process which allows them to fully compromise the site.

WordPress Releases a Fix in 4.9.7

The WordPress security team has just released version 4.9.7 which addresses both of these issues by performing some additional checks before deleting attachment files. Specifically, they have added the function wp_delete_file_from_directory which they use to verify the file is within the uploads directory before deleting it.

/**
 * Deletes a file if its path is within the given directory.
 *
 * @since 4.9.7
 *
 * @param string $file      Absolute path to the file to delete.
 * @param string $directory Absolute path to a directory.
 * @return bool True on success, false on failure.
 */
function wp_delete_file_from_directory( $file, $directory ) {
	$real_file = realpath( wp_normalize_path( $file ) );
	$real_directory = realpath( wp_normalize_path( $directory ) );

	if ( false === $real_file || false === $real_directory || strpos( wp_normalize_path( $real_file ), trailingslashit( wp_normalize_path( $real_directory ) ) ) !== 0 ) {
		return false;
	}

	wp_delete_file( $file );

	return true;
}

Timeline

  • 2018-06-29 11:26 AM (-500) – Initial report of second arbitrary file deletion vulnerability submitted to WordPress security team.
  • 2018-07-02 1:14 PM (-500) – Firewall rule released to Wordfence Premium customers to address second vulnerability.
  • 2018-07-05 12:00 PM (-500) – WordPress releases version 4.9.7 which fixes both vulnerabilities.

What To Do

We strongly encourage you to update to 4.9.7 as soon as possible. If you have automatic updates enabled, your site should update within the next 24 hours. Automatic updates are enabled by default in WordPress for minor releases.

Credits: Congrats to Matt Barry, our lead developer at Wordfence for finding this vulnerability and writing up technical details. Thanks to Mikey Veenstra for editing this post. As always, thanks to the WordPress security team for being super responsive and for their hard work helping secure WordPress core.

The post Details of an Additional File Deletion Vulnerability – Patched in WordPress 4.9.7 appeared first on Wordfence.

Read More

Wordfence Now Includes 1.4 Billion Leaked Passwords in Password Auditing Feature

Last week, we reported a massive upsurge in brute force login attempts following the leak of a database of 1.4 billion clear text credentials. No one had seen 14% of the exposed username/password pairs before, making this a ripe opportunity for hackers to attempt to break into WordPress sites.

Historically, brute force attacks targeting WordPress have not been very successful. But this new database provides fresh credentials that, when matched with a WordPress username, may provide a higher success rate for attackers targeting sites that do not have any protection.

Password Auditing Improvements

Wordfence Premium includes a powerful Password Auditing feature. Using a GPU cracking cluster, we give you the ability to audit the strength of your admin and user passwords. You can learn more about how this feature helps protects your site here.

In response to this latest leak, we’ve merged this updated password list into our own large password list that we currently use to audit administrator accounts. Our previous list contained 269 million known passwords from various breaches, such as LinkedIn, and eHarmony. After merging and removing duplicates, this new list comes in at 609 million known passwords against which we can test your users’ passwords.

We ran some initial tests to compare how our previous list performed against the new list. In a random sampling of 100 user accounts, our previous list cracked 42% of the 100 password hashes. The current list cracks 57% when run against the same list. That’s a 36% increase over the previous capability. This means that a Wordfence password audit is now 36% more likely to find a weak password than before.

Recommendations

We strongly recommend that you upgrade to Wordfence Premium to benefit from the new capability we’ve added to our Password Auditing feature.

We also recommend you follow these additional steps:

  1. Install a firewall like Wordfence that intelligently blocks brute force attacks.
  2. Ensure that you have strong passwords on all user accounts, especially admin. Wordfence provides an option to enforce strong passwords when creating/updating a user account under “Login Security Options”.
  3. Change your admin username from the default ‘admin’ to something harder to guess.
  4. Delete any unused accounts, especially admin accounts that you don’t use. This reduces your attack surface.
  5. Enable two-factor authentication on all admin accounts. Wordfence Premium provides two-factor.
  6. Enable an IP blacklist to block IPs that are engaged in this attack. Wordfence Premium provides a real-time IP blacklist.
  7. Monitor login attempts by configuring alerts for when an admin signs in to your website. Wordfence (free version) provides this.
  8. Do not reuse a password on multiple services. That way, if you have a password from a data breach in this new database, it won’t be the same as your WordPress admin password. You can use a password manager like 1password to manage many passwords across services.

The post Wordfence Now Includes 1.4 Billion Leaked Passwords in Password Auditing Feature appeared first on Wordfence.

Read More
Page 1 of 212»