The relationship between WordPress developers and security researchers has been strained for some time now. Recently it is so bad that vulnerability reporters are going rogue which is affecting site owners. In the past months we’ve seen multiple researchers drop 0-day information (vulnerability details with no current patch available) which has resulted in our security staff being in emergency mode to ensure plugins are getting updated quickly, before sites get hacked. In some rare occasions where sites get hacked before we can patch, we’re putting in even more time handling incident response and cleanup for every affected site.
This is not a healthy scenario for anyone involved. Developers are being rushed to produce patches, sites are getting hacked due to no fault of the site owners, security teams are putting in more time than normal towards remediation of hacks, and researchers are getting [bad] press over their actions.
Here are two articles from this week that in one shows a security researcher with great patience facing months of non-communication from the developers they reported a vulnerability to, and a second where it's shown a different security researcher has stopped being nice and is now choosing to go full disclosure before attempting to contact plugin authors about vulnerabilities:
- RCESecurity "About a Sucuri RCE ... and How Not to Handle Bug Bounty Reports" June 20, 2019
- ZDNet "Disgruntled security firm discloses zero-days in Facebook's WordPress plugins" June 17, 2019
This scenario the WordPress and Security communities have got themselves in is a net loss for everyone involved (except the hackers), and it’s really quite saddening. Pagely's Security Team has a strong background of doing the right thing in these cases, be it with reporting of vulnerabilities (including those in WordPress core and plugins) as well as received and triage vulnerability reports on behalf of others. We know that the process of reporting vulnerabilities can be a net-positive and does not have to go down the road that leads to sites being compromised.
Here we have four recommendations for Developers, plus an offer for Security Researchers and Developers alike.
These are our four recommendations:
1. Have a point of contact.
It would be surprising that one of the biggest hurdles for the security researchers may be simply finding out who to contact. The WP.org plugin repository understandably (for anti-spam and privacy reasons) does not include your email address or a contact form on plugin pages. Nor is it acceptable to publish details of a security finding in the plugin forums (this is the same as releasing the vulnerability since it’s a public discussion forum).
So take a minute to think. How do you want to receive security reports? Maybe include a security point of contact in the plugin’s readme/source files, or if you have a development website that you’re linking to from the plugin description page on WP.org, be sure to have either a generic contact form or specific page detailing instructions on how people can report security issues found in your code.
If you’re a development shop that has some funding, you also may wish to consider signing up for a bug bounty program like hackerone or bugcrowd, and use that as your point of contact.
What happens if a security researcher can’t find out how to contact a plugin author? Well, then they will reach out to the WP.org plugin team to act as liaisons to receive, triage, and report the issue to you, the developer.
Pro-tip: If the plugin team confirms a vulnerability, they will likely remove your plugin from the WP.org repo until you have a patch available.
2. Be appreciative.
Reading a report of a security flaw in your code base can bring up some negative emotions, especially if you’ve got your ego tied up in your code. Try to let any negative emotions slide away if they bubble up.
It helps to take a second before you start reading the report to imagine the reporting party as someone who already contributed multiple hours of their own time towards your project, free of charge. Treat them as you would someone who had a great idea or pull request that improved your code, not as a threat.
This is the step I see things break down the most. A developer gets, what they perceive as, a nasty email from a researcher. They take personal insult because they believe they’re being told their code is bad. Their reaction to this is to send an email maybe downplaying or demeaning the report which starts a negative downward spiral from where there is no positive outcome.
As a developer, imagine spending hours contributing to a project free of charge and when you unveil your improvements, the project lead acts dismissive or negatively towards your contribution. Would you feel comfortable contributing your time towards that project ever again? Probably not. Is it possible you may even have feelings of wanting to get even? Possibly.
Now imagine that contribution was a security finding? That security researcher has their means of getting even right there in the report they sent to the project in good faith. By making that same security report public, makes it an 0-day, sites get hacked, the project’s reputation is tarnished, and the developer still has to write and push a patch.
3. Communicate.
Don’t leave the reporter out of the loop while you work on a patch or review their report. Share your progress and timeline if you have one, even if it’s a long way off. Ask questions if you have any (some of these vulnerabilities are confusing the first time you read about them, it took me some time to really understand object injection and its risk).
If you inform the reporter you’re squeezed for time, or you’re having trouble understanding the issue, or maybe even just ask them their opinion of the proposed patch, sometimes they may offer to help.
Keep in mind the person reporting the vulnerability may have an internal timeline they assumed is sufficient (maybe 30, 90 or 180 days , but it's always an arbitrary timeline until both parties communicate their expectations) and if the researcher doesn't hear anything from the developer in that time frame, they may just report the vulnerability publicly so they can close the case and move on to finding more vulnerabilities. It doesn’t hurt to keep up communications, ask questions or share timelines and/or knowledge.
4. Transparency.
This last bit is for the users of your code. Be sure when you have a security release ready, you include a note in the changelog that the release contains a security related patch. Your users need to know that the version released addresses a security issue, so they know to update ASAP. Hiding or neglecting to include security notes from your code’s changelog, doesn’t mean the security issue never existed.
Neglecting to include a note that a version of the software includes a security patch is simply a disservice to a project’s users. If users don’t see there is a security patch in that release, then some will not bother to update their sites. Sites not getting security patches results in sites being compromised. The worst part is, during the incident response phase to clean up the mess the hack causes, it will be pointed out your plugin insecurity as the fault of the hack.
When Pagely customer’s experience a compromise we perform a detailed incident response which, is more than just a cleanup because, 99% of the time we will include details on what the initial attack vector was. It’s very common that if the cause of the hack was a plugin whose developer ignored or played down a security issue, the site owner chooses to remove the plugin from the site entirely. Understandably so, as the site owner feels betrayed and loses trust that the project’s developers will be honest with them about security concerns.
That’s the basics. I hope developers reading this take to heart some of the considerations. I believe nothing recommended above would harm a project’s reputation and, in fact, I would argue they improve the project’s reputation as being ran by mature developers who have earned their user’s trust.
For the few security researchers who may be reading this, especially if you agree with the importance of the above four points, here is our offer:
I know some of you have faced some difficulties when reporting vulnerabilities to the WordPress development community in the past. We would like to offer an olive branch in the form of assistance.
If you have had a bad experience reporting vulnerabilities to the WordPress development community (core, themes, plugins, whatever), and would like us to help, please reach out (contact us via the Pagely support contact form, and someone will route notification to our security team).
We will be glad to help you find the point of contact for a plugin (we have connections in the community) and even act as mediators, reviewing/confirming your report and reaching out to the plugin author on your behalf!
This would be a win-win. You can spend more time finding vulnerabilities and less time writing emails, while we help the affected project be more secure.
This offer has already been put into play, we helped Slavco Mihajloski just last week with reporting a vulnerability he found in NextGen Gallery. We would look forward to helping anyone else (both developers and researchers alike) who want to work towards a solution where vulnerabilities are patched, credit is properly attributed, and sites don't get hacked.
We hope that this dilemma can be addressed, hopefully our offer to help act as mediators will get both security researchers and WordPress developers away from the road that leads to 0-days being released and sites being hacked, and onto a road of collaboration and mutual understanding (and where hackers have to do their own damned work to find vulnerabilities in the WordPress ecosystem).
Original post was published by Pagely's Head of Security at https://pagely.com/blog/wordpress-developers-security-researchers/
Top comments (0)