https://www.wpwhitesecurity.com/plugins-suspended-wordpress-repository-security-issue/
On 27th February 2020, at 9:34PM (CET) we received an email notifying us that our plugin WP Security Audit Log was “temporarily withdrawn from the WordPress.org Plugin directory due to an exploit”.
We submitted a fix on Friday, 28th February 2020, at 4:08PM. It only took us 16.5 hours to release the fix. We would have fixed the issue much earlier if this happened during our normal working hours (we are based in Europe), because we have a very good support response time (reference).
Our plugin was reinstated on Monday 2nd March 2020 at 1:00PM. That is 69 hours after we submitted the fix. It is important to note that it took the team so long to reinstate the plugin because of the weekend.
Why am I writing this?
I’d like to point out that I do believe that non-maintained plugins that have security issues should be suspended from the WordPress repository. Also, I have massive respect for the work that the volunteers at the plugin reviews team do, and I also take full responsibility for the reported security issue.
However, I do believe that reported security issues in maintained plugins might be handled better. Because of the way they are handled at the moment, the plugin’s reputation takes a big negative hit, and its users and their websites are put at risk. Therefore at the end of this post I highlight a few possible improvements that may help, and I think they should be considered. The idea is to always put less users at risk, and to lessen the impact on the plugin and developers.
In this post I also document all the details of what happened, and explain the low severity edge case vulnerability reported in our plugin.
What is the procedure to reporting a WordPress plugin security issue?
From the official guidelines in the Plugin Handbook:
Every attempt to contact the developer directly should be made before you reported the plugin to us (though we understand this can be difficult – check in the source code of the plugin first, many developers list their emails). If you cannot contact them privately, please contact us directly and we’ll help out.
What happened in our case?
We make it very clear in the plugin who develops the plugin. Just look at the plugin page on the repository and you’ll get an idea! We also make it very easy to contact us.
However, no one reported the security issue to us prior to the plugin being temporarily withdrawn from the plugins repository. So someone reported the issue to the WordPress plugins review team and they temporarily withdrew our plugin from the repository without any prior notification.
Before we dive into the whys and whats, and what is good, bad and what can be improved, let’s take a look at the plugin vulnerability and a short explanation of who we are.
What was the plugin vulnerability?
We have an install wizard in WP Security Audit Log to help users configure the plugin. One of the settings in the wizard allows you allow non-admin users to read the activity logs.
However, we made a mistake; we didn’t check if the user running the wizard was authenticated. Therefore unauthenticated users could run the wizard and allow another user or role access to the plugin’s settings. However, this is an edge case low severity issue.
Why is this a low severity edge case security issue?
The attackers could only exploit this if:
- the install wizard was never completed by the installer,
- the attackers already had a user / had access to a user on the website,
- The attackers can only gain access to the plugin’s settings and activity log.
By exploiting this security issues, the attackers do not gain access access to other privileges on the WordPress website. Therefore this exploit does not have any negative effect on the website’s behaviour and functionality itself.
Proof of concept
The POC is very simple. Visit this page as an unauthenticated user:
http://example.com/wp-admin/admin-post.php?page=wsal-setup¤t-step=access
This is the step of the wizard that allows you to specify who can see the logs. Search for the ‘_wpnonce’ nonce in the source of the HTML page, copy and insert it in the following curl command:
$ curl ‘http://example.com/wp-admin/admin-post.php?page=wsal-setup¤t-step=access’ -d ‘_wpnonce=INSERT-NONCE-HERE&wsal-access=yes&editors%5B%5D=subscriber&save_step=Next’
Once you log in as a subscriber and you will have full access to the plugin settings.
Why do we think this case was mishandled?
In the email we were sent, there was the following:
We do not close plugins lightly, and when it comes to security issues we attempt to balance the volume of users and the history of the developers with the severity and potential for damage of the report.
However, I think that our plugin was withdrawn too early. So far;
- When we had issues in the past we always addressed them within a few hours. We did the same this time.
- We always replied on time when the plugins review team got in touch.
- The security issue only affected our plugin (low severity) and it was an edge case.
- The security issue couldn’t be exploited automatically.
- The only damage the attacker could do was to change the plugin settings, read the activity logs, or purge them.
What do other developers think of such situations?
Most of us have already read an article, tweet or message on social media about similar issues. However, I wanted to find out for myself what other people, especially developers, think of this. I think this is important because there might be some things that I am not seeing.
To start off with, I sent an email to the person who identified the issue, thanking him for the responsible disclosure. His response was:
“Glad to see you quickly fixed the issue in the plugin. BTW, I noticed that the folks at wordpress.org closed it for a few days, that was a bit harsh and wasn’t really needed.”- Jerome Bruandet.
I have also done a small poll on the Facebook group Selling WordPress Products. Although this group is small, the majority of its members are plugins and themes developers. From the poll we can see that the developers unanimously agree that in case of low to medium severity issues, the developers should be contacted and given a chance to supply a fix and not withdraw the plugin:
How may these procedures be improved?
To the best of my knowledge, there are no documented procedures in place for when someone reports a security issue in a plugin. If this is the case, procedures such as the below might help the developers and also put less people at risk.
Contact the developers and agree on a plan of action before closing the plugin
The plugins review team can try to contact the developers and confirm the vulnerability before closing down the plugin. Developers should reply back with a plan of action, including a reasonable date for the fix.
If need be, the plugins review team can set a deadline. For example, developers should have between 12 and 24 hours to fix the issue. However, in some cases they might need more time, depending on the time zone they are in etc. Should the developers fail to respond, the plugin should be withdrawn from the repository.
Determine the severity and type of the security issue
This could be open to debate. However, someone with a bit of security experience can easily tell if a reported security issue can be automatically exploited, if it is an edge case or not, and what is its impact from the reported proof of concept (POC).
Check that the developers stick to the plan of action
There should be a sort of check in place to confirm the developers submit the fix on time and sticks to any other tasks included in the plan of action.
Withdrawing maintained plugins from the repository does not help
In the case of maintained plugins, withdrawing them from the repository does more harm than good. For example;
- You make it public that the plugin has an issue, most probably a security issue. This raises a lot of alarms and puts a spotlight on the plugin. This is also like inviting attackers, telling them that something in the plugin is possibly exploitable.
- It exposes the current plugin user base because all of a sudden, their websites became a target. Most of the users have no idea on what they should do, especially if the plugin’s functionality is core to their website and business.
- You increase the chances of delaying the fix. This is typically caused by lack of communication, or because of holidays and weekends.
One might argue that by withdrawing a plugin from the repository you are stopping the infection from propagating. However, if the security issue is of low severity, the exploitation cannot be automated, and the disclosure is responsible, there are no risks involved, or the risks are extremely low.
Disclaimer: This is not an attack
I’d like to point out that this is not an attack against the WordPress plugins review team or anyone involved in these processes. I honestly do respect their work and I know that what they do is done in good faith. However, there is certainly a place for improvement, like in every other system and process.
Many will probably tell me that if I want a change I should volunteer instead of writing this post.
I’ve been trying to join for quite some time; I’ve talked to several people at different WordCamps to get involved, and I’ve also been monitoring the Make WordPress plugins page for calls for volunteers. However, in the last few years they didn’t have any vacancies. When they needed help they added new members by invite only.
The post Should maintained plugins be suspended from the WordPress repository when there is a security issue? appeared first on WP White Security.
Source: Security Feed