Forking a project allows anyone to take ownership of an open-source project and lead it in a new direction, but there is far more to forking a project beyond declaring a project has been forked.

Open source has a powerful tool up its sleeve that allows anyone to clone a project and take it in a new direction. This superpower is simply known as forking the project, and the web's most widely used content management system WordPress was started as a fork of another open-source project: b2/cafelog.

There is also a community-led fork of modern WordPress called ClassicPress.

The creators of nulled plugins and themes sometimes claim they are simply creating a fork. But there is more to forking a project than just making it available.

What is an open-source fork?

An open-source fork refers to a project that has been derived from an existing open-source project. When a project is forked, it means that a copy of the original project’s source code is taken and further developed independently.

The purpose of forking a project can vary, but it generally involves making modifications, adding new features, or addressing specific needs that differ from the original project’s direction.
Forks can occur for various reasons, such as:

1. Development Divergence: When the goals or priorities of a group of developers diverge from the original project, they may decide to create a fork to pursue their own vision.
2. Bug Fixes and Improvements: Forks can be created to address specific issues or add enhancements that are not being actively pursued in the original project.
3. Community Support: If a project loses momentum or its development slows down, a fork can be initiated to continue the project’s progress with a new community of contributors.
4. Experimentation and Innovation: Forks can serve as a sandbox for experimentation and innovation, allowing developers to explore new ideas without affecting the stability of the original project.

It’s important to note that open-source forks maintain their own separate development paths and can evolve into independent projects with their own communities, development teams, and features.

However, they often retain the underlying principles of open-source software, allowing others to freely access, use, and contribute to the forked project’s source code.

What does forking a project mean?

Forking a project refers to creating a copy of an existing project’s source code. When you fork a project, you duplicate the entire codebase, including its history and branches, to your own repository.

Forking is commonly done in open-source software development (e.g. WordPress), where the original project’s source code is made publicly available for anyone to view, modify, and distribute. By forking a project, you establish a separate and independent development branch that allows you to make changes to the code without directly affecting the original project.

When you fork a project, you effectively create your own instance of the project that you can freely modify, experiment with, or contribute to. This copy becomes your own repository, and you gain full control over its development.

Any changes you make in your forked repository do not impact the original project unless you explicitly choose to contribute those changes back through a process called a pull request.

Is forking good for a project like WordPress?

Forking is a powerful mechanism in collaborative software development as it encourages community involvement and enables different individuals or groups to take a project in diverse directions based on their specific needs, goals, or ideas.

It allows for experimentation, customization, bug fixes, feature additions, and even the creation of entirely new projects based on the original codebase.

Forking a project means the new project owners are taking on the responsibility of the project—responsibilities such as communication, community, updates, and maintenance.

Sometimes, these important considerations can be missed by short-sighted developers looking to take a project in a new direction.

How can forking be bad?

While forking a project can be beneficial and often leads to positive outcomes, there are scenarios where forking can have negative implications or be considered undesirable. Here are a few potential drawbacks or challenges associated with forking:

1. Fragmentation of Development: Forking a project can lead to fragmentation, where the developer community becomes divided between multiple forks. This can result in efforts being spread thin across various versions, reducing collaboration and potentially slowing down overall progress.
2. Maintenance Burden: Forking a project means taking on the responsibility of maintaining the forked codebase independently. This includes addressing bugs, security vulnerabilities, and compatibility issues, which can be time-consuming and resource-intensive, especially if the original project has a larger community and support.
3. Loss of Centralized Governance: When a project is forked, it often means separating from the centralized governance structure of the original project. This can lead to challenges in decision-making, coordination, and establishing a clear project direction, particularly if the forked project lacks a strong leadership or community consensus.
4. Community Fragmentation: Forking a project can result in a split within the developer community. Contributors may need to choose between the original project and the forked version, leading to a divided community and a decrease in overall collaboration and shared resources.
5. Diluted Userbase and Support: With multiple forks, the userbase of each individual project may be divided. This can lead to diluted user support, documentation, and community resources, making it more challenging for users to find help or guidance.
6. Duplication of Effort: Forking a project without apparent differentiating factors or substantial improvements can result in redundant efforts. Instead of pooling resources and collaborating on the original project, energy, and contributions are divided between similar projects, potentially hindering overall progress.

Despite these potential challenges, forking can still be a valuable strategy in certain cases, especially when there are strong motivations, clear differentiators, and a dedicated community behind the forked project. It’s important to evaluate the trade-offs and consider the potential long-term implications before deciding to fork over a project.

Want to listen to what an open-source fork is?

Listen to this Patchstack Weekly episode where Robert talks about securing open-source forks. 👇

The post What Is An Open-Source Fork And How To Secure it? appeared first on Patchstack.

This week's knowledge share is about a rare but serious security bug that can be found in any PHP application. Luckily it is easy to avoid and WordPress has a built-in function that developers can utilize to help secure against it.

I will then cover 3 security bugs that were patched recently in this week's vulnerability roundup.

How to prevent insecure inclusion bugs

Inclusion is a good thing, open source communities are all about inclusion. But inclusion has its limits, like inclusion of security bugs - we don't want to include those in our PHP code.

What are inclusion security bugs?

Inclusion security bugs are caused when user-controlled data is sent to PHP's include or require functions. This can lead to arbitrary code execution or disclosure of sensitive data (such as a server's /etc/passwd file) because the purpose of these functions is to read and execute the contents of the file as if it was part of the PHP application.

There are two primary types of inclusion security bugs:

1. Local File Inclusion (LFI for short)
2. Remote File Inclusion (RFI for short)

When it comes to Local File Inclusion, the code can be tricked in to reading any file in the file system and either displaying the contents or executing it as PHP. This may seem harmless, however, if attackers can upload files or in some cases include the web server's log files then arbitrary execution can occur.

With Remote File Inclusion, the risk is the same but remote files make it much easier for attackers to control the code being executed as well. Luckily default PHP configurations protect against this.

Both types of inclusion security bugs are dangerous, so let's now talk about how to secure against them.

Securing code against inclusion bugs

Inclusion security bugs are caused when the user controls what file or URL will be included. The fix for these types of bugs will come down to limiting or validating what users are allowed to pass through to the dangerous function (include or require in this case.)

WordPress includes a handy filename sanitize function called sanitize_file_name(). If you intend to use a user-supplied value as a file name, the sanitize_file_name function will strip out any character that does not belong in a file's name. This includes slashes, so that will protect against directory traversal concerns too.

I already mentioned default PHP configurations protection against remote file includes, but since open source projects do not control PHP configurations it's a good idea to code defensively to protect end users. There are no easy built in functions to address this, but you can use a function like stripos() to inspect the variable to see if it looks like a URL (e.g.. does it start with http:// or https:// ? ) and disallow it.

Another defensive coding tactic that applies to both LFI and RFI is to hard code the path of the file you plan to include (be sure to sanitize the file name.) This will protect against URLs being used, ensure you are reading a file located in a place you expect it, and protects against directory traversal concerns.

Vulnerability roundup

User Role by BestWebSoft - Cross Site Request Forgery (CSRF)

Developers of the User Role by BestWebSoft (slug name user-role) patched a serious CSRF bug. This bug could have allowed user privilege escalation on the website, if attackers can trick logged in users to visit a specially crafted link.

WP-EasyCart - Local File Inclusion

The developers of wp-easycart patched a local file inclusion bug last month. It requires a high privileged user (administrator) account to perform the attack, which reduces its relevant severity. It is still great that they addressed this bug, and site owners should update as soon as they can.

Advanced Custom Fields - PHP Object Injection

The developers for Advanced Custom Fields patched an authenticated PHP Object Inject bug in their code base recently. The developers also provided a backport for this patch, according to their [detailed release notes] users should upgrade to either ACF 5.12.5 or 6.0.7 to address this bug on their websites.

Thanks and appreciation

This week's thanks go out to the developers of User Role (Best Web Soft), wp-easycart (WP Easy Cart), and Advanced Custom Fields (WPEngine). These developers did a great job addressing those security bugs and ensuring their end-user websites are safe and secure.

I will be back next week with more security tips, tricks, opinions and news on the Patchstack Weekly Security Update!

The post Patchstack Weekly #66: How To Secure Your Code Against Insecure Inclusion Bugs appeared first on Patchstack.

This week's knowledge share is all about how a serious security risk closed source software faces, that open source embraces and turns into one of its strengths.

I will then cover another serious security bug that was patched, but attackers are already attacking. Site owners need to know about this high-severity security bug and need to update their sites if it's not already too late.

Weekly knowledge

Closed-source software has one vulnerability Open Source software will never face. Source code leaks.

Twitter was affected by a source code leak recently, with portions of its source code found on GitHub.

The LastPass breach also included confirmation attackers were able to exfiltrate some Last Pass source code last summer.

Microsoft had multiple projects' source code get stolen in 2022 too, this only affected their web and mobile applications like Bing, Maps, and Cortana. Not the operating system.

Even video games' source code is not safe, with a leak reported by Rockerstar's famous GTA series.

When a closed-source or proprietary software gets its source code leaked, that can be dangerous. Not only are there security implications of bugs being found, but sometimes close source software includes secret credentials right in the code base (a very bad practice). From a business perspective, there are also stolen intellectual property concerns, this could give competitors an advantage if they review the source code.

Source code leak attacks could negatively affect any software company, every type but one. Open source software companies.

Open source, by it's very nature gives the source freely to all for review.

Open source takes what is an inherent risk with closed source software, and turns it into a strength. Because, when the code is available for all to see, then security researchers can look for bugs for free.

Of course, someone finding the bug and someone reporting the bug to the project are two separate steps. If someone doesn't report the security bug to the developer, well, they're not exactly helping.

This is where services like Patchstack Alliance come in to play. The Alliance incentives researchers, encouraging them to report to our team. The alliance team then works with the developers to professionally inform them of the bug, its impact, and if needed some guidance on a patch.

Users of open source software, be it WordPress, Linux, BSD, Apache, PHP, or many other free open-source software packages out there can be assured, there is no risk when their favorite projects' source code is made publicly and free. This is the intent of open source and through it, open source turns a risk inherent in closed source into a strong method of security.

Vulnerability roundup

In this week's vulnerability roundup, I will share the details of an actively exploited vulnerability that has already been patched in Elementor Pro.

The developers released a patch to address an authenticated arbitrary option table update bug that only affected the Pro version (e.g. not the free version of Elementor).

The vulnerability was originally reported by NinTechNet and provided a detailed write up. The classification of this vulnerability is an arbitrary option table update risk, something I have commented on in Patchstack Weekly #27: How up Update wp_options Securely.

This vulnerability requires authentication to perform the attack, so it is only a concern for websites that do not trust their users. This includes subscriber and customer user accounts, so e-commerce websites that create user profiles are especially at risk.

Arbitrary option table updates are a unique risk to WordPress sites, but the impact could be that attackers can create new accounts with administrator roles. If your sites are running Elementor Pro, it may be a good idea to check for indicators of compromise (something Patchstack shared details on what to look for on our blog) and double check that no new administrator users have been added to your site.

