NinjaFirewall Only WordPress Security Plugin to Provide Any Protection Against Exploitation of Unfixed Privilege Escalation Vulnerability

On July 22 a new version of the WordPress plugin uListing was released with a very concerning changelog entry:

fixed: Unauthenticated Privilege Escalation for Registration

In looking into that, we found that what that referred to involved restoring a security check that had been removed in an earlier version. That a security check existed and then was removed is a bad sign for the security of the plugin, but it gets worse. While looking into that, we found that the change only addressed part of the privilege escalation issue in the plugin and new version of the plugin didn’t otherwise address the other part. We contacted the developer the same day, asking how we could report that to them. They only got back to us on Friday, though hopefully that can be resolved soon.

We warned customers of our service that were using that plugin that they were still vulnerable. For those relying on other data sources for WordPress plugin vulnerabilities, they didn’t have that happen.

One of those, WPScan, only got around to warning about this five days later, but listed the issue as having been resolved:

Patchstack still hasn’t warned to even that level:

Warning about the vulnerability is one way to handle this, but is it possible for a security plugin to prevent exploitation? NinjaFirewall has a setting that indicates it might some provide protection against this exact type of privilege escalation issue:

Testing confirmed that it addresses the unfixed part issue with the proof of concept we created for it, though further testing showed that protection is limited, which we will come back to. There is also protection for the other part of the issue due to a rule written for that specific issue, but the protection against the unfixed part of the issue was done through general protection, which is what we are interested in.

At that point, we started working on creating our own general protection, which currently operates somewhat differently and is designed to hopefully to provide more robust protection, while also limiting unnecessary problems. Though that protection still needs to be tested against a lot more vulnerabilities to make sure we are delivering what we should be.

To see if any other plugin offers similar functionality that we should also look at while working on our protection, we tested all the other security plugins we currently include in our security plugin testing. The result was that none of them provided protection. You would hope that the developers of security plugins would be looking at what other developers are doing and building off of that, but other than us, they don’t appear to be doing that.

Also at that point, we checked to see if we could bypass the protection and we found we could. While the protection did prevent changing the role to Administrator or Editor, it didn’t prevent changing the role of the user from a Subscriber to a Contributor or Author. It also didn’t prevent changing the role to a custom one that contained capabilities exclusive to Editors and Administrators. Our protection is able to address blocking those changes as well.

Testing Procedure

For each of the tested plugin we set up an install of WordPress 5.8, installed version 2.0.7 of uListing and installed the latest version of the security plugin. We tried to enable any feature of the plugin that could possibly have an impact on stopping exploitation of the vulnerability. We didn’t set up any additional service connected with the plugins.

We used the proof of concept provided in our Vulnerability Details post for the unfixed part of the issue, in the exploit attempts.

The 25 plugins we tested include the security plugins listed in the Popular plugins section of the Plugin Directory and some others that look to be intended or marketed to prevent this type of situation. If you would like to see an additional plugin included in future testing, please leave a comment on the post or contact us.

Results

Only one plugin provided protection, NinjaFirewall. Our plugin had protection against this at the time of the testing, but that was built partly by testing against the vulnerability, so it would be misleading to list our plugin as having prevented exploitation.

In trying to bypass the protection of NinjaFirewall, we found that while the protection did prevent changing the role to Administrator or Editor, it didn’t prevent changing the role of the user from a Subscriber to a Contributor or Author. It also didn’t prevent changing the role to a custom one that contained capabilities exclusive to Editors and Administrators.

The full results are below: