Welcome friend to the second edition of Patchstack Weekly Security Update for November 11th, 2021.
This week we will discuss vulnerability news, including the WordPress 5.8.2 Security release and highlighting a vulnerability reported by the Patchstack Alliance (formerly Red Team) this week.
I will chat about the difference between authentication and authorization as well and provide some tips for bug hunters and developers alike to better understand how it is handled in WordPress.
This week the WordPress core team released WordPress 5.8.2 which includes a Security bug fix. Looking into the bug tracker for more details I see that this release is not addressing a vulnerability fix like XSS or RCE, but more of a house cleaning security matter.
The WordPress core team removed an out-of-date certificate authority (CA) which expired a few weeks ago on September 30th, 2021.
This will correct an issue some sites were experiencing, where they were unable to connect to other servers over SSL due to this expired certificate, and it’s best to fix this before people start implementing dangerous workarounds like accepting insecure connections over validated secure connections.
In other news, we have been patiently waiting to release details for a vulnerability that could allow authenticated users to delete the entire database on sites running the WP Reset Pro plugin.
It has been over a month since the plugin developers have released their patch, we believe that has been enough time for site owners to update and secure their installs of the WP Reset Pro plugin.
We just released a blog post earlier this week detailing the Patchstack Alliance’s write-up on a vulnerability fixed in WP Reset PRO. This post is a worthwhile read to find out exactly, what went wrong in the code and how to patch this type of security bug as well. If you are a WordPress developer or want to spot insecure code during code review, please check out the write-up.
The developers for WP Reset Pro acted quickly when the Patchstack Alliance researchers reached out to the plugin developers who had a patch released within 24 hours and noted it clearly as a “Security bug fix” in the changelog.
Site owners running the WP Reset Pro plugin on their site should make sure they have upgraded to 5.99 or higher if they have not done so already.
Let’s talk about authentication and authorization, in that order, because that is the order they happen. First, you authenticate, then you check what the authenticated users are authorized to do, and you must do both.
Authentication vs. Authorization sounds a lot alike which may be why it is a common point of confusion, even in enterprise application development. So, let’s get into the differences.
Authentication solves the problem of identifying who is making this request to the application. Authentication confirms Identity.
Authorization, on the other hand, solves the problem of “now that we know who this user is, are they allowed to take this action?”. Authorization confirms Permission.
Back to authentication or identification: This is commonly done via an initial challenge, matching a username with a password being the most common, then maintained through sessions or temporary authentication tokens. Once persisted, your application can be sure it knows which user is interacting with the application.
So, now all you need to solve is “should we allow this user to take this action?” So, let’s go back to Authorization or permission.
Within WordPress, they use Roles and Capabilities to manage a list of capabilities a user is authorized or permitted to take. Each user account is assigned to a role, you may already know a few like Author and Administrator, but WordPress also supports custom roles. And each role is mapped to a list of capabilities users with that Role can take.
A full list of the default roles and capabilities included in WordPress core can be found here: https://wordpress.org/support/article/roles-and-capabilities/
So, now you know a user gets assigned a role, and a role has a set of capabilities or actions they can take. How do you look this up?
Luckily WordPress core made this easy, simply call the current_user_can( … ) function, In its simplest form, you can call current_user_can() and pass it a capability like current_user_can(“manage_options”), and the function will return true or false if the current logged in user has permission or authorization to manage the options table in WordPress. And that, in short, is authorization in WordPress.
Now, when should you check this?
Every time you are executing code that is protected, especially in requests to action hooked to functions that are handled by the WordPress API.
So, if you have added function as a hook using add_action((“hook_name”, “callback_function”) then within the callback_function is where you should be performing authorization checks using current_user_can().
Let me mention a common function or a gotcha in WordPress too. The function is_admin() sounds like it checks if the user is an administrator, and I have seen developers trying to use it in this manner before, but the is_admin() function only checks if the URI includes /wp-admin/ in the path, that is not authorization!
Plus, let us unpack this a little more: Even if this functioned how it is incorrectly assumed to work (is the user an admin?) checking a user’s Role is not checking that Role’s capabilities. So, in the end, if you are looking to check if a user is authorized to perform an action, please use current_user_can() are your go-to function.
By the way! It is also important to add a nonce check as well. But, we’re out of time, so that will be a topic discussed in a later episode.
Thanks go out to the WP Reset Pro development team who got that patch out in record time, that shows they know what they’re doing, they care about their customers, and are quick to address problems when they are reported.
Thank you to the WordPress core team for their time to remove the expired certificate authority.
Thank you as well to the researcher here at Patchstack who found and respectfully reported the issue in the plugin.
Together, developers and security researchers have made the WordPress ecosystem a tad bit safer, and thank you for staying with me to the end.
I will be back next week with more tips and news on WordPress security!