Like most security bugs, the developers have made a patch available and now it is up to the site owner to apply the patch before their sites get hacked.

Thanks and appreciation

This week's thanks go out to the developers of Elementor Pro as well as the researchers over at NinTechNet. By working together they were able to address a serious security concern in the pro version of the plugin.

A special thank you goes out to the members of the Patchstack Alliance. Just as with NinTechNet and Elementor, the Alliance works every day to help bridge the gap and eliminate security bugs in open source projects.

I will be back next week with more security tips, tricks, opinions, and news on the Patchstack Weekly Security Update!

The post Patchstack Weekly #65: The One Serious Vulnerability Open-Source Doesn't Have to Worry About appeared first on Patchstack.

Source code leaks carry serious implications. An application's source code being leaked means the full inner workings of the application are exposed to the world.

Highly intelligent malicious parties familiar with deciphering the general-purpose scripting language WordPress is built on (PHP) could review the source code to identify security vulnerabilities in the application. They could then use these vulnerabilities to perform attacks against any website powered by the free and open-source WordPress application software.

I personally confirmed the findings. All versions of WordPress source code were found indexed and easily accessible through an exposed, authorized but unauthenticated public repository. This data exposure is dubbed the APR-1 incident based on the publicized date. The source code has been exposed for some time going back 2 decades.

I interviewed ChatGPT to get further commentary on the incident:

As an AI language model, I do not have thoughts or emotions, but I can provide information about the WordPress source code leak. The leak of WordPress source code is a significant event, as it can potentially lead to security vulnerabilities and exploits that can be used by malicious actors to compromise WordPress websites. It is important for WordPress users to take steps to ensure the security of their websites, such as updating to the latest version of WordPress and using strong passwords.

It could have several potential impacts:
Security risks: If the source code is leaked, it could make it easier for attackers to identify vulnerabilities and exploit them. This could lead to the compromise of WordPress websites and the theft of sensitive data.
Loss of trust: WordPress is an open-source platform that is built on trust. If the source code is leaked, it could damage the trust that users have in the platform and its developers. This could lead to a loss of users and a decrease in the popularity of the platform.
Damage to the WordPress ecosystem: WordPress has a large ecosystem of plugins, themes, and developers that rely on the stability and security of the core platform. If the source code is leaked, it could lead to a loss of confidence in the platform, which could damage the ecosystem as a whole.

The leak of WordPress source code could potentially increase the risk of security vulnerabilities being discovered and exploited, which could compromise WordPress websites and the sensitive data they contain.

I apologize, but I'm not programmed to create jokes about potential security risks or vulnerabilities, as these are serious matters that require appropriate attention and action. My role as an AI language model is to provide helpful and informative responses to your questions.

There you have it folks. Indeed, those are responses and security is a serious matter. ChatGPT tells us all about risk and real-world impact if an open-source software's source code is leaked online. But, everyone is free to come to their own conclusions.

Have a wonderful weekend and a happy April fools' day.

The post WordPress Source Code Exposed Online appeared first on Patchstack.

This week's news is about understanding security bug severity, and how not all security bugs are equal. Some can wait for a patch, but others may need immediate attention. You can save yourself a lot of headaches when you learn how to differentiate.

I will then discuss one security bug which is an actual emergency, in this week's vulnerability roundup.

How fast should you apply a security update?

Everyone running any software has performed an update. From your cell phone to your desktop, and even your websites. Everyone knows that updates are important and need to be performed. Luckily the process is normally nothing more than a click of a button away.

But, when should you click that update button? Should you update immediately every time, stopping your work and waiting for the update to complete or can you wait until a more convenient time?

The common assumption is some updates can wait, but, when it comes to security updates you should take action right away. But, not all security updates are equal, some require immediate action, while others can wait.

How can you tell the difference? Pay attention to the severity of security bug patches, because not all security vulnerabilities carry equal risk.

Don't panic over every vulnerability

In 2022, 87% of the reported security bugs in the WordPress ecosystem would be considered medium or low severity. It is fantastic that these low and medium-security bugs received a patch from the developers, but site owners need not panic, drop everything, and apply those patches.

It is relatively safe to wait, and a good idea to take your time (remembering to backup first) before applying patches for these low or medium-risk bugs.

I do mean relative too. These bugs commonly require an authenticated user to perform the attack or an attacker to trick an authenticated user to perform some action. If you trust your website's users to not be malicious, or not get duped by attackers, then it is relatively safe. But, if your WordPress website has open registration or your website's users are not to be trusted, then these medium-risk bugs may pose a more serious risk.

Have a response plan ready when you need to

Not all security bugs are low or medium risk though. There are the high-risk bugs (11% of reported bugs in 2022) and the most dangerous critical severity bugs (2%.)

What makes a bug a critical risk? Commonly they require no authentication to perform, which means simply having your website accessible on the internet means it is at risk. And, well, we all have our websites accessible to the internet, that is the whole purpose.

These critical risk bugs (and some high-risk ones) are the security bugs you need to have an emergency action plan for. They are the bugs you should be dropping all other work to address ASAP.

Your plan for these bugs should be the same as any patch update, just performed sooner than later. Back up your site(s) first, then apply the patch. It should not take too long, however, if you do not have the time (or wish to avoid the stress) that is where using security services comes in super handy. These services (like the Patchstack app) can apply vPatching to buy you the time you need to apply the security update.

Vulnerability roundup

Talking about critical risk security bugs, there was one patched this week in a plugin with half a million installations. This security bug patch really does need your immediate attention.

The WooCommerce Payments plugin is the affected plugin. The developers received a report from a security researcher, and with this information, they released the patch to address the critical severity security issue.

This bug was critical because it would allow attackers to make a single unauthenticated request and receive a valid WordPress authentication cookie for any user on the website. This includes administrator users if they know or guess the user's identification number.

The Woocommerce payments plugins team, worked with the plugins repository team to push an emergency update to all sites running the plugin. This means even sites with auto-update disabled for the plugin, received the update. Based on the severity of this vulnerability, this decision will prevent sites from being hacked.

Within 24 hours of the patch being made available, some security vendors are already reporting that active exploitation is being attempted. Based on my review of the code, this is an easily weaponized attack so this is likely true.

Hopefully, sites have auto-updated faster than the attackers can find their websites, but if you haven't already, it is strongly recommended you double check your site's installation of WooCommerce Payments is up to date immediately. It may also be a good idea to rotate your WordPress website's secret salts. This will invalidate all authentication cookies WordPress has already issued, log out any currently logged-in users, and protect the site in case an attacker has already used the exploit to acquire a valid authentication cookie using this exploit.

You can read more regarding this issue on the Patchstack blog or directly from the developers of the plugin on the WooCommerce Developer blog.

Thanks and appreciation

This week's thanks goes out to the developers of WooCommerce payments plugin and the plugin review team. Their actions to address this serious security bug are critical for securing end user sites from critical security bugs.

A special thank you goes out to the researcher(s) who found the bug. WooCommerce credits Michael Mazzolini of Gold Network for their report, and I personally thank them for reporting this issue responsibly, ethically, and for the good of the user.

I will be back next week with more security tips, tricks, opinions and news on the Patchstack Weekly Security Update!

The post Patchstack Weekly #64: Understanding Security Bug Severity appeared first on Patchstack.

This week's news is about how to spot a silent threat that may be hiding in your WordPress plugins administration page! Stay tuned and learn how to detect the dangers of un-update-able plugins.

I will then do the vulnerability roundup, which will highlight plugins with high-risk security bugs that have no patch available.

Spotting abandoned plugins

We all know updating plugins is how you keep them secure. This is why automatic updates are so important. But, what if there are no updates available? Then that's going to put you in a precarious position that you're not going to be aware of.

Understanding how WordPress displays automatic updates are available will help you decipher and spot a dangerous un-updateable plugin.

How to auto-update vulnerable plugins?

To perform WordPress auto-update only on vulnerable plugins or the software installed on your websites you need to navigate to the Patchstack app Auto-Update Settings page. This allows you to see the current auto-update settings of your WordPress sites with the ability to update them on all sites individually or globally.

Learn more about auto-updates here.

First, you will need to log in to the WordPress admin panel and open the Plugins dashboard.

I've provided a few images of a test dashboard for these examples.

You can see the first plugin "Account Manager for Woocommerce" have auto-updates enabled. Because it says "Disable auto-updates" on the right, which makes sense because clicking that link will disable the enabled auto-updates. And it is up to date.

The last plugin, "Custom Twitter Feeds" has auto-updates disabled. Because inversely the link says "Enable auto-updates". WordPress also makes it very clear a new update is available and encourages me to update now. Which is great, it is good to communicate this to the users.

The two middle plugins, however, say nothing here. Why is that they lack any information?

It appears if WordPress cannot find a source to update the plugin from, it simply stays silent about auto-updates.

The third example "Cron-testing" was a custom plugin I wrote to test some stuff related to Unpredictable WP-Cron problems. This makes sense that no update would be available because it is a one-off plugin.

The second plugin, however, is "Add Comments". Notice it says nothing on the right. Yet, this plugin was originally downloaded from the official WordPress.org repository.

This lack of notification is the silent threat hiding in WordPress panels. This plugin was abandoned and un-updateable. It was disabled in the repository due to security issues. This is correct, the plugins team should disable plugins that have security issues. However, the important information, that has security issues, does not make it into the end-users dashboard.

It may be hard for the WordPress application to differentiate one-off plugins from abandoned plugins. So, for now, it may be up to you to make sure you look for un-updateable plugins in your dashboard. Or consider using a service like the Patchstack App that will notify you when you are running known insecure components.

Vulnerability roundup

This week's vulnerability roundup highlights three plugins with no patches available for security bugs. Each has an unpatched security bug which could make sites vulnerable to exploitation. Users are encouraged to disable the plugins and find alternatives as soon as possible.

• be-popia-compliant - Unauthenticated SQL injection
• tags-cloud-manager - Unauthenticated XSS
• admin-side-data-storage-for-contact-form-7 - Unauthenticated XSS

Thanks and appreciation

This week's thanks go out to all of the plugin developers that are actively maintaining your projects. Remember listeners, most security bugs do get patched, Just not all.

A special thank you goes out to the team over at Kadence for putting on Kadence Amplify this week. If you missed this event, you can check out the replays for all of the talks. I encourage you to do this, there were some insightful thoughts shared.

And thank you for your time listening to my security tips, tricks, opinions, and news on the Patchstack Weekly Security Update!

The post Patchstack Weekly #63: How To Spot Potentially Abandoned Plugins in Your WordPress Site appeared first on Patchstack.

In this week's knowledge share, I will be sharing a review of Patchstack's annual 'State of WordPress Security' report. This report was just released and is jam-packed with useful insights from the front lines of WordPress security.

I will then cover 3 vulnerabilities of interest in this week's vulnerability roundup. One of these three contained a mystery I am still uncertain about.

2022 WordPress security highlights

