Cross-Site Request Forgery (CSRF) Vulnerability in Deny All Firewall
It is a continuing bad sign for the overall security of WordPress plugins that so many security plugins have security vulnerabilities of their own. We ran across one such plugin, Deny All Firewall, due to our monitoring of changelog entries of plugins to keep customer of our service aware of vulnerabilities that were or are in the plugins they use. The plugin is described as:
This plugin examines your WordPress installation and allows you to inject rules into your .htaccess file which completely block access to everything except genuine site content.
In checking over it a bit we found a number of issues, from storing a log file in a way that anyone can access it, to the logging capability possibly being insecure, but we didn’t check further on that since part of it wasn’t working right. What we did confirm was that it would be possible for an attacker to cause Administrators to disable the plugin’s functionality without intending it, which is referred to as cross-site request forgery (CSRF).
The plugin registers it’s settings page to be accessible to WordPress users with the “manage_options” capability, so Administrators:
55 | add_options_page('Deny All Firewall Settings','Deny All Firewall', 'manage_options', 'daf_settings', array($this, 'daf_settings_page')); |
Access that page will cause the function daf_settings_page() in the file /deny-all-firewall.php to run. In that function is this code:
152 153 154 | if (isset($_GET['daf_remove']) && $_GET['daf_remove'] == 'true') { if ($this->daf_remove_rules()) { |
With that code, if the GET input “daf_remove” is set to “true” the function daf_remove_rules() runs and the plugin’s functionality is disabled. What is missing there is a nonce check to prevent cross-site request forgery (CSRF) protection, so an attacker could cause a logged in Administrator to send a request that does that without the Administrator intending to disable the functionality.
Due to the moderators of the WordPress Support Forum’s continued inappropriate behavior we are full disclosing vulnerabilities in protest until WordPress gets that situation cleaned up, so we are releasing this post and then leaving a message about that for the developer through the WordPress Support Forum. You can notify the developer of this issue on the forum as well. Hopefully the moderators will finally see the light and clean up their act soon, so these full disclosures will no longer be needed (we hope they end soon). You would think they would have already done that, but considering that they believe that having plugins, which have millions installs, remain in the Plugin Directory despite them knowing they are vulnerable is “appropriate action”, something is very amiss with them (which is even more reason the moderation needs to be cleaned up).
Update: To clear up the confusion where developers claim we hadn’t tried to notify them through the Support Forum (while at the same time moderators are complaining about us doing just that), here is the message we left for this vulnerability:
Is It Fixed?
If you are reading this post down the road the best way to find out if this vulnerability or other WordPress plugin vulnerabilities in plugins you use have been fixed is to sign up for our service, since what we uniquely do when it comes to that type of data is to test to see if vulnerabilities have really been fixed. Relying on the developer’s information, can lead you astray, as we often find that they believe they have fixed vulnerabilities, but have failed to do that.
Proof of Concept
The following proof of concept will disable the plugn’s functinality, when logged in to WordPress.
Make sure to replace “[path to WordPress]” with the location of WordPress.
http://[path to WordPress]/wp-admin/options-general.php?page=daf_settings&daf_remove=true
Firstly (and most importantly), thank you “Plugin Vulnerabilities” for indirectly alerting us to this bug in our plugin.
As you’ve mentioned, the plugin completely locks down a WordPress site so as to only serve content that exists rather than to allow hackers to scan a site for exploits (such as the one you have so proudly discovered).
We were alerted to this issue by WordPress Plugin Support on Saturday 22nd, giving hackers a full 24 hours head start on us to make use of the issue since you failed to notify us before publishing this post.
Luckily for the users of our plugin the exploit you have discovered would only turn off the plugins capabilities and wouldn’t cause WordPress to be compromised on its own; and we immediately released a fix.
In future, we hope that you contact plugin developers directly when you locate future issues so that they are able to create a fix before you carelessly tell the world how clever you are.
Please note that we have tried to contact yourselves via the contact form on your website prior to leaving this comment and would like you to comment further on …
“In checking over it a bit we found a number of issues, from storing a log file in a way that anyone can access it, to the logging capability possibly being insecure.”
… since …
a) The log file is not accessible when the firewall is enabled
b) When the firewall is disabled, the log file is not created
c) The log file entires are JSON encoded
So, over to you 🙂
Once again, thank you so much for your interest in our plugin. We feel that we have created something quite revolutionary and our clients who use it are already benefiting from decreased use of server resources and comfort that hackers continued efforts have been thwarted before they commence.
Kind regards,
Oliver
First off, you are making a lot of claims about your plugin that seem highly overstated at best and you are providing no evidence to support any of that, while claims like that call for strong evidence, preferably from independent testing. Considering how insecure the plugin has been, it seem unlikely that you really understand what you are trying to provide.
If you actually read our post you would have seen that the WordPress team actually caused you to be alerted after our disclosure. If you are going to criticize someone you might to know what you are talking about first. Also, the vulnerabilities already existed in the plugin, so our disclosure isn’t the problem, it is the vulnerabilities, which shouldn’t exist in a “quite revolutionary” security plugin.
We got your message, but haven’t hard time to get back to you since we are busy working on things for our customers, but quickly you don’t claim that the log file is not accessible if the firewall is not enabled. Also JSON encoding the file doesn’t deal with sanitization and escaping when using the data.
Thanks for your reply.
Claiming the plugin to be *so* insecure when in fact it was a minor flaw that would only have disabled its own capabilities (and only if a user with administrator access clicked on a malicious link) is *very* dramatic.
To quote WordPress support “Strictly speaking, even calls to SERVER should be sanitized … however we do not require that, as they are considerably harder to leverage.” Despite this, we are still going to implement $_SERVER sanitisation. And again, the log file isn’t created if the plugin isn’t enabled.
On the other hand (seeing as you would like evidence) lets take a look at what the plugin could do for your own website 🙂
A very brief look finds the following …
– Users exposed … you currently allow hackers to see your usernames (whitefirdesign) and seeing as your login page is wide open this isn’t very good at all https://www.pluginvulnerabilities.com/wp-login.php (we have another plugin, block-wp-login that you might want to use for that)
– Theme PHP exposed … https://www.pluginvulnerabilities.com/wp-content/content.php
– Plugin readme.txt exposed … https://www.pluginvulnerabilities.com/wp-content/plugins/fruitful-shortcodes/readme.txt
– Entire wp-content PHP exposed
Unfortunately, the plugin couldn’t do anything about you publicly displaying your WordPress version at the bottom of your theme but there’s only so much you can do with .htaccess 🙂
Now you will notice that you have the ability to sort out your own back yard before you make this comment public. Which isn’t a luxury you allowed us. Let’s hope you have the time to fix your site and the confidence to allow this post to be put public.
Kind regards,
Oliver
You really don’t seem to know what you are talking about security at all and didn’t respond to specific points we made, but we will respond to yours.
Your plugin has failed to implement basic security while it is a security plugin, if you really don’t understand why that is a problem, you shouldn’t be developing a security plugin.
We couldn’t find any WordPress documentation that matches the wording you are quoting, so we don’t know where got that, but if it was the team running the Plugin Directory, that would be another thing they have gotten wrong, since some $_SERVER variables come from user input, so they need to be sanitized, valididated, and or escaped.
Usernames are not considered a secret by WordPress and if you look at the top of website we have link to login, since we have customers that need to login. The security of logins is handled by using a strong password, not hiding usernames or login pages.
You linked to a file that doesn’t exist and the not found page for our website is shown, so there isn’t an issue there.
That isn’t a security issue.
Directory listing isn’t enabled, so we don’t know what you are referring to there.
Brilliant.
When you’ve caught up, we’ll be here to help.
Thanks for your input,
Oliver
What are you talking about? We are not the ones with a problem handling security here.