NinjaFirewall’s Rule For Vulnerability Doesn’t Really Add Much Protection

We recently looked at yet another example of the limited value that rules written for specific WordPress plugin vulnerabilities offered with the Wordfence Security plugin. But what about the other firewall plugin that has rules being written for it, NinjaFirewall? In looking at the latest rule added to that, we found rules for that can also be of limited value. This highlights the importance of general protection, as opposed to rules written for specific vulnerabilities. Something that both plugins are not focusing on enough, though, NinjaFirewall has done a better job on.

Here is the rule data for NinjaFirewall’s latest rule:

[why] => WP vulnerability 
[lev] => 3 
[ena] => 1 
[cha] => Array 
   ( 
	   [1] => Array 
		   ( 
			   [whe] => REQUEST:action 
			   [wha] => gsf_upload_fonts 
			   [ope] => 1 
		   ) 

   ) 

[cpb] => manage_options

That relates to something accessed through a GET or POST input named “action” that has a value that equals “gsf_upload_fonts.” One of our systems identified that the plugin Essential Real Estate has code that matches that. Checking the recent changes to the plugin, we found that the code was changed in the recent version, 4.4.0. Here is how the developer describes the issue being addressed:

Fixed: Prevent users with limited privileges on the site, like subscribers, from momentarily uploading malicious PHP files disguised as ZIP archives, which may lead to remote code execution.

Wordfence made a pretty different claim about that:

This makes it possible for authenticated attackers with subscriber-level capabilities or above, to upload arbitrary files on the affected site’s server which may make remote code execution possible.

In looking into this, we found that it was closer to the changelog description, but maybe even less of an issue than that.

What we also found is that NinjaFirewall’s rule doesn’t add any protection that updating the plugin would. The update for the plugin was released before the rule. So keeping plugins up to date is a better option than relying on a rule written for NinjaFirewall for the specific vulnerability.

Furthermore, looking at the underlying code, it isn’t even clear to us if it is even possible for an attacker to even access the code in normal circumstances. Here is the beginning of the function being accessed:

public function ajaxUploadFonts() {
	$nonce = isset($_REQUEST['_nonce']) ? sanitize_text_field(wp_unslash($_REQUEST['_nonce'])) : '';
 
	if ( ! wp_verify_nonce( $nonce, GSF()-&gt;helper()-&gt;getNonceVerifyKey() ) ) {
		wp_send_json_error( esc_html__( 'Access deny!', 'smart-framework' ) );
		die();
	}

The significance of that is an attacker would need access to a nonce, which is a unique value to prevent cross-site request forgery (CSRF). We couldn’t find where users with the Subscriber or other low-level roles would be able to access that. Maybe it can be found by them, we can’t say for certain. But if they can’t, then they are not able to do anything.

Wordfence provided no evidence that files could be persistently uploaded or that low-level users could access the needed nonce.

Plugin Still Insecure

What is rather problematic here is if low-level users can get access to the nonce, there is still other code in the file they can access, so there would still be vulnerabilities. Whether there is a vulnerability, the code is certainly not secure. We reached out to the developer about that on Monday, but so far they haven’t responded or released a further update.

No Rule Needed

Something else that is important to note here is that malicious file uploads as would be done if this was a vulnerability, can be stopped without writing a rule for this specific vulnerability. Our own Plugin Vulnerabilities Firewall stops exploitation attempts that way, and so does NinjaFirewall. That protection existed before the update for the plugin was released, which highlights where firewall plugins are actually best at providing protection.

Considering the possibility that this can’t really be exploited and that NinjaFirewall already provided protection, it seems possible the developer didn’t really look into this situation closely before adding a rule.