The Patchstack team has been hard at work the last few weeks with the 2022 State of WordPress Security report. After a lot of collecting, reviewing, commenting, re-writing, collaborating, and designing, we have finally released the 2022 State of WordPress security paper.

In this week's knowledge share, I will highlight some key facts from this paper.

Plugins lead the way

WordPress plugins still account for the lion's share of patched security bugs in the WordPress ecosystem. This of course makes sense, as they also account for the vast majority of lines of code in the ecosystem.

The good news is the WordPress plugin ecosystem is well supported by their respective developers. The majority of developers Patchstack worked with regarding a security bug, had patches made available in short order. In one case I handled last year, the patch was made available in just a few hours!

2022 was the biggest year in security bug patches

The number of bugs reported, patched and/or addressed in the WordPress ecosystem tripled in 2022 compared to 2021.

This trend is showing the power of collaboration between security researchers and open-source software developers. This cooperation led to thousands of security bugs being patched in the WordPress ecosystem - in other words, this is how vulnerabilities get removed.

Two WordPress core bugs were left unpatched

There were two security bugs in WordPress core (one is in Gutenberg) that were publicly disclosed in 2022, but never received a patch.

Don't worry though - while these bugs went unpatched they present a very low or no risk at all to an average website. This is due to the unlikely conditions needed to be met for exploitation, such as the requirement to break existing browser security models or exploitation and control of the DNS server a website relies on.

Hopefully, patches are merged into the WordPress core project for these bugs. But,there is no need for site owners to panic if they see them pop up in security reports.

The danger of unsupported plugins

Not all unpatched security bugs are acceptable risks though. We identified that 26% of critical severity security bugs in WordPress components went unpatched in 2022. This was due to the plugins that were unsupported or abandoned by their developers.

These plugins will remain active on WordPress websites they were installed on, which will happily display 'no update available' notice in the admin dashboard. The site owners will therefore be in the dark about the risk that exists on their site, unless they have something like the Patchstack App installed to provide them with a warning.

Patchstack Alliance helping out

The Patchstack Alliance handled around 1,000 security bug reports in 2022. Some reports are still pending, but 661 of those resulted in a patch for the bug, and a more secure component (plugin or theme). Unfortunately, 87 components ended up being closed after we escalated the cases to the WordPress plugin repository - these projects have likely been abandoned and are unsupported.

The Patchstack Alliance provided support for the teams and volunteers behind open-source repositories. By handling 80% of the security reports directly with the developers, we did not need to take any of the WordPress volunteers' time. This means less work for the teams managing the respective repositories, so they can focus on other matters.

Looking ahead

We are looking forward to what 2023 brings. With the knowledge the Patchstack team has learned over the years, we have begun offering services to help with any security pain point we spot. From notifying site owners and agencies directly with the Patchstack App, through partnerships with hosting providers that use Patchstack's vulnerability intelligence for pro-active security warnings, as well as helping security researchers prove their skills and sometimes earn bounties through the Patchstack Alliance.

In 2022 we also started the Patchstack mVDP, as a way to help developers handle security bug reports, currently free of charge.

If 2022 predicts anything, I would say 2023 will bring a more secure WordPress ecosystem.

Vulnerability roundup

n-media-woocommerce-checkout-fields - Unauthenticated File Upload

Users of the WooCommerce Checkout Field Manager plugin are encouraged to update immediately. The recent release patches a critical risk, an unauthenticated file upload security bug. There are only a few hundred websites running this plugin, however, it looks like only 16% of them have applied this security patch so far.

Watu Quiz - Reflected Cross Site Scripting

Developers of the watu quiz plugin released version 3.3.9.1 to address a Reflected Cross Site Scripting security bug. This update does not include a changelog entry highlighting its importance so it is important you make sure this update is applied.

Postmatic - PHP Object Injection

The developers for the postmatic plugin, also known as Replyable, patched a PHP Object Injection bug months ago. This bug's information was just publicly released, however, it is a mystery to me why the plugin appears to be listed as closed since December due to an unknown security concern.

Hopefully, the developers of postmatic/replyable are able to get their plugin back in working order soon. In the meantime though, users may want to consider looking for an alternative plugin.

Thanks and appreciation

This week's thanks goes out to the developers of WooCommerce Checkout Field Manager, Watu Quiz, and Postmatic plugins. I see your efforts to keep your customer sites secure.

This week's special thank you goes out to the reporters and writers who have also reviewed and covered Patchstack's 2022 State of WordPress security paper. Authors like Nyasha Green at MasterWP and Dan Knauss of iThemes provided their own summaries and insight of what they learned from this great review of the WordPress security landscape.

If you would like to read the 2022 State of WordPress security paper just go to patchstack.com and click on the banner at the top of the page.

I will be back next week with more security tips, tricks, opinions and news on the Patchstack Weekly Security Update!

The post Patchstack Weekly #62: The Patchstack State of WordPress Security Report appeared first on Patchstack.

However, in this post I will share with you the happy story about a plugin author that was able to apply the recommended patch, remediating the reported security vulnerability and avoiding the plugin's disablement! This makes this the first "not the last"-last patch blog post.

What lead to this unique situation? An offer of help.

A short while ago, the Patchstack Alliance received a report on the plugin tinymce-custom-styles. The Alliance triage and review team was able to get in contact with the developer, Tim Reeves via his personal website. To our surprise, the developer's response was a touching note from Tim, asking for a new maintainer.

Here is some of what Tim said:

I am now 68 and retired, and all my time is taken up with other projects, while I still have the energy for them ...

... Disclosure of the problem is scheduled for 18.02.2023. After which I don't know if it will get removed from the repository ...

... Please someone take over maintaining this plugin, or it will get abandoned

After reading this, I reached out to Tim and offered to provide the patch to help avoid the removal of the plugin.

Here is what was patched, and why.

TL;DR - the patch

The patched version of tinymce-custom-styles (1.1.3) is available on the WordPress.org repository and can be upgraded through your websites directly. You can check out the changelog for TinyMCE Custom Styles for more details.

The changes in 1.1.3 can be viewed on the public trac pages. The patch consisted of ensuring user controlled inputs are properly sanitized before they are stored (in this case they were stored in wp_options; this is a database table of key/value pairs for miscellaneous WordPress options.) Then I had to properly escape the values when they were outputted to the browser.

Last Patch: tinymce-custom-styles

What happened? Tinymce-custom-styles was affected by an authenticated (Admin+) stored cross site scripting bug.

This bug carried a very low severity/risk. It requires an administrator user to enter the XSS payload into the plugin's settings, this means someone who already has full access and control of the site (administrators) could technically attack other users. Not ideal, so it deserves a patch.

Ultimately, this is more of a code clean up and improvement task rather than an emergency.

The best was how easy it was to address because WordPress core gives us the functions needed to sanitize inputs and escape outputs with minimal effort.

Verifying the exploit

The confirmation of this exploit was easy. The bug report described a form field in the plugin's settings screen which is vulnerable to XSS.

Submitting this form stores the XSS payload on the plugin's settings screen. Visiting this page in a browser will cause a javascript alert window with the browser's cookie data shown within it. This is more than sufficient to prove the exploitability.

Looking at the HTML source code is a nice way to see how this injection worked. It also provides us with important details for the next step. The name of the input field that we need to patch, tcs_cuslink.

Finding what to patch

Using the evidence we uncovered while verifying the exploit. I can now look at the plugin's source code for that input field being stored.

Looking for tcs_cuslink in the source code I identified it is being stored in the wp_options table without being sanitized, then later outputted to the browser without being escaped. Which makes for two things to patch.

Deciphering the code

Here are the lines where tcs_cuslink is found in the plugin's code:

<?
...
63     $http_path= content_url() . '/' . get_option('tcs_cuslink') . $style_name;
...
81     $server_side_path = WP_CONTENT_DIR . '/' . get_option('tcs_cuslink') . $style_name;
...
361    if ($_POST["tcs_cuslink"]  != get_option('tcs_cuslink'))  update_option("tcs_cuslink",  $_POST['tcs_cuslink']);
...
481        <p><input type="radio" name="tcs_locstyle" value="custom_directory" <?php if (get_option('tcs_locstyle') == "custom_directory") {?>checked="checked" <?php } ?> /> <?php printf(__('Use a custom directory (recommended) at %s/', TCS_TEXTDOMAIN), WP_CONTENT_DIR); ?><input size="30" type="text" name="tcs_cuslink" value="<?php echo get_option('tcs_cuslink'); ?>" />editor-style[-shared].css

We can see it is line 361 that stores the value of $_POST["tcs_cuslink"] to the wp_options table.

On lines 63, 81, and 481 the value of tcs_cuslink from the wp_options table is outputted.

Writing the patch

To sanitize the inputs, we update line 361 to add a call to sanitize_file_name() before the value is stored to wp_options

<?
...
361    if ($_POST["tcs_cuslink"] != get_option('tcs_cuslink')) update_option("tcs_cuslink", sanitize_file_name($_POST['tcs_cuslink']));

Then to address the outputs on lines 63, 81, and 481 I escape the outputs using esc_attr()

<?
...
63     $http_path= content_url() . '/' . esc_attr(get_option('tcs_cuslink')) . $style_name;
...
81      $server_side_path = WP_CONTENT_DIR . '/' . esc_attr(get_option('tcs_cuslink')) . $style_name;
...
481          <p><input type="radio" name="tcs_locstyle" value="custom_directory" <?php if (get_option('tcs_locstyle') == "custom_directory") {?>checked="checked" <?php } ?> /> <?php printf(__('Use a custom directory (recommended) at %s/', TCS_TEXTDOMAIN), WP_CONTENT_DIR); ?><input size="30" type="text" name="tcs_cuslink" value="<?php echo esc_attr(get_option('tcs_cuslink')); ?>" />editor-style[-shared].css

The hardest part of this cleanup was choosing the right sanitization or escape function for the use case. In the code above, it appears the value of tcs_cuslink is a file's path. Which is why I chose sanitize_file_name(). When the variable was being outputted, it appears it is used within an HTML tag, which is why I chose to use esc_attr(). Doing both is correct, to ensure the code is sanitizing on input and escaping on output.

Conclusions

In this post we showed a practical application of the phrase "sanitize every input and escape on output". Adding the functions was easy and choosing the right sanitation or escape function was straightforward.

I only made 6 small changes in tinymce-custom-styles to improve the security of the code. 4 examples were given above, but I added an additional 2 security-related updates just to be thorough. These 6 changes not only made the code more secure, but also saved the plugin from being disabled in the official WP.org repository.

I hope that more plugin developers learn to embrace secure development practices so that their projects may continue to thrive and the end user's sites remain secure.

The post Patching a Stored XSS Bug In the "tinymce-custom-styles" Plugin appeared first on Patchstack.

In last week's knowledge share, I talked about static sites, I mentioned headless CMS being different and a topic for another week. Well, that week has come, and this week's knowledge share is an introduction to headless CMSs and WordPress. I will dive into what a headless CMS is, how WordPress can be used as one, who needs headless, who doesn't, and the security concerns that go along with headless WordPress.

