Multiple Vulnerabilities In Brizy Page Builder Plugin Allows Site Takeover

The Wordfence Threat Intelligence team has responsibly disclosed multiple vulnerabilities on Brizy – Page Builder, a WordPress plugin installed on over 90,000 sites.

The research team found traffic indicating that a vulnerability might be present in the Brizy – Page Builder plugin, though it did not appear to be under active attack. This led the team to discover two new vulnerabilities as well as a previously patched access control vulnerability in the plugin that had been reintroduced.

Both new vulnerabilities could take advantage of the access control vulnerability to allow complete site takeover, including a combination that allowed any logged-in user to modify any published post and add malicious JavaScript to it, as well as a separate flaw that allowed any logged-in user to upload potentially executable files and achieve remote code execution.

The Brizy – Page Builder plugin used Brizy_Editor::is_administrator and Brizy_Editor_User:is_administrator functions for a wide variety of authorization checks and any user that passed one of these checks was assumed to be an administrator, effectively bypassing almost all of the other capability checks used in the plugin. Unfortunately, due to a logic flaw, being logged in and accessing any endpoint in the wp-admin the directory was sufficient to pass this check due to the use of the is_admin() function for authorization checking.

public static function is_administrator() {
 
    if ( ! is_user_logged_in() ) {
        return false;
    }
 
    return is_admin() || is_super_admin();
}

This meant that all logged-in users, even subscribers, were allowed to modify any post or page that had been created or edited with the Brizy editor, even if it had already been published. This logic flaw was identical to the one patched in version 1.0.126 and was reintroduced in version 1.0.127, though only Brizy_Editor::is_administrator existed in versions prior to 1.0.127.

While this vulnerability might only be a nuisance on its own, allowing attackers to replace the original contents of pages, it enabled two additional vulnerabilities that could each be used to take over a site.

While the Brizy – Page Builder plugin does not offer a direct way for lower-privileged users such as contributors to add JavaScript to page content, it was possible for a lower-privileged user to modify a request sent to update a page via the brizy_update_item AJAX action by adding JavaScript to the data parameter. The added JavaScript would then be be executed if the post was viewed or previewed by another user, such as an administrator.

Thanks to the authorization check vulnerability, even the lowest-privileged users, such as subscribers, could add malicious JavaScript to any page, allowing them to take over a site. JavaScript running in an administrator’s session could allow an attacker to perform actions such as adding a new administrative user, escalating the privileges of an existing user, or adding backdoor functionality to existing plugin or theme files.

While exploiting this as a subscriber-level user did require submitting a request containing valid hash and editor-version parameters, these are echoed out on dashboard pages accessible to subscribers. The only parameter an attacker would need to guess when modifying a page was the dataVersion parameter, an incrementing integer starting at 1 which could easily be guessed in seconds with a few repeated requests.

Thanks to the authorization check vulnerability, it was also possible for subscriber-level users to upload executable files to a location of their choice using the brizy_create_block_screenshot AJAX action.

A malicious user could provide a filename of their choice using the id parameter, and populate the file contents via the ibsf parameter, which would be base64-decoded and written to the file.

While the plugin appended .jpg to all uploaded filenames, a double extension attack was also possible. For instance, a file named shell.php would be saved as shell.php.jpg, and would be executable on a number of common configurations, including Apache/modPHP with an AddHandler or unanchored SetHandler directive. An attacker could also prepend their filename with ../ to perform a directory traversal attack and place their file in an arbitrary location, which could potentially be used to circumvent execution restrictions added via .htaccess.

By supplying a file with a .php extension in the id parameter, and base64-encoded PHP code in the ibsf parameter, an attacker could effectively upload an executable PHP file and obtain full remote code execution on a site, allowing site takeover.

We strongly recommend updating to the latest version available, 2.3.17, as soon as possible.