Last Updated on 08/10/2020 by Hrithik V
On the 27th of July, a vulnerability was found in a WordPress plugin known as WP Bakery. This flaw enabled authenticated attackers with escalated privileges to inject malicious JavaScript in posts.
WPBakery page builder is the most used page builder for WordPress. It is a tool that allows site owners to create custom pages using drag and drop capabilities easily. Unfortunately, the plugin was designed with a flaw that could give users with contributor and higher-level roles the ability to inject ill JavaScript into pages and posts and also gave these users the ability to edit other users’ posts. The plugin explicitly disabled any default post HTML filtering checks in the saveAjaxFe function using kses_remove_filters();. This meant that any user with access to the WPBakery builder could inject HTML and JavaScript anywhere in a post using the page builder.
Even though WPBakery only intended pages that were built with the WPBakery page builder to be editable via the builder, users could supply the correct parameters and values for any post and access the editor which can be classified as a security issue as well as a general bug. This made it possible for contributors and editors to use the wp_ajax_vc_save AJAX action and corresponding saveAjaxFe function to inject malicious JavaScript on their own posts as well as other users’ posts.
| public function saveAjaxFe() { vc_user_access()->checkAdminNonce()->validateDie()->wpAny( ‘edit_posts’, ‘edit_pages’ )->validateDie(); $post_id = intval( vc_post_param( ‘post_id’ ) ); if ( $post_id > 0 ) { ob_start(); // Update post_content, title and etc. // post_title // content // post_status if ( vc_post_param( ‘content’ ) ) { $post = get_post( $post_id ); $post->post_content = stripslashes( vc_post_param( ‘content’ ) ); $post_status = vc_post_param( ‘post_status’ ); $post_title = vc_post_param( ‘post_title’ ); if ( null !== $post_title ) { $post->post_title = $post_title; } kses_remove_filters(); remove_filter( ‘content_save_pre’, ‘balanceTags’, 50 ); |
The plugin’s onclick functionality for buttons made it possible for an attacker to inject a JavaScript that can be executed with a single click. Contributor and author level users were also able to use the vc_raw_js, vc_raw_html, and button using custom_onclick shortcodes to add malicious JavaScript to posts.
All of these meant that a user with contributor-level access could inject scripts in posts that would later execute once someone clicked a button or accessed the page. As contributor-level users require approval before publishing, it is highly likely that an administrator would view a page containing malicious JavaScript created by an attacker with contributor-level access. By executing malicious JavaScript in the administrator’s browser, it would be possible for an attacker to create a new malicious administrative user or inject a backdoor, among many other malicious things.
How to tackle such vulnerabilities?
One of the best ways of keeping your site protected from cross-site scripting attacks against higher privileged accounts is by using Dual Accounts. Dual account control uses two accounts for any user that may require administrative capability. This can be done by using one user account with editor capabilities used to review and approve author and contributor posts and another user account with administrative capabilities for admin-related tasks like adding new users and plugins.
Doing so will limit the impact that a cross-Site Scripting vulnerability may have. When you access a page as a site administrator, any malicious JavaScript that an attacker injects can use administrative only functions like adding a new user or editing a theme file to further infect the site. By using a user account with only editor capabilities while editing, creating, and checking on posts created by lower-level users, an XSS exploitation attempt could be limited, as an attacker can’t successfully add new admin accounts or edit themes through an Editor account.