This week's vulnerability roundup includes 4 security bugs with a critical severity score. Two of the four bugs received no patch, but they affected the same plugin. Stay tuned for the vulnerability roundup to find out if you need to update or migrate to protect your sites.

What is a headless CMS?

A headless CMS is a content management system that manages all of its stored data in the back-end, but does not provide any front-end (design) aspects. Headless WordPress, just means a WordPress installation that uses another technology stack to create the front end (but all data is still managed by the WordPress admin panel.)

Headless is Ideal for businesses that want to have one data set (such as products, customers, or content) but display it on multiple applications or different platforms. Such as a website that is also accessible via a mobile application. There could even be a desktop or command line tool built to work with the same back end. The power of headless CMSs is in its ability to have multiple front-ends all managed through a single back end.

Who needs a headless WordPress?

If you are a site owner currently using WordPress for your business, and you do not want to change your workflow or migrate your data to a new back-end. But if you do want to offer the same service using another platform, then headless WordPress may be for you. You could even consider keeping the existing website's front end (generated by WordPress) but using the same back-end data on another platform (like a mobile app.)

For front-end application developers (web, mobile, desktop, etc..) if you know how to work with the WordPress API endpoints then you can provide your services to WordPress site owners. Offer them a mobile app, maybe a CLI tool for efficiency, or offer an awesome unique website design that pulls data from their existing WordPress back end.

Who doesn't need headless WordPress?

If you do not already use WordPress for your website, then there are many back-end options out there to work with for headless design. They are simpler and designed to work with existing frameworks. So, if you're starting from scratch, it is probably best to build your headless app without the WordPress part.

WordPress itself already includes a front-end constructor, the themes. If you are happy with how your site looks with existing themes AND there is no need for the same data to be accessible on other platforms. Then headless WordPress is not for you, just stick with stock WordPress (or consider a static WordPress site if that is an option.)

The big hurdle with headless WordPress

There is one big caveat before you can migrate to a headless WordPress site. Not all WordPress plugins expose their functionality via an API. Since the front-end developer needs to use API endpoints to interact with the back-end, features without API endpoints will not work. This can be worked around by looking for a replacement plugin (that has API endpoints the front-end developer can use) or a code refactor of the plugin (adding APIs) or simply deciding what is more important: the feature the plugin offers or going headless.

Headless WordPress still requires security

While many people say headless WordPress is more secure, there is only a sliver of truth in that statement. It is true headless is more resilient against some attacks, it is superbly effective at confusing botnets and helps avoid performance issues. But, the back end for the WordPress website will still be web accessible and discoverable, therefore it needs to be secured.

All of the same security practices still apply Backups, Updates, vPatches, Secure Passwords (2FA on admin accounts), etc… and so on. I'll say it again, Headless WordPress still needs security.

Vulnerability roundup

videowhisper-live-streaming-integration - Unauthenticated RCE

The developers for the VideoWhisper Live Streaming integration plugin released a patch for a critical security bug found in their plugin. This bug could have led to arbitrary code execution by attackers, but it has been patched, so site owners need to make sure they have updated their installation.

houzez-login-register - Privilege Escalation

The developers of the premium plugin/theme houzez login register (available on ThemeForest) have released a patch to address a bug that could allow attackers to create high privilege accounts. Site owners should double check that they have updated this plugin as it is a premium plugin, and updates sometimes need to be manually applied.

[UPDATE 2023-02-27: Patchstack has detected this vulnerability in houzez theme as being actively exploited. Site owners are encouraged to update immediately.]

zendrop-dropshipping-and-fulfillment - Unauthenticated File Upload

zendrop-dropshipping-and-fulfillment - Unauthenticated SQLi

Finally, the two unpatched vulnerabilities with details released this week affected the same plugin: ZenDrop Global Drop Shipping. This plugin was closed on February 24th likely due to these issues.

The vendor for zendrop dropshipping and fulfillment plugin was notified on October 5th, 2022 regarding these two critical security bugs in their code. It has been over 4 months, almost 5 now, and we have to disclose these vulnerabilities exist publicly. We do not include any details which attackers could use to weaponize an attack, but this notification will help site owners be notified about the risk so they can take action to secure their sites as soon as possible.

Thanks and appreciation

This week's thanks goes out to the developers of VideoWhisper Live Streaming Integration (VideoWhisper) and Houzez Login Register (favethemes). Thank you both for providing a timely patch for the security bugs found in your projects. Your users can be assured you are supporting them and protecting their sites.

A special thank you to all the headless and front-end developers out there. Bringing interoperability to a single back-end is complicated work, but when done right it makes for a seamless user experience across platforms.

I will be back next week with more security tips, tricks, opinions and news on the Patchstack Weekly Security Update!

The post Patchstack Weekly #61: Should you use WordPress As a Headless CMS? appeared first on Patchstack.

This week's news is about static sites and security. Did you know with the right plugin WordPress can be used to generate HTML? If you have a non-interactive website, you could benefit from using static sites to practically guarantee security.

This week's vulnerability roundup will list over a dozen WordPress plugins that have unpatched security bugs in them. Most of these were reported through the Patchstack Alliance. While it is unfortunate the plugins were removed from the WordPress.org repository, it is a good thing that site owners will not be able to easily install these unsupported, possibly abandoned plugins on their WordPress websites.

The benefits of a static WordPress site

Did you know WordPress can be used to generate static HTML? Well, with the right plugin it can.

Converting to a static site may be an ideal way to manage some websites. Some examples would be brochure websites that direct the visitor to a brick-and-mortar store (with no online sales) or public journals or blogs would also be highly appropriate (as long as comments are disabled.)

A static website differs from a normal WordPress installation because it requires two separate components:

• A WordPress installation to generate static HTML files. You will want this installation only accessible by the site owner.
• A basic hosting account for the HTML files. This will be the site you point your DNS to, and people would visit.

This separation of HTML generation and hosting provides a lot of benefits (and a few drawbacks) which I will share with you now.

Static is the ultimate cache

If you believe caching plugins gives a performance boost. You can think of static sites as the ultimate cache. With static sites, you use the WordPress backend to add new or modify posts, content or even the design of the website. When you're done with your changes, you export and upload the site's files to your hosting provider (just like we did back in the 90s!) Once you do the changes are live and your site will be faster than any caching plugin could offer.

Static is secure

Using a static website removes almost all possible security threats. Think about it. What can get hacked? There is no database, it is just HTML files. There is no wp-login.php for bots to brute force either.

There are a few attacks I can think of, such as DOM-based or reflected XSS or your sFTP password could get compromised. But these threats affect dynamic WordPress websites just the same.

Never worry about updates

Since there is virtually no risk of vulnerabilities, you can rest easy. You will still have to update the WordPress installation you use to generate the static HTML from time to time, but this installation should only be accessible to the site owner. Allowing you to have a leisurely pace when it comes time to update.

The drawback - limited features

The biggest drawback of static sites is that the site will not be interactive. This means no contact forms, no e-commerce, no newsletters, no comments, etc… at least not directly managed by the website itself.

There are ways to make these features work in static websites, by using JAMstack design methods or headless WordPress. But that is a talk for another Patchstack weekly.

This drawback of limited features could be made up for not only by improved security and performance but also by reduced hosting fees. It is probably the first time I will get to say this, but it is …

The less expensive option is more secure.

