On August 13, 2020, the Wordfence Threat Intelligence group finished investigating two vulnerabilities in Advanced Access Manager, a WordPress plugin with over 100,000 installations, including a high-severity Authorization Bypass vulnerability which could result in privilege escalation and web site takeover.
We reached out there to the plugin’s writer the very next day, on August 14, 2020, and received a reply within a few hrs. After providing the entire vulnerability disclosure, we obtained a reply on August 15, 2020, a patch have been released in version 6.6.2.
Wordfence Premium customers received a firewall guideline avoiding the Authorization Bypass vulnerability on August 14, 2020. Sites nevertheless running the free edition of Wordfence will receive this principle 1 month later, on September 13, 2020.
Affected Plugin: Advanced Access Manager
Plugin Slug: advanced-access-supervisor
Affected Variations: < 6.6.2
CVE ID: Pending
CVSS Score: 7.5(Higher)
CVSS Vector: CVSS:3.0/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
Fully Patched Version: 6.6.2
Advanced Access Supervisor allows fine-grained access manage, and has the ability to assign several roles to an individual user. If the “Several Functions Support” setting is allowed, the plugin is susceptible to authenticated authorization bypass and, in some instances, privilege escalation.
A low-privileged user could assign themselves or change to any role having an equivalent or lesser user degree, or any function that did not have got an assigned user degree. This may be done by delivering a
POST demand to
wp-admin/user profile.php with standard profile revise parameters and appending a aam_user_roles parameter fixed to the part they wish to use.
The reason this worked is that the
AAM_Backend_Supervisor::profileUpdate method that truly assigns these roles is set off by the
user_register actions, and didn’t work with a standard capability check.
add_activity('profile_up-date', array($this, 'profileUpdate'), 10, 2); add_action('user_sign up', array($this, 'profileUpdate'), 10, 2);
public functionality profileUpdate($id) $user = obtain_user_by('ID', $id); //save selected user roles if (AAM::api()->getConfig('core.configurations.multiSubject', false)) $roles = filter_input( INPUT_POST, 'aam_user_roles', FILTER_DEFAULT, FILTER_REQUIRE_ARRAY ); // let's be sure that the set of roles is array $roles = (is_array($functions) ? $roles : array()); $okroles=array_keys(get_editable_roles()); // prepare the ultimate list of functions that should be set $newRoles = array_intersect($functions, array_keys(get_editable_roles())); if (!empty($newRoles)) //remove all current functions and set new $user->set_function(''); foreach ($newRoles as $part) $user->add_function($role);
This meant that, if the ‘Multiple Functions Assistance’ setting was enabled, any user would trigger this technique when updating their profile. The
profileUpdate function would then determine if any functions were within the
Write-up parameter. If functions were present, after that it used the WordPress get_editable_roles function to find out if the user was permitted to put in a given role, and when so, granted an individual that part without performing any type of capability check.
By default, get_editable_roles returns all registered functions. However, the Advanced Accessibility Supervisor plugin added a filtration system to limit these functions in the AAM_Service_UserLevelFilter::filterRoles method. This technique looped through each authorized role and identified the role’s user level utilizing the
public perform filterRoles($roles) static $ranges = array(); // to speed-up the execution foreach ($functions as $id => $function) if (!empty($role['abilities']) && will be_array($role['capabilities'])) if (!isset($amounts[$id])) $ranges[$id] = AAM_Core_API::maxLevel($role['capabilities']); if (!$this->isUserLevelAllowed(true, $levels[$id])) unset($roles[$id]); return $roles;
AAM_Service_UserLevelFilter::filterRoles after that removed any functions with an increased user level compared to the current consumer from the set of roles the existing user was permitted to choose. Automagically, this worked reasonably properly; all built-in functions have an integral user-level attribute. Unfortunately, nevertheless, the user-degree attribute had been deprecated in WordPress 3.0.
This meant that when a role didn’t have a user-level attribute, or had a user-level attribute add up to or lesser compared to the logged-in user, the logged-in user could assign themselves compared to that role.
This was an issue in 3 possible scenarios:
- Roles lacking any assigned user degree. In case a role was made from scratch in Advanced Gain access to Manager, however, not assigned a consumer level, any consumer with subscriber-level accessibility could switch compared to that role.
- Cloned user functions. If a job was cloned from a preexisting role (for example, a contributor or writer) and assigned additional features, any consumer in the initial role could change to or assign themselves to the brand new role.
In any one of the scenarios, the low-privileged attacker may potentially switch to a job that allowed them to either directly dominate a site or even could be used within an exploit chain, based on which functions were configured.
Affected Plugin: Advanced Access Manager
Plugin Slug: advanced-access-manager
Impacted Versions: < 6.6.2
CVE ID: Pending
CVSS Score: 4.3(Moderate)
CVSS Vector: CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
Fully Patched Version: 6.6.2
Advanced Access Supervisor also allows customers to login through the WordPress Relaxation API. Sadly the plugin’s aam/v1/authenticate and aam/v2/authenticate Sleep endpoints were arranged to respond to an effective login with a json-encoded copy of most metadata concerning the user, possibly exposing users’ details to an attacker or low-privileged consumer. This included stuff like the user’s hashed password and their abilities and roles, along with any customized metadata that might have already been added by various other plugins. This may include sensitive configuration info, which an attacker may potentially use within an exploit chain. For instance, an attacker in a position to assign themselves a customized role using the prior vulnerability could look at which features were assigned in their mind, permitting them to plan the next thing of these attack.
What are Functions and Capabilities?
All WordPress sites require an administrator, a user who provides complete control on the site to make modifications and perform maintenance. Furthermore, an eCommerce web site would have to allow clients to get on keep an eye on their orders, and a information site would likely have to enable its journalists the opportunity to author posts, and may require an editor. In such cases, “administrator”, “editor”, “writer”, and “consumer” are functions.
Each of the roles includes a certain group of capabilities. For instance, an administrator could have the manage_options capability which allows them to make adjustments to a site’s choices, but it would end up being disastrous to permit a customer, as well as an author, exactly the same capabilities. Similarly, an author would want the ability to
edit_posts, however, not
edit_others_blogposts, and a person or subscriber shouldn't have these capabilities.
In many cases, a niche site owner may need more fine-grained manage over which users is capable of doing certain actions, so that they might work with a plugin like Advanced Entry Manager to generate custom roles because of their users. They might then assign the abilities they need those users to possess, this kind of as allowing a niche site designer the opportunity to
edit_theme_choices without changing some other site options.
In addition, many plugins add specific roles and custom capabilities. For instance, while “customer” isn't a built-in WordPress function, eCommerce plugins will define a particular “customer” role which has custom capabilities linked to viewing their purchase position and updating their deal with details, while prohibiting them from producing any changes to the website.
The capability to customize roles and capabilities using plugins is area of the power of using WordPress for a number of applications, including eCommerce, understanding management systems, membership sites, and many more. However, this expanded efficiency demands a greater focus on access control and features from online marketers.
August 13, 2020 - Wordfence Risk Cleverness finishes analyzing vulnerabilities.
August 14, 2020 - We to push out a Firewall guideline to Wordfence Premium customers to safeguard against privilege escalation vulnerability and offer disclosure to the plugin’s author.
August 15, 2020 - A complete patch is released.
September 13, 2020 - Firewall principle becomes open to sites utilizing the free edition of Wordfence.
In today’s write-up, we detailed 2 vulnerabilities within the Advanced Access Supervisor plugin, including the high-severity vulnerability which could allow lower-level customers to escalate their privileges. We strongly suggest updating to the most recent edition of the Advanced Accessibility Manager plugin, currently edition 6.6.2, as quickly as possible.
Wordfence Premium users have already been protected from this vulnerability since August 14, 2020. Sites still utilizing the free edition of Wordfence will have the firewall rule 1 month later, on September 13, 2020.
If you know a pal or colleague who's using this plugin on the web site, please forward this advisory in their mind to keep their websites protected.
Special because of the plugin’s author, Vasyl Martyniuk, for a fantastic and rapid reaction to our disclosure
The post High-Severity Vulnerability Patched in Advanced Access Manager appeared first on Wordfence.