NinjaFirewall WP Edition’s Option Update Protection Is Embarrassingly Easy to Bypass

From what we have seen from testing WordPress security plugins against real vulnerabilities in other WordPress plugins as well other things, many of them don’t provide any protection against the types of threats they should be able to protect against. For the few that do provide some protection it is hard to recommend them because the developers greatly overstate the protection they provide, either because they don’t understand the limitations of them, they are lying about the capabilities, or a combination of both. In the real world that has led to websites being unnecessarily hacked.

One example of overstated protection is the plugin NinjaFirewall WP Edition. Nearly three years ago the developers of that had come across a vulnerability in a plugin and when disclosing that vulnerability they made this claim:

Alternatively, if your are using NinjaFirewall (WP/WP+ Edition), our WordPress WAF, you are protected against it.

When we did a test to see if security plugins would provide protection against that we found their plugin didn’t protect against exploitation. The explanation for that discrepancy appeared to be that the plugin provided protection if exploitation occurred the same way the original hacker had exploited it, but our testing involved exploiting it slightly differently.

Recently the developers of that have disclosed vulnerabilities where they made more broad based claims of providing protection. Here for example involved a disclosure of an option update vulnerability (that they referred to as privilege escalation vulnerability) in the plugin Travel Management :

Update as soon as possible if you are using version 1.5 or below.
If you are using our web application firewall for WordPress, NinjaFirewall WP Edition (free) and NinjaFirewall WP+ Edition (premium), you are protected against this type of vulnerability.

They provided nothing to back that claim up, which they should for such a broad claim, and it seemed likely they were overstating what they were able to protect against. In just a few minutes we are able to confirm that not only are they misleading people as to the protection provided, that the developers don’t even seem to have well thought out the protection they are providing.

Rule Based Protection’s Limits

To start testing things out we installed the Ninja Firewall plugin, a vulnerable version of the Travel Management plugin, and tried using our stand proof of concept test for that type of vulnerability, turning on user registration:

/wp-admin/admin-ajax.php?action=nd_travel_import_settings_php_function&nd_travel_value_import_settings=users_can_register[nd_travel_option_value]1[nd_travel_end_option]

The response to that request was:

Sorry [IP address], your request cannot be processed.
For security reasons, it was blocked and logged.

If you believe this was an error please contact the
webmaster and enclose the following incident ID:

One way detection of an exploit attempt there could have been accomplished is through a rule designed to catch the attempt to exploit this specific vulnerability. To test to see if that was what was going on we changed the relevant code in the Travel Management plugin to replace usage of “travel” with “travel2” and then did the same thing with exploit attempt request:

/wp-admin/admin-ajax.php?action=nd_travel2_import_settings_php_function&nd_travel2_value_import_settings=users_can_register[nd_travel2_option_value]1[nd_travel2_end_option]

The result was that we didn’t get the response shown above this time. That is significant because it means that the protection isn’t general protection against this type of vulnerability, but something specifically crafted for that vulnerability. That means that there won’t be any protection unless the developer of the plugin knows about the vulnerability and has crafted a rule for it. Is the developer good at that? Who knows, as they don’t seem to even acknowledge that limitation, much less provide evidence to show how they are dealing with that.

Considering that those most in need of additional security that a plugin can provide are also probably the most likely to have a targeted attack where the attacker find new vulnerabilities instead of relying on publicly disclosed vulnerabilities, that limitation should be clearly noted.

Bypassing Protection

There was a second layer of protection though, as we got this response:

NinjaFirewall: You are not allowed to perform this task.

We thought it might be based on the plugin stopping the updating of the specific “users_can_register” option when not logged in as Administrator. If true, that would seem to have an important limitation not warned about, which is that you could not realistically block updating all options that way since that would stop normally functionality of a WordPress website from occurring.

To get a better idea of if that was the case we tried to change a different option. In looking over the options table we noticed one of the last options was “nfw_options”, which based on the name would seem related to the plugin. When we tried updating that option instead we go this response:

Updated option “nfw_options” with 1.

So our hypothesis about it only being certain options being limited turned out to be correct, but it turned out that was more significant because doing that disabled the plugin. So when we tried changing the “users_can_register” option again the plugin no longer blocked the request:

Updated option “users_can_register” with 1.

So bypassing the protection directly against option updates vulnerability is easily bypassed. That the developers didn’t think of that seems to be in line with being willing to overstate the capabilities of their plugin, but it is out of line with something else the developer recently did.

Going Beyond What is Needed?

Last week we noticed what looked to be a possibly fairly serious security vulnerability being fixed in the plugin Woody ad snippets. While trying to get a handle on just what the impact was we warned our customers and everyone else of a related vulnerability that still hadn’t been fixed (and still hasn’t been fixed). It turns out the developers’ of Ninja Firewall had discovered the fixed vulnerability, but if you read their post they went to fair amount of effort to figure out how to exploit that and then disclosed it, beyond a level it seems was needed. You could make arguments in favor of that, but it is hard for us to see that as defensible when the developer doesn’t seem to have done nearly as much to test the security that their plugin provides.

Cross-Site Request Forgery (CSRF) Too

In further testing we found that the second layer of protection is in fact operative unless someone is logged in as Administrator.

Neither layer of protection is active for a logged in Administrator, which means that the firewall won’t stop the exploitation of the vulnerability through cross-site request forgery (CSRF) against Administrator, which would involve causing them to take actions they didn’t intend to. That is something that should be noted by the developer as well.