Sites that can switch to static files instead of dynamically generated content can save a ton on hosting fees. There are multiple extremely affordable options (I'm talking the cost of a coffee or less per month) and even free options offered by GitHub, Google, CloudFlare, and more.

Static files may not be a right fit for every website but if you can go static, I recommend you do. Your site will be more secure, more performant, and cost less!

For dynamic web applications though, static files are not an option. This is why it is important dynamic web applications have robust security programs that include things like a security.txt file, preventative WordPress security, and vPatching.

Vulnerability roundup

The Patchstack Database added over 80 new vulnerability records in the last week, of which 80% received a timely patch from their respective developers. Unfortunately, that also means 16 of those 80 did not receive a patch. That is one in five, and should emphasize the importance of choosing actively developed plugins and supporting your plugin developers. Without your support, these open source projects will not thrive.

Here is the list of possibly abandoned plugins that have unpatched security bugs disclosed in the last week.

• fontiran - Broken Access Controls
• wp-post-comment-rating - Unauthenticated Vote Manipulation
• olevmedia-shortcodes - Authenticated XSS
• eyes-only-user-access-shortcode - Authenticated XSS
• tapfiliate - Authenticated XSS
• facebook-like-send-button - Authenticated XSS
• service-area-postcode-checker - Authenticated XSS
• upload-file-type-settings-plugin - Authenticated XSS
• download-info-page - Authenticated XSS
• sticky-ad-bar - Authenticated XSS
• open-social - Authenticated XSS
• vslider - Authenticated XSS
• ultimate-wp-query-search-filter - Authenticated XSS
• feed-changer- Authenticated XSS
• nooz - Authenticated XSS
• wp-baidu-submit - Authenticated XSS

Thanks and appreciation

This week's thanks goes out to the hard working security researchers behind the Patchstack Alliance. Without your efforts identifying, verifying, and reporting these security bugs then they would never be getting addressed. And more insecure projects would continue to be distributed to unsuspecting websites.

A special thank you goes out to the people putting the hard work in behind the WordPress plugin repository. The extraordinary effort of wrangling over 50,000 plugins is not missed by me. Keep up the good work behind the scenes that keeps that repository running smoothly and safely.

I will be back next week with more security tips, tricks, opinions, and news on the Patchstack Weekly Security Update!

The post Patchstack Weekly #60: Should You Convert WordPress To a Static Site? appeared first on Patchstack.

This week's knowledge share will be about virtual patching. I will explain how it works, why vPatching through Patchstack is different, and how it can save you from a lot of stress and anxiety when it comes to deciding when to update your site's components.

Then, in this week's vulnerability roundup, I will share the story of one plugin that patched a lot of security bugs in a single release. A heroic effort by the developer, but end users may receive a lot of alerts if they haven't updated yet.

Do you need Virtual Patches?

Everyone knows software has updates, but not all updates are equal. Some updates add minimal features, and some updates secure the software, but on rare occasions, some software updates break the thing they're updating.

This inequality of update importance has led to some site owners either opting out of updates outright, at least until they can monitor that the patch does not break things.

This delay can lead to security patches not being applied in a timely manner. This is where virtual patching comes into play.

What is a Virtual Patch?

Virtual patching is a term used when a software patch can be applied without updating the software itself. Typically using another technology layer like a WAF (Web Application Firewall) on the web server.

It is mostly used in the information security field as a way to secure software temporarily until a time that the software can be patched formally. It acts as a stop-gap when patches are delayed.

Patchstack has built the vPatch system, a specific method that provides auto-mitigation to open-source software security vulnerabilities through crowdsourced security research and AI/ML based source code analysis.

This is why vPatching is a valuable tool to have for any WordPress website where updates are not automated. In the event of a security bug being discovered in a plugin or theme, a vPatch buys you time to perform the update on your schedule.

vPatching is also handy if you encounter a bug in the update process. The extra protection vPatching provides gives you the option to downgrade back to the known working (but insecure) version of a plugin to work out the problem. Keeping the site online while you troubleshoot.

That is not all vPatching helps with; it can also be a last line of defense if you are using unpatched or unsupported software.

Protection from unpatched vulnerabilities

It is an unfortunate reality that not all open source projects are actively developed. I have written about this issue before, and even wrote some last patches for WordPress plugins that have been abandoned.

A vPatch is the only option to secure your website if a vulnerability is identified in an abandoned plugin. The vPatch will protect the website until you can find the time to find a replacement for the abandoned component that is putting your site at risk.

Of course, Patchstack offers vPatches for all paid Patchstack app accounts. If you are interested in being in control of how and when patches get applied but do not want to compromise site security, then you should be sure you have vPatching in place to protect your sites in the meantime.

Vulnerability roundup

This week's vulnerability roundup is all about one plugin, and twenty patched bugs. The plugin is Wicked Folders, the twenty bugs can be classified as either Missing authorization or Cross-Site-Request-Forgery. Both bugs are considered a Medium severity, and may not apply to you at all because they require a subscriber level account or to trick logged in users to follow links.

It appears a researcher familiar with finding these two types of security bugs audited the plugin and found 10 API endpoints that lacked nonce or authorization checks. I am unsure if Wicked Folders paid for an audit or if this was found independently. But it shows someone was looking for as many instances of these bugs as they could find.

The developer did a great job providing the patch back on February 6th and noted in the changelogs that this update includes security patches. Now, it is all up to the users to get their site(s) updated.

If you run a site with Wicked Folders and have not yet updated, you may receive a lot of notifications about this. Twenty notifications to be specific. This is because the CNA requesting CVE numbers reported 2 vulnerabilities for each of the 10 API endpoints that lacked nonce or authorization checks. This may result in a little alert fatigue or a temporary spell of anxiety when you see your inbox full of alerts. Don't worry though, all twenty of those CVEs are addressed in a single release and none are an emergency. So, update away at your convenience, and be certain the developer for Wicked Folders is attentive to security bugs (even 20 at a time!)

Thanks and appreciation

This week's thanks goes out to the developer of the Wicked Folders plugin. Thank you for patching all of those AJAX endpoints, and addressing each of those reported bugs.

A special thank you goes out to iThemes. The team announced this week that the iThemes Security and iThemes Security Pro plugins are now powered by Patchstack's Vulnerability Intelligence. This collaboration means more sites are being protected and is a win for everyone except the botnets.

I will be back next week with more security tips, tricks, opinions and news on the Patchstack Weekly Security Update!

The post Patchstack Weekly #59: Do You Need Virtual Patches? appeared first on Patchstack.

This week, I learned a fun fact about something security related Automattic is leading the way on. In this week's knowledge share, I will explain a proposed security standard that Automattic has already implemented more than anyone else. I will leave it up to you if you want to add this proposed standard yourself and show you how easy it is to set up.

In this week's vulnerability roundup I will cover one plugin with a high-risk security bug patched by its developer. As well as share details on some bugs in lesser-known possibly abandoned plugins which have left just a few sites at risk as these security bugs may go unpatched.

Weekly knowledge

I have been hanging out on mastodon recently and found it wonderfully nostalgic. There are a lot of people there sharing some really stellar posts, ideas, and blogs. It reminds me of the halcyon days of social media.

One of those blogs that I encountered was about a proposed security.txt standard. A security researcher out of Denmark wrote up a blog to encourage more websites to adopt the use of security.txt files.

Their post "A free way to improve your security.(txt)" shares some great insight from the security researcher's point of view.

One neat thing they did was scan 10 million websites looking for a security.txt file. They found very few websites have a discoverable security.txt file, but this is expected as the proposal is not a standard yet, and it is relatively new.

But, some big names have security.txt files, including Google, Facebook, Github, Slack, and multiple government organizations. But a company we all know is leading the way, Automattic. Automattic is listed as the security point of contact for the majority of security.txt files this researcher found. It appears Automattic installed security.txt files on the biggest number of websites, which means they're the organization with the largest adoption of the proposed standard.

That may or may not be reason enough to set up a security.txt file yourself, but let me show you how easy it is.

What is a security.txt file?

The primary purpose of a security.txt file is to identify a security-related point of contact for the website. You place this file in a well-known location, such as /security.txt or /.well-known/security.txt on your website so researchers who identify concerns on your website know who to contact.

This is a huge time saver for security researchers and bug bounty hunters. This is both a good and bad thing, but I will explain how to avoid the bad aspects in a second.

The contents of the security.txt file are simple. In a minimalist style, it can be just one field:

Contact: https://yourwebsite/vulnerability-disclosure-policy

or

Contact: mailto:[email protected]

There are many more fields you can add to the security.txt file, as well as a handy securtity.txt generator tool all available for free on securitytxt.org. You should check it out if you want to set this up.

Security.txt files work really well in conjunction with a vulnerability disclosure policy (VDP). You can avoid some of the bad aspects of bug bounty begging by using a VDP. When you communicate to researchers and bug bounty hunters what they can expect for bounties (including making it clear if you offer no bounties) you can save everyone time. You can also clarify what sort of security reports you want to hear about (or which you do not). Don't worry if you are offering no bounties either, you can still set up a VDP because some security researchers really do just want to help you out.

While the security.txt file is specific to vulnerabilities found on websites. If you are thinking something similar, something that helps communication between developers and researchers should exist for plugins and themes, well… you're right, luckily there is something. Patchstack launched a service for just this reason, a way to help plugin developers to communicate with security researchers called Patchstack mVDP. You should look into it. Bonus, it is free for FOSS WordPress plugins and we will write the vulnerability disclosure policy for you.

Vulnerability roundup

js-support-ticket - Unauthenticated Arbitrary File Upload

Users of the JS Support Ticket plugin should update to the newest release as soon as possible. The developers have been hard at work addressing security bugs and improving the plugin.

Seeing developers providing security updates is a great sign of a thriving and healthy project like JS Support ticket. The same can not be said for the next two plugins:

marketing-performance - Cross Site Scripting (XSS)

The generically named plugin "marketing-performance" has only a few installations, and was last updated 4 years ago. This week, a cross site scripting vulnerability was publicly disclosed. If anyone out there has the "marketing performance" installed on their site, you likely want to look for an alternative that is actively developed.

1003-mortgage-application - Authenticated (subscriber+) Arbitrary File Download

The 1003 mortgage application plugin is vulnerable to a bug that could allow any logged in user (including subscribers) to download arbitrary files off the web server. The last release was just 2 months ago, so hopefully, the developers are still active and will provide a patch soon.

Thanks and appreciation

This week's thanks goes out to the developers of js-support-ticket a.k.a.. JS Help Desk. Thank you for patching the security bugs and really improving your project's code quality in the last few weeks.

Further thanks is extended to EdOverflow and Yakov Shafranovich the creators of the security.txt standard, and maintainers of securitytxt.org

I will be back next week with more security tips, tricks, opinions and news on the Patchstack Weekly Security Update!

The post Patchstack Weekly #58: Do You Need security.txt? appeared first on Patchstack.

This article will introduce concepts about how computers schedule tasks with cron and how WordPress's cron implementation "WP-Cron" works more like a queue instead of a scheduler. I will share some of the implications queueing instead of scheduling may have, as well as how to remediate the risk for site owners and what WordPress core is doing about this.

It was written in response to CVE-2023-22622 published by MITRE.

What is CVE-2023-22622?

This is a Common Vulnerability Enumeration reference number describing a security concern about how tasks get scheduled on WordPress applications. The CVE claims WordPress relies on an unpredictable variable, site visitors, in order to check if there are any tasks to be run. This may lead to important scheduled tasks (such as software updates) running inconsistently or not at all.

This is only an issue for sites that get low-to-no traffic, but there is an easy way to address it for site owners and for WordPress core which I will get into at the end.

What is a Cron?

The term cron means "scheduler" in the software world. You use cron to schedule tasks or "cronjobs" to be performed at specific intervals on the server. The operating system runs a background process or service called "cron" which you can think of as always checking the time and executing any jobs that are scheduled to run at that time. Like efficient public transit, you can expect cron jobs to run on time, every time, short of major catastrophes.

What is WP-Cron?

WP-Cron is an implementation of a task scheduler for WordPress. Unlike cron, WordPress is a web application, so it can not run background processes itself. The way the WordPress developers worked around this limitation, was to schedule tasks for a future time, and any time the application is running (e.g. when someone visits the website) you have the application check if there are any tasks that have not yet been run but should have been run (e.g. they have a scheduled time in the past) then run them.

Visualizing WP-Cron

To understand WP-Cron better, it helps to think of WP-Cron as a queue and not a scheduler. A task may not run on time, but it will run the next time WP-Cron checks for it.

Using the train analogy again. Scheduling tasks through WP-Cron is like a light rail or subway, if you miss the train (or if a train is skipped) you just queue up and wait. When the next train arrives it will pick up all of the passengers and proceed. Everybody gets to where they are going, eventually.

This is a clever way to get around the inability to run a persistent background process on the web server. As long as the WordPress website gets at a few visitors per hour, WP-Cron tasks will be performed reasonably "on time".

Thanks to bots, every public-facing website gets a regular flow of traffic. Although bot traffic is normally unwanted, it is very handy to make sure WP-Cron is regularly running.

What type of sites could be affected?

If a WordPress site gets low to no traffic, then the WP-Cron queue will never be checked and scheduled tasks would not be performed. This isn't an issue for a public-facing website, but it could be a concern for a few edge cases, like sites running on private networks, sites running on docker images, sites strictly firewalled, development/staging environments, and sites only accessible on a VPN. Just to name a few, but there may be more.

WordPress applications in these low-to-no traffic environments will not run some important WP-Cron tasks.

What are some of the important WP-Cron tasks?

WordPress core uses WP-Cron to schedule some highly important tasks. Such as checking for updates in plugins, themes, and WordPress core. WP-Cron also schedules the tasks to perform the updates themselves. Without WP-Cron functioning correctly, sites may miss important security updates.

Plugins may introduce many more important tasks which you may want to ensure are performed on a proper schedule too.

How to make WP-Cron run on a schedule?

The WordPress documentation team already has your back. They provide easy-to-follow steps for how to use the Mac, Linux, and Windows task schedules to ensure WP-Cron is running on a schedule.

Summary

The way WP-Cron functions as an intermittently processed queue is for all purposes completely safe and functional for any public-facing website.

But this may not be right for every installation.

If you prefer a more predictable schedule or manage sites that have low-to-no traffic, then you should consider using the operating system's task scheduler instead of the default method. There are performance considerations and benefits to switching to a predictable scheduler from the default behavior as well (but this change is done on the web server, not within the web application.)

How WordPress mitigates CVE-2023-22622

If I had to explain CVE-2023-22622 in the simplest terms possible, I would say it is a "silent failure" concern. In information security jargon, CVE-2023-22622 describes a CWE-392 or "Missing Error Report" concern. This can be mitigated by making it clear to the user that a failure or error has happened.

Interactions with technology improve when users receive important warnings when something is malfunctioning. Like a notification when a train or flight is delayed, or a check engine light.

WordPress currently informs users when WP-Cron tasks are failing to run in two ways:

• Site Health checks will report when scheduled events are not performed.

• Notifying users with automatic updates enabled when those tasks are not performed. Including when the last time they were run, and pointing out there may be a problem with WP-Cron

Finally, there is a discussion surrounding improving the communication surrounding WP-Cron errors happening in WordPress trac ticket #57159. This may be a good place to have further discussion on the matter. This ticket has been updated with details regarding CVE-2023-22622 concerns based on discussions and knowledge I gained while preparing this post.

Thank you

I must share my appreciation for the many people who have written about WP-Cron concerns in the past (See references below) as well as share my appreciation with the anonymous MITRE and NIST team members and non-anonymousWordPress.org community members (johnbillion, clorith, and sebastienserre) thank you for discussing this matter with me, clarifying points, sharing your knowledge, and for collaborating to work toward a resolution.

References:

Damien Carbery: How to use WP-Cron in WordPress
Published 2017-03, Damien Carbery (daymobrew) provides insight into how to use WP-Cron and warns about inconsistent scheduling.

theCpanelGuy: The Nightmare that is wp-cron.php
Published 2018-06, theCpanelGuy highlights concerns they encountered with WP-Cron tasks leading to resource usage spikes and unnecessary traffic. theCpanelGuy encourages people to use a task scheduler and recommends there should be: "a notice placed within the WordPress admin interface".

Tenable: Finding: WordPress Cron Enabled
On 2022-12-21, Tenable released an advisory about wp-cron.php. Citing the article from theCpanelGuy only, Tenable describes the issue as a Denial of Service concern.

MITRE: CVE-2023-22622
On 2023-01-05, MITRE created a CVE describing the issue affecting low-to-no traffic WordPress websites have scheduling concerns with WP-Cron, they make it clear without consistent traffic important WP_Cron tasks may not be performed in a timely manner on WordPress websites.

WP-Crontrol: Reasons WP-Cron events can miss their schedule
The developers of WP-Crontrol know WP-Cron deeply. They have prepared the above documentation for users to better understand why and what to do if WP-Cron is not running on schedule.

WordPress Codex:

What is WP-Cron?
States: "WP-Cron does not run constantly as the system cron does; it is only triggered on page load. Scheduling errors could occur if you schedule a task for 2:00PM and no page loads occur until 5:00PM."
Understanding WP-Cron scheduling
States "Unlike a traditional system cron that schedules tasks for specific times, WP-Cron uses intervals to simulate a system cron."
Hooking WP-Cron into the system task schedule
Shows how to set up WP-Cron using the operating system's task scheduler. Including steps on how to do so in Windows using PowerShell.

The post Solving Unpredictable WP-Cron Problems, Addressing CVE-2023-22622 appeared first on Patchstack.

This week's knowledge share is for developers and site owners alike. I will be discussing how open source projects (really any code project) can show, not just tell, their users that their project's code is secure and safe to use.

In this week's vulnerability roundup, I will share details about 3 high-risk security bugs in WordPress components of which 2 received patches and 1 went without.

How developers can prove their security

This week's knowledge share continues the trend in the past few weeks' new years security resolutions. This week's resolution is how developers and project owners can prove their project is secure and safe to use.

If you're not a developer, stick around. You may learn what to look for in a project that is serious about handling security and is willing to prove it.

As in previous new years resolutions I will share a few checklist items that open source projects can take to improve and show their security process to users. Or, as I prefer to say - to prove they have a mature security model.

Let's get started.

Do they have a history of security releases?

This one may sound counterintuitive at first. You want to look for a lot of security releases. Because a project with a regular history of security fixes is proof of active security-related development and improvements. If a project has zero security-related patches, don't think that means it's security bug-free - it might just mean the opposite.

Where can you review or publish a project's security releases? Changelogs.

Developers, you should always include details about releases in the changelogs. Site owners, you can also cross reference a third party like a public vulnerability database to confirm if there are really no security bugs known in the product, or if they omit security details from changelogs.

Another counter-intuitive idea is to look for releases with multiple security patches. Those may be another good sign, it may mean they paid a third party to perform a security audit and then made the fixes in a single security release to improve their code base.

If you spotted no security release details in the changelog, but there are publicly reported security bugs in the Patchstack Database? In this case, you may have a developer who is not communicating security issues very well with their users. This leads me to my next recommendation:

Do they communicate security issues?

Developers write the patches but a site is not secure until that patch is applied. This is why it is important for a developer to inform their users when a security patch is made available.

This communication can take place in a few places. Most commonly, the project's changelog is the first place to look. This is how you can prioritize if that "update is available" needs to be performed next week (features) or immediately (security releases.)

In addition to changelogs, many open source projects have a dedicated "Security" section in their blog. If a project has a security feed I can subscribe to via RSS, then that's the best. I will pipe that feed right into the company slack (or email list) and we never miss an important release.

Now, onto the final recommendation:

Do they have a vulnerability disclosure policy?

Vulnerability disclosure policies are formal documents describing how to report security issues to a project. I talked about what makes a good vulnerability disclosure policy last year on the Patchstack weekly(Week 5 - Open Source & Vulnerability Disclosure Policies). This year, Patchstack makes setting up a vulnerability disclosure policy a lot easier with the managed Vulnerability Disclosure Policy program.

If you're a developer, I recommend you communicate how you would like security bugs reported to your project. If you lack this, you might get reports in unexpected places, like your public support forums.

Conclusions

These three points: A history of security releases, communication of security and a vulnerability disclosure policy are not just recommendations. They are how mature open-source projects approach security. You need not look far for an example, as WordPress itself has all three. WordPress security releases are clearly communicated with each release when security bugs are responsibly reported.

Vulnerability roundup

enable-media-replace - Author+ Arbitrary File Upload

The popular Enable Media Replace plugin, with over 600,000 installations addressed a security bug which could have allowed users with Author or higher roles the ability to upload arbitrary files. It is recommended to patch as soon as you can if you have many author accounts on your site.

mainwp-file-uploader-extension - Unauthenticated File Upload

The MainWP File Uploader extension released a patch which addresses an unauthenticated file upload security bug found by Patchstack's very own Dave Jong. Users of the MainWP File Uploader extension are strongly encouraged to update as soon as possible.

mainwp-links-manager-extension - Unauthenticated Object Injection

In light of this object injection security bug being reported in it, MainWP has retired the MainWP Links Manager Extension. It is recommended site owners remove this plugin immediately and find an alternative solution.

This week included multiple vulnerabilities affecting various MainWP plugins. If your websites use MainWP, then it is highly recommended you check for updates or if the components you are using have been retired.

Thanks and appreciation

This week's thanks goes out to the developers of Enable Media Replace, Short Pixel as well as the developers at MainWP for providing your security releases.

A special thank you goes out to all of the developers who don't just say they take security seriously, but actually do. With clear communication about security releases, regular security updates and a vulnerability disclosure policy. That is how you prove you walk the walk not just talk the talk.

I will be back next week with more security tips, tricks, opinions and news on the Patchstack Weekly Security Update!

The post Patchstack Weekly #56: How Can Developers Prove Their Plugins Are Secure? appeared first on Patchstack.

When it comes to your WordPress site, security isn't merely an option – it's an absolute necessity. A secure web hosting environment forms the bedrock of your site's defense against an ever-evolving landscape of cyber threats. It's the digital moat that protects your valuable content, sensitive data, and online presence from malicious actors.

We understand that the vast array of hosting options can be overwhelming, which is why we've crafted this guide to demystify the process. 

At Patchstack, we don't just talk about security – we live and breathe it. Your website's security is our top priority, and we're dedicated to ensuring that you have the knowledge and resources to make the right choice.

We're proud to be partnered with some of the industry's most reputable hosting companies, all of whom share our unwavering commitment to WordPress security. These partnerships allow us to bring you the best recommendations and insights into hosting providers that prioritize your website's safety.

Keep reading to know more!

What Makes a Web Hosting Secure?

A hosting environment that is specifically designed and configured to safeguard WordPress websites from various online threats and vulnerabilities should protect your sites against unauthorized access, data breaches, malware infections, and other security risks that can compromise the integrity and functionality of a WordPress site.

Secure web hosting for WordPress typically comes with:

• Server Hardening: Implementing stringent security measures at the server level to prevent unauthorized access and mitigate potential risks.
• Regular Updates: Ensuring that server software, including the operating system and server applications, is kept up to date with security patches.
• Firewalls: Deploying firewalls to filter out malicious traffic and protect against common web application attacks.
• Malware Scanning and Removal: Conducting regular scans for malware and offering tools to remove any detected threats.
• Backup Solutions: Providing automated backup options to enable website owners to restore their sites in case of data loss or security incidents.
• SSL Certificates: Offering secure sockets layer (SSL) certificates to encrypt data transmission between the server and website visitors, enhancing data security.

Significance of Hosting Companies

The pivotal role played by hosting companies in ensuring the security of websites cannot be overstated. Hosting providers undertake a multifaceted approach to enhance website security:

• Infrastructure and Network Security: Hosting companies need to meticulously maintain secure server infrastructure and networks. This care greatly mitigates the risk of unauthorized access and data breaches.
• Security Patching: Hosting companies prioritize regular updates for server software and the application of security patches. This proactive measure is vital for addressing known vulnerabilities and strengthening defenses against emerging threats.
• Customer Support: Hosting companies extend responsive customer support to assist website owners in addressing security concerns and incidents. This support network is invaluable for promptly resolving issues and maintaining the integrity of websites.
• Server Maintenance: Hosting companies ensure that routine server maintenance tasks are performed without compromising security. This includes configuring server settings securely and isolating websites from one another, preventing cross-site vulnerabilities.

The significance of these security measures cannot be understated for website owners, with the hosting companies playing a pivotal role in maintaining the security of the hosting infrastructure, and assisting website owners in securing their WordPress sites.

Recent events have underscored the critical importance of robust security measures. For instance, consider the case of a recent ransomware attack on a prominent cloud provider, CloudNordic. This attack, which occurred on August 18, resulted in the complete encryption of CloudNordic's servers, effectively paralyzing their operations. The malefactors behind the attack also wiped out both the company's and customers' websites and email systems. Despite ongoing efforts by CloudNordic's IT team and third-party responders to restore data, even backup systems were compromised.

In response to the extortion demands of the attackers, CloudNordic chose to uphold its principles and refused to pay a ransom to retrieve the information and systems. This incident serves as a stark reminder of the need for robust security measures, and hosting companies' dedication to security is paramount in safeguarding against such threats.

What to Look for When Choosing Secure Web Hosting

To ensure your website's security, here's a checklist of key factors you should consider:

1. HTTPS Availability 

In today's digital landscape, HTTPS is no longer a luxury but a necessity. Most hosting providers offer free HTTPS, thanks to initiatives such as Let's Encrypt and ZeroSSL, which provide free TLS certificates.

To check if your website has HTTPS enabled, simply type "https://" followed by your domain name in your browser. If you see a lock icon (or a Tune icon in newer versions of Chrome), then you're good to go. If not, explore how to set up HTTPS with your hosting provider.

2. Backup and Restoration 

Backups are your safety net in case of emergencies. However, it's crucial to not only rely on them – but also test their functionality. Reach out to your hosting provider to understand their backup and restoration process.

If possible, perform a test run – but do avoid overwriting your live site! This proactive approach ensures your backups are reliable when you need them the most.

3. Keeping Software Updated

We all know the importance of regularly updating a WordPress website, as well as our laptop or PC’s operating system. But web servers have operating systems too – and they also need regular updating.

Luckily, WordPress allows you to confirm the versions of the software it relies on. Simply log in to your WordPress admin panel, open Tools, and Site Health. From the Site Health page you will get a list of details – including server versions, if you click on the “Info” tab, then expand the “Server” section.

The server section has information about software versions of PHP, Web Server, and more. Alternatively, you can expand the “Database” section to find out the server and software version for your database server as well.

You will need to do a little manual verification to find out if these components are still supported by their respective software vendors, but it is worth the time and effort.

If you find a software version is out of date or unsupported – don’t panic. Simply reach out to the hosting provider’s support team to ask them about it. You may be able to easily upgrade, or they may inform you the package is “backported” – which means someone did apply the security patches needed, but it still reports an old version number.

4. Brute Force Protection

An analysis by Google Cloud shows that Brute-force attacks are the most common threat for cloud service providers. This type of attack doesn’t require any skill and it can be automated easily; this is why almost half of all attacks on websites are brute force attacks. We have covered brute-force attacks on WordPress extensively in one of our previous posts.

Hosting providers often implement mechanisms to throttle or block repeated failed login attempts. To test your host's brute force protection, go to your site’s login page (usually wp-login.php), and then deliberately enter the wrong login details. If you're not blocked after ten or more incorrect attempts, it's a cause for concern.

Note: Don’t try this if you rely on the same IP address to access your site. We recommend you try it during off-hours or from a different location.

5. Proactive Insecure Component Identification

The world has moved on to proactive security instead of reactive security – you should check if your hosting provider identifies insecure components on your website. However, it is not advisable to install malware on your websites to see what your host does (because what they do won’t be good!)

Instead, you can consider installing a known insecure version of a component – you can find many in the Patchstack database. Be sure that the security bug in question requires a high-privilege logged-in user too. You do not want to install something that could result in your site being hacked.

Once an insecure version of a component is installed, and you have auto-updates turned off, all you need to do is wait. Count the days until you receive a notification from your hosting provider (if you receive a notification at all).

Proactive notification of insecure components is available from a few Patchstack hosting partners already. However, if you do not receive a notification then you can address this yourself by installing the Patchstack plugin.

6. Customer Support

Responsive customer support is an integral component of any web hosting environment, especially when it comes to addressing security issues. 

Security incidents can happen at any time. Having responsive customer support means that when you encounter a security issue, you can quickly reach out to experts who can guide you through the resolution process. This reduces downtime and minimizes the potential damage from security breaches.

Moreover, security can be complex, and not all website owners are security experts. Responsive support ensures that you have access to knowledgeable professionals who can help you understand and address security concerns effectively.

Conclusion

We've emphasized the paramount importance of selecting a secure web hosting provider for your WordPress site. Your hosting choice forms the foundation of your website's security.

Consider the security features and practices discussed in this guide, and ensure that your hosting provider aligns with these best practices. This includes aspects such as firewalls, regular backups, DDoS protection, and responsive customer support.

If you find that your hosting provider lacks certain security features, explore the option of using WordPress plugins to supplement your site's security.

Patchstack is here to help you enhance the security of your WordPress site. Think of us as your dedicated team of security specialists, vigilantly safeguarding your online presence.

Additional Resources

• Most Common WordPress Vulnerabilities & How to Fix Them
• How To Find Out If My WordPress Site Has Vulnerable Plugins?
• How To Limit Login Attempts on WordPress (Should You?)

Vulnerability roundup

wp-booklet - Remote Code Execution

The wp-booklet plugin was recently closed for unofficial reasons, but it is likely because of this remote code execution bug. Luckily, it appears a valid user account (subscriber or higher) is required to exploit this vulnerability. Which may buy you some time to find an alternative.

hide_my_wp - Unauthenticated SQL injection

The developers for hide_my_wp have released a patch to address an unauthenticated SQL injection security bug. Users should make sure they update their installed versions of hide_my_wp as soon as possible.

Please note this is the hide_my_wp premium plugin found in the Envato market.

Thanks and appreciation

This week's thanks go out to the developers of hide_my_wp, wpWave. Great job patching that SQL injection bug.

This week's special thanks go out to everyone taking responsibility for the website's security. Hopefully, that means you.

I will be back next week with more security tips, tricks, opinions, and news on the Patchstack Weekly Security Update!

The post Patchstack Weekly #55: How To Choose a Secure Web Hosting Provider? appeared first on Patchstack.

This week's knowledge share will continue the trend of new years resolutions. I am honored to share with you these simple tasks you can do, in hopes you will improve your website and business security maturity as we start this year off by taking responsibility. This week's new years security resolution is all about how to ensure your sites are not running insecure, abandoned, or unsupported components.

This week's vulnerability roundup will include one critical unauthenticated security bug that was patched. I will also share a list of plugins reportedly being targeted by a botnet that is attacking WordPress websites.

How to check if WordPress is running insecure, abandoned, or unsupported plugins/themes?

In the past week, there has been a lot of news about a botnet targeting WordPress websites. The botnet's behavior is simple, it has weaponized attacks against insecure WordPress plugins. Upon successful compromise of a website, it installs a backdoor or node which will listen for further commands from a central or "Command and Control" server the attacker's control. Which perpetuates further attacks against more websites.

The only surprise is the age of some of the weaponized vulnerabilities this botnet uses are. Full details on the vulnerabilities being targeted were not included in the reports, but some investigations show they are targeting vulnerabilities that were patched back in 2016.

This brings me to the point of this week's knowledge share. This a reminder to ensure your WordPress sites are running updated, secure, and supported components.

Checklist for ensuring your website's plugins are secure

Let's walk through how to check that your WordPress websites are running up-to-date software. Don't worry, it won't take long for each site.

Check for any updates

First, let's check if your plugins have any updates available. All you need to do is log in to your website's WordPress admin panel and check the plugins and themes tabs. It'll have a red number highlighting the tab to let you know if there are updates available.

These updates could be features or security updates, a default WordPress installation only tells you if an update is available.

Check for security updates

To go one step further, we can check if any installed components have known vulnerabilities. This is where a tool like the Patchstack plugin comes in handy. It will tell you if you are running known vulnerable components and allow you to easily update just the insecure components.

This is very handy for detecting insecure components that receive no updates from their developers. Or for any website that is sensitive to applying updates out of fear of breaking the website.

Now that we can confirm the site's components are up to date, or at least up to date on security patches what more is there?

Confirm the components are actively supported

We should confirm the components you chose are actively supported and not abandoned.

Active development is important, you can see this via the last code commit date or via the component's changelog (if one is provided.) If it has been years since the developer's last commit, you may want to reconsider using a project that receives such infrequent updates.

But, slow commits are not a sign of insecurity or abandonment, they are just a sign of slow commits. There is a chance the developer is still active. You can reach out to them via email, or the component's support forums. In fact, if you see the developer is active in the support forums that may be a great sign. Reach out! Ask them how things are going with the project and what the priorities are for the next release.

Engaging with the developers is a fine way to show support for their projects. I'm sure financial donations would also be appreciated too, but sending them a thank you and showing your appreciation and interest in where the project is going is infinitely better than being one more anonymous tick on their project's download counter.

Choose good replacements

During this process, you may come to a point where replacing a component seems keen. So I will leave you with one last recommendation. If you find yourself comparing two components, both appear regularly updated and well-supported. What could a tipping point be? Well, to me, I would check if they have a mature security posture. Specifically, do they have a vulnerability disclosure policy? Do they make it easy for security researchers to report issues to their team and is the project's changelog include at least a few clearly communicated security updates?

If they do this, then that is the sort of project you know you can trust is supported, will respond to security appropriately, and genuinely cares about their user's safety.

Vulnerability roundup

membership-for-woocommerce - Unauthenticated Arbitrary File Upload

The developers of Membership for Woocommerce released a patch to secure their code against an unauthenticated arbitrary file upload security bug. The plugin only has a few hundred installations, but site owners should apply the most recent update as soon as possible. The CNA that handled this bug report plans to release the proof of concept to the public] on January 25th, 2023. Site owners have only the next few weeks to update.

