Today our Plugin Vulnerabilities Firewall stopped an attempt to exploit a recently fixed vulnerability in a WordPress plugin on our own website:

Looking in to that, we found a mess.

Repeated Failure to Secure the Plugin

The plugin being targeted was HUSKY from PluginUs.Net (RealMag777). Every single one of the last ten updates to the plugin had been an attempt to fix security issues according to the changelog:

1.3.6.6

• small fixes
• one security fix, thanks to Hiroho from wordfence.com

1.3.6.5

• 1 security fix, thanks to Dimas Maulana from Patchstack.com

1.3.6.4

• 1 security fix, thanks to Daniel Scheidt from vorwerk.de

1.3.6.3

• 1 security fix, thanks to shaman0x01 from wordfence.com

1.3.6.2

• 1 security fix, thanks to Rafie Muhammad from Patchstack.com
• 1 fix for WPML

1.3.6.1

• 1 security fix, thanks to Arkadiusz Hydzik from wordfence.com
• small fixes

1.3.6

• security fix, thanks to Richard Telleng (stueotue) from wordfence.com
• bunch of small fixes
• new features

1.3.5.3

• 2 security fixes, thanks to Wordfence.com
• 1 security fix, thanks to Patchstack.com

1.3.5.2

• 1 security fix, thanks to Dhabaleshwar Das from Patchstack.com
• 1 security fix, thanks to Krzysztof Zając from Wordfence.com

1.3.5.1

• 1 security fix, thanks to Yudistira Arya from patchstack.com

The vulnerability being targeted was only addressed in the latest version, so the previous 9 updates had failed to fully secure the plugin. (Based on the results of our Plugin Security Scorecard, it still isn’t properly secured.)

That insecurity is despite it being used on at least 100,000 websites and those being ecommerce websites (as the plugin extends WooCommerce).

The developer apparently doesn’t seem to think that repeatedly incompletely addressing the security problems in the plugin is an issue, as they recently added this to the page for the plugin on the WordPress Plugin Directory;

Q: What about security fixes?
R: We take this seriously and do them regularly

Exploiting It Doesn’t Work That Way

Based on what was captured in the logging when our firewall plugin stopped the attempt, it looked like what was being attempted to be exploited was fixed in the latest version of the plugin. So we set up the previous version in a test environment and tried exploiting it in line with the payload shown being blocked. The result returned was a page that said:

Stop!

The explanation for that was in the relevant code.

In the file /ext/by_text/index.php, the plugin makes the function ajax_search() AJAX accessible to those logged in to WordPress, as well as those not logged in:

52
53

add_action('wp_ajax_woof_text_search', array($this, 'ajax_search'));
add_action('wp_ajax_nopriv_woof_text_search', array($this, 'ajax_search'));

The first code in that function returns “Stop!” if a nonce check fails:

941
942
943
944

public function ajax_search() {
	if (!wp_verify_nonce(WOOF_REQUEST::get('woof_text_search_nonce'), 'text_search_nonce')) {
		die('Stop!');
	}

The attacker couldn’t have sent a valid value for that nonce check since that is generated by the plugin and we don’t even have that plugin installed on our website.

When we disabled that check, we got this as the result of recreating the attack attempt:

{“options”:[“”,””,””,””,””,””,””,””,””,””],”pagination”:{“pages”:1,”page”:1}}

Which isn’t what the hacker would hope to happen. What looks to have gone on here is that the hacker thought this vulnerability would allow viewing the contents of an arbitrary file, but it includes it instead.

The file the hacker specified is the configuration file for WordPress, wp-config.php, which contains, among other things, the database credentials for the database used by WordPress. If the hacker could see those, it could, in some circumstances. allow them to gain further access. That is what is referred to as an arbitrary file viewing vulnerability.

A local file inclusion (LFI) vulnerability, which is what was actually in the plugin, allows a file on a website to be included (or run). The wp-config.php file already runs whenever WordPress loads, so it doesn’t benefit a hacker for it to run again.

The fix for the actual vulnerability was to use the sanitize_key() function to limit what files can be included:

995
996
997

		$template = sanitize_key($template);
 
        $path = $this->get_ext_path() . "views/templates/{$template}.php"; //templates inside the plugin