Why NinjaFirewall’s PHP Object Injection Protection Failed to Prevent Vulnerability in WordPress Plugin From Being Exploited
As part of working on our WordPress firewall plugin, we are doing tests to make sure our plugin’s protection works and to see what protection, if any, other existing plugins provide. While being able to show that our plugin is already providing protection that no other plugin provides is good for marketing the plugin, it isn’t the best result for trying to improve the plugin as we can’t learn too much from other plugins if they don’t provide protection.
In the latest test we did, we were surprised to find that no other plugin plugin provided protection, as it looked like the plugin NinjaFirewall should. The vulnerability being tested is a PHP object injection vulnerability we had discovered, and the default Advanced Policies settings for the NinjaFirewall made it look like it should provide protection against that type of vulnerability and this particular instance of it:
What we thought might explain the failure is that value to be blocked is Base64 encoded, with the proof of concept looking like this:
/wp-admin/admin-ajax.php?action=bin_soprop&atts=TzoyMDoicGhwX29iamVjdF9pbmplY3Rpb24iOjA6e30=
Changing the proof of concept to a use the non-Base64 encoded version of the value (which causes the proof of concept to not work) like this, caused NinjaFirewall to block the request:
/wp-admin/admin-ajax.php?action=bin_soprop&atts=O:20:”PHP_Object_Injection”:0:{}
So the Base64 encoding tripped it up, but elsewhere in the settings it is indicated that Base64 decoding is done by default, but returning to that, we found that only applies to POST input, not GET input, which is what the proof of concept involved:
We tried to send the Base64 encoded version as a POST input and NinjaFirewall also blocked that.
It is unclear why there isn’t even an option to apply that to GET input. We apply that decoding to both GET and POST inputs with our plugin, as GET inputs that are Base64 encoded are not just an issue with this type of vulnerability.
Also of concern is that by default the PHP object injection protection isn’t applied to COOKIES, which have been the user input at issue with plenty of PHP object injection vulnerabilities.
Review and Test Vulnerabilities
The big takeaway here, though one that we already focused on, is that you need to review and test many vulnerabilities to make sure that a firewall plugin’s protection is robust enough to actually be able to catch most vulnerabilities out there.