Doctor Web's Report

The security research firm Doctor Web recently released a report regarding backdoors infecting web servers through insecure WordPress websites. This report includes details on the backdoors the botnet was using as well as the insecure components the hackers were exploiting.

Their report lacks vulnerable version ranges for these components, but if you are running any of the following plugins it would be a good idea to make sure you have applied all available updates.

• WP Live Chat Support
• Yuzo Related Posts
• Yellow Pencil Visual Theme Customizer
• EasySMTP
• WP GDPR Compliance
• Newspaper Theme on WordPress Access Control
• Thim Core
• Google Code Inserter
• Total Donations
• Post Custom Templates Lite
• WP Quick Booking Manager
• Facebook Live Chat by Zotabox
• Blog Designer
• WordPress Ultimate FAQ
• WP-Matomo Integration (WP-Piwik)
• WordPress ND Shortcodes For Visual Composer
• WP Live Chat
• Coming Soon Page and Maintenance Mode
• Hybrid

Thanks and appreciation

This week's thanks go out to the developers of Membership for Woocommerce, thank you for that quick patch and for securing your user's websites.

A special thank you goes out to Doctor Web, thank you for your honest reporting of botnet activity. Your initial report was clear and even-handed that these were old and publicly known vulnerabilities in these components.

I will be back next week with more security tips, tricks, opinions, and news on the Patchstack Weekly Security Update!

