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