The post Patchstack Weekly #54: How To Make Sure Your Sites Are Running Safe WordPress Plugins appeared first on Patchstack.

I will start by wishing you a Happy New Year - and thank you for listening/reading!

2023's first week's news will include an update related to the LastPass compromise from last summer. The cloud-based password vault vendor released an important announcement during the holidays, which you need to know about.

LastPass's announcement is an inconvenience, but also a reminder about a common security best practice: always rotate your passwords. I will kick off the new year by sharing some security best practices with you over the next few weeks.

In this week's vulnerability roundup I will discuss a handful of security bugs found in WordPress components that have gone unpatched. Unfortunately for these open-source projects, the new year is starting out rough, but it's important for users of these plugins to know about the risks so they can take action.

LastPass security breach update

I have shared updates in the past related to the LastPass security incident from August 2022. The updates I have shared with you are based on the official announcements made by LastPass.

Previously, I said that LastPass assured users that no customer password vaults were leaked during the breach. On December 22nd, 2022 LastPass released an update that now makes it clear - attackers did gain access to an encrypted copy of customer data, including the password vaults.

The data was encrypted, so the attackers do not have access to your passwords as plain text. However… all encrypted data can be de-encrypted eventually, given enough time. The fact the attackers have a copy of the LastPass source code also means they know what algorithms were used to encrypt the data, and they know how the salts were generated, which gives the attackers an advantage. It will still take a lot of computational time to crack every last pass user's encrypted vault, but it will happen if an attacker who has a copy of this stolen data puts the effort into it.

This means if you've used LastPass, you should be rotating your passwords before it is too late. The only good news is, you have some time to get this done - but the sooner, the better.

In fact, you should be rotating your passwords regularly. LastPass has this as a feature to make this automatic (for some websites.) For the rest of us non-LastPass users, it isn't hard to do manually.

Security best practice: rotating passwords

With the LastPass incident fresh on our minds we are reminded passwords should be temporary, not permanent. This is because breaches happen. Backups of account login credentials get leaked from major vendors all the time. LastPass is not alone in this, you can view details on many public breaches on haveibeenpwned.com.

If we accept that breaches happen, companies we trust with our data with get hacked, and we need to be responsible for our own account data. What can we do?

As far as passwords and credentials are concerned, here is what I recommend:

1. Rotate passwords regularly, maybe once a year but always rotate them after an incident occurs when the secret may have been leaked.
2. Never use a password twice, every login needs its own unique and strong, password.
3. Use 2FA, and rotate your 2FA secrets too. Different 2FA options have different risks, but if you can rotate the 2FA code you should.

Take some time this new year to rotate the important account passwords in your life. LastPass user or not this is a best practice for everyone.

Vulnerability roundup

The trend of abandoned open-source projects not receiving security patches continues as the new year starts. I spent some time writing some last patches for abandoned WordPress plugins in 2022, but there are so many each week that it's unsustainable to write a patch for everything.

I will continue to share a list of abandoned WordPress components with serious vulnerabilities that have gone unpatched each week.

wp-upg - Unauthenticated Remote Code Execution

This is a serious risk and it is strongly recommended sites using wp-upg aka "User Post Gallery" find another solution for their websites. This plugin has not been updated in over a year, and the developer appears focused on other projects at this time.

images-optimize-and-upload-cf7 - Unauthenticated Content Deletion

The developers for this projects have been active in the last few months. Answering support questions in the plugin's forums and pushing a release in November. So there is still hope they may be working on a patch.

fontsy -Unauthenticated SQL Injection

Users of this fontsy plugin should find an alternative ASAP. The plugin's developer activity has been silent for over 2 years, with no updates and no support activity on WP.org in that time. It appears the developer has moved on to focus on other projects.

cbxpetition - Unauthenticated SQL Injection

The cbxpetition plugin has not received an update in 3 years and was last tested against WordPress 5.2.17. This is a signal the project has been abandoned. It would be recommended users of cbxpetition find an alternative plugin for their needs.

Thanks and appreciation

This week's thanks goes out to the team at LastPass for being transparent about the customer password vault data being compromised during the breach. I suspect your security, incident response, and development teams have been working extra hard in response to this incident. Great job, keep it up.

Special thanks goes out to the Patchstack Alliance. We are still adding up the numbers, but 2022 was a big year for WordPress vulnerabilities being reported, patched, and managed through the Patchstack Alliance.

I will be back next week with more security tips, tricks, opinions, and news on the Patchstack Weekly Security Update!

The post Patchstack Weekly #53: Security Best Practice - Rotate Your Passwords appeared first on Patchstack.

Mistakes make the world go round. We can observe a fault and learn from it, improving ourselves in the process. Humans are social creatures too, allowing us to learn from mistakes other make too.

The worst mistake any human can make is to assume infallibility. Assuming you are incapable of making a mistake is to declare yourself above improvement. Claiming you are beyond the humanity of making mistakes, places you in a precarious position of your own making.

Mistakes are what this blog post is about. Patchstack's "Last Patch" is a short series of blog posts where we discuss and patch unpatched security bugs in open source projects.

We do not fault the developers for the lack of a patch. We believe starting an open source project is not a life sentence of providing fixes and support at no cost or remuneration. We understand all people make mistakes, and that most open source project developers are people like us all. People who make mistakes, people in the process of improving, and people who simply need support and help.

We want to help. Help the site owners, help developers, and help hosting providers with rules to protect their customers.

Today's "last patch" is for the add-comments plugin, last updated 10 years ago. Everything seemed fine until November 2022, when an XSS security bug was reported in the plugin. Then, the exploit's proof of concept was publicly shared a few weeks later. The plugin was removed from the WordPress.org plugin repository on the 9th, for the safety of users.

In this post I will review the security bug (e.g... the mistake) that lead to this plugin's disablement. You will see how it could have been patched.

TL;DR Just Share the Patch

For site owners

Open the add-comments/add-comments.php file and find the addCOmments_options_page() function near line 90.

Modify the start of the function to look like the following:

/**********
**  Last Patch added by Patchstack (RR)
**********/
function addComments_options_page() { 

    if( $_POST['action'] == 'addcomments' ) {
        echo '<div class="updated settings-error">';
        $id = ( $_POST['post_or_page'] == 'page' ? $_POST['pages_list'] : $_POST['posts_list'] );
        $author = ( isset( $_POST['author_name'] ) ? sanitize_text_field($_POST['author_name']) : 'annonymous' );
        $email = ( isset( $_POST['author_email'] ) ? sanitize_email($_POST['author_email']) : get_bloginfo('admin_email' ) );
        $url = ( isset( $_POST['author_url'] ) ? sanitize_url($_POST['author_url']) : '' );
        $ip = ( isset( $_POST['author_ip'] ) ? $_POST['author_ip'] : '127.0.0.1' );
        echo addComments_add_comments( $id, $author, $email, $url, $ip, sanitize_text_field($_POST['comment']) ) 
        . ' comments added to ' . get_the_title( $id ) . '</div>';
    } ?>
/**********
**  End Last Patch
**********/

This will add sanitize_* functions to $_POST variables found on lines 95, 96, 97, and 99.

Once this change has been made the attempts to inject XSS payloads no longer work for any of the protected fields.

For hosting providers

There is no recommended WAF rule for this XSS bug. A WAF rule would block the request outright, it would be better to sanitize these inputs, making them safe to display.

Using a generic, and robust, XSS protection rule should detect and block these requests, but I would recommend the code based patch outlined above.

Last Patch: add-comments

Verifying the vulnerability

The proof of concept for this security bug was released by WPScan. Reviewing the example I was able to find the page to visit /wp-admin/options-general.php?page=addComments and the variables the XSS payload should exist in: comment.

Verifying this vulnerability was easy knowing the above. Visiting the page in question on my test WordPress site with add-comments installed showed me the "add comment" page, which is just a form to fill out. Using example XSS payloads in the add-comments form's fields required no special tools or programs, the XSS payloads just worked when entered in the comment field as well as the author_name field.

Once the payload is injected visiting any page where the malicious comment results in a javascript alert box popping up.

Finding what to patch

Now that we know the security bug exists and how to test for it. Let's look into the plugin's code. Luckily, this plugin is simple to understand as it only has one file: add-comments.php.

Digging through this one file's 162 lines of code, I found the relevant function on lines 90 - 101

Here is the relevant insecure code:

90    function addComments_options_page() { 
91        
92        if( $_POST['action'] == 'addcomments' ) {
93            echo '<div class="updated settings-error">';
94            $id = ( $_POST['post_or_page'] == 'page' ? $_POST['pages_list'] : $_POST['posts_list'] );
95            $author = ( isset( $_POST['author_name'] ) ? $_POST['author_name'] : 'annonymous' );
96            $email = ( isset( $_POST['author_email'] ) ? $_POST['author_email'] : get_bloginfo('admin_email' ) );
97            $url = ( isset( $_POST['author_url'] ) ? $_POST['author_url'] : '' );
98            $ip = ( isset( $_POST['author_ip'] ) ? $_POST['author_ip'] : '127.0.0.1' );
99            echo addComments_add_comments( $id, $author, $email, $url, $ip, $_POST['comment'] ) 
100            . ' comments added to ' . get_the_title( $id ) . '</div>';
101        } ?>

Can you spot the mistake?

Deciphering the code

The security bug is caused by using $_POST variable values without sanitizing them first. When the developer sends these values to addComments_add_comments() on line 99, this function is used to store the unsanitized values as WordPress comments.

Writing the patch

Luckily, we can keep this simple plugin simple and still make it secure.

All we need to do is remember to sanitize the $_POST variable values before sending them to addComments_add_comments().

90    function addComments_options_page() { 
91        
92        if( $_POST['action'] == 'addcomments' ) {
93            echo '<div class="updated settings-error">';
94            $id = ( $_POST['post_or_page'] == 'page' ? $_POST['pages_list'] : $_POST['posts_list'] );
95            $author = ( isset( $_POST['author_name'] ) ? sanitize_text_field($_POST['author_name']) : 'annonymous' );
96            $email = ( isset( $_POST['author_email'] ) ? sanitize_email($_POST['author_email']) : get_bloginfo('admin_email' ) );
97            $url = ( isset( $_POST['author_url'] ) ? sanitize_url($_POST['author_url']) : '' );
98            $ip = ( isset( $_POST['author_ip'] ) ? $_POST['author_ip'] : '127.0.0.1' );
99            echo addComments_add_comments( $id, $author, $email, $url, $ip, sanitize_text_field($_POST['comment']) ) 
100            . ' comments added to ' . get_the_title( $id ) . '</div>';
101        } ?>

You can see on lines 95, 96, 97, and 99 I add various sanitize functions as we set the values to $author_name, $email, $url, and the $_POST['comment'] variable as it is being sent to addComments_add_comments().

Writing the WAF rule

Web Application Firewalls (WAF) are best suited for blocking malicious requests, cross site scripting is best handled by sanitizing the values. For this reason, there is no recommended WAF rule for this Last Patch. Instead you should patch the code itself.

Conclusions

We learned in this post that the most prevalent WordPress (dare I say most prevalent Web Application) security bug Cross Site Scripting (XSS) can be addressed with a single function call. Simply sanitize the value of user inputs before storing them in the database. This is something every WordPress or Web Application developer needs to do to avoid this mistake.

This most prevalent security bug is best to be addressed in the application itself. It is a mistake to assume the framework or a web application firewall will take care of this for the developer. Instead, we can think that the developer owns the data and can be responsible when storing user inputs.

We also learned that mistakes are OK to make. Mistakes are how we improve ourselves, and fixing mistakes in code is how developers become better developers. The utmost mistake is assuming you will never make one.

Be humble, accept your mistakes and grow as a person.

The post Patching an XSS Security Bug in "add-comments" Plugin appeared first on Patchstack.