New Service Vulnerability Disclosure Policy
The Wordfence team regularly discovers security issues with commercial services, such as WordPress hosting providers, that put their users at risk. In some cases, the issue is quite severe, putting thousands of websites at risk simultaneously. In these instances, our standard approach has been to contact the service provider directly, provide them with the details and work with them toward resolution. Lately these issues have become more common, so we’ve decided to formalize our approach going forward, updating our Vulnerability Disclosure Policy to specifically address these scenarios.
What Is a Service Vulnerability?
We define a service vulnerability as any issue with a technology service that represents an exploitable security risk for its users. We draw a distinction between service and software vulnerabilities, because in many cases, the service vulnerability is due to configuration issues instead of a software bug. For example, a WordPress host may set file permissions incorrectly, allowing an attacker to easily move laterally between sites in their environment. The hosting company may be running no vulnerable software while still opening their customers up to attack.
How Does Wordfence Discover Service Vulnerabilities?
Our Security Services Team cleans hundreds of hacked websites each month. As part of that service, they analyze the available server logs, configuration and other server information to try to identify how the website was compromised. This is really important, as it is the only way to be certain that they’ve closed the security hole the attackers used to hack the website in the first place. It is during this analysis that we occasionally discover security issues with hosting providers. In most cases, we will see a flood of site-cleaning cases immediately following the first discovery, all from the same host.
Wordfence Service Vulnerability Disclosure Policy
When the Wordfence Security Services Team discovers a security vulnerability in a service, such as WordPress hosting, we take the following steps to address the issue:
- Our research team verifies the vulnerability.
- We notify the service provider, using the following disclosure deadline, based on the day the service provider is notified:
- 90 days
- 14 days if the vulnerability is being actively exploited
- Where this service vulnerability directly affects a customer, we will notify that customer that they should consider changing hosting providers. We will not provide technical details of the service vulnerability until we disclose publicly. Instead, we use the following language: “We recommend at this time that you change hosting providers to resolve this security issue. We can not provide further details at this time, but have contacted the hosting provider directly about this issue.”
- The service provider releases a fix or the deadline passes, and we announce the vulnerability via our blog.
Why We Impose Disclosure Deadlines
When determining our approach to disclosure deadlines, we had to balance the needs of customers, service providers and the broader WordPress community. Let’s take a look at the perspectives we needed to balance:
Customer Perspective
As a customer of a service provider with a service vulnerability, I would want to know about the issue right away so I could take action. I also wouldn’t want additional attackers to be notified, increasing the odds that my site might be compromised, but if the vulnerability is being actively exploited, I would expect those involved to “drop everything and fix it!” I would be able to tolerate you keeping it confidential for a short time to allow the service provider reasonable time to implement a fix, but not for very long. As a paying customer, I would feel I deserved to know so I could take action to defend myself.
Service Provider Perspective
As a service provider with an issue, I would want a reasonable time to develop, test and deploy a fix. Many service providers have massive customer bases and complex infrastructure challenges. I may also have other high priority issues that I’m in the middle of handling, forcing me to make difficult choices.
WordPress Community Perspective
The broader WordPress community needs to know that, in general, when service providers discover security issues, they are dealt with quickly. We all need service providers we can trust, and we rely upon each other to keep the WordPress ecosystem safe and hold service providers accountable.
A Balanced Approach
We had an animated discussion about how aggressive the deadline should be for service providers. Where we landed is quite simple: if a vulnerability is being actively exploited, we expect the service provider to literally drop everything and fix the problem. If they do that, our deadline of 14 days should be plenty of time to implement a fix that they’ve properly tested and doesn’t break other things. If the vulnerability isn’t being actively exploited, 90 days is still reasonable for even the largest providers in our industry.
As always, we reserve the right to change deadlines based on discussions with the provider. Our interests are aligned with those of the community, and we will always do what we feel is the right thing.
Software Vulnerability Disclosure Deadline Change
As a result of this conversation, we also reviewed our policy for software vulnerabilities, and have decided to make a change to how we handle disclosure deadlines. In the past, we have always given the author a 30-day deadline to publish a fix. In the large majority of cases, the author posts a fix within a day or two. Unfortunately, some authors are not so responsive. Going forward, in cases where a software security vulnerability is being actively exploited, our disclosure deadline will now be seven days. We feel this is very reasonable, as fixing a security vulnerability in a piece of software like a WordPress plugin or theme is much easier than rolling out a configuration change to thousands of mission-critical production servers.
Conclusion
We take our role as the leading security vendor in the WordPress ecosystem seriously. We feel that these updates to our approach will benefit service providers, software authors, their customers and the broader WordPress community. We encourage other security researchers to adopt similar policies and invite you to reach out to us with any questions you have about implementing a similar approach.
Comments
10:02 am
I LOVE your updates and they have saved my sites a lot of grief. Thank you for this service!
1:54 pm
Thank you.
10:13 am
Love you guys! The best service I have come across ever. Love it love it
1:53 pm
Thanks Kristian.
10:18 am
Very reasonable and thoughtful solution. Hoping you'll expand to web site coverage outside of WordPress someday soon.
1:53 pm
Thanks. We have already expanded. Check out https://www.gravityscan.com/ for malware and vulnerability scanning for joomla, drupal, magento and many other platforms.
2:21 pm
Any plans to expand the service to include similar functionality to iControlWP or ManageWP? I'm already running Wordfence premium on all of my Wordpress sites. It would be nice to bulk apply the daily recommendations without clicking through and logging in to every site that needs an update. For frequently updated plugins, it's a time commitment.
1:47 pm
Considering it. Thanks for the feedback.
10:18 am
Excellent!!! keep up the good work.
10:19 am
Really informative. It's sometimes so easy just to see things from one angle so it's great to have the different perspectives. Sounds like you've come up with a really well balanced policy.
Also, I'd totally missed the fact that releasing information about vulnerabilities to users also means releasing that information to more people who then try to actively exploit that vulnerability!
12:59 pm
Ditto on your entire comment. I think understanding these different perspectives is important and helps us the customers from having unreasonable expectations. So glad the Wordfence folks are on top of this and keeping all of us as safe as possible. The service providers should thank them as well.
1:51 pm
Thanks Debbie.
1:52 pm
Thanks Sarah!
3:37 pm
The balancing act of arriving at a "fix' without advertising a vulnerability to more attackers in the short term, is a really hard compromise - but well thought out by Wordfence. Well done. Whilst trying to address the 'fix' the last thing that other customers would want, is to become targetted by an advertisement that a vulnerability now exists in the wild. But only up to a deadline point, as Wordfence has come up with., Nice.
10:20 am
Great update. Thanks!
10:26 am
How do you define "service provider" in the case where an organization is using collocated hardware, shared hosting, or a cloud provider to host customers websites? Does that go to the true hardware/network owner or the organization providing the service?
1:11 pm
Hi Dave,
Great question. It's rare for a single service provider to provide the entire stack at all layers of the OSI. We will contact the affected service provider directly e.g. if it's an AWS vulnerability and a hosting provider is using AWS, we'd work with Amazon directly. If it's a hosting provider's config, we'd work with them directly. We would also handle notifying other affected parties on a case-by-case basis.
The most common case we see is hosting providers who have an issue that they can resolve.
Mark.
11:49 am
Mark not that I would ever assume to quibble with your brainliness nor your Gorrillas with lazer hats that can fly... However, since I spent thousands of $$ at Clark College for a degree I never got in Data Networks and Telecom... I must whisper to your ear that the OSI model has not been the ipso facto accepted network model for about 20 years now,, the 7 layers has been lowered to 4 in the TCP/IP stack or the TCP layers for short.
Of course because it was the standard for so many old schoolers (cough, cough) and it's still widely mentioned today over the shorter but confusing TCP stack - I have chosen to forgive you for your agregious fau pax. :-)
(PS... please don't send your flying gorillas down to Vancouver)
1:46 pm
And I forgive your spelling of faux pas. It's not a mistake. OSI is still an excellent reference, used daily in conversations in ops and taught in current syllabi. e.g. "Layer 2 switching" "layer 3 attack" etc.
10:37 am
I agree about a deadline to fix security issue, but I find it very hard that you will advise a customer to change hosting provider, as you know a lot of software is having 'hidden' bugs, and we all know that there are many layers of software running on servers to provide 'secure hosting' My servers have cPanel with Cloud Linux and I keep everything up-to-date, but every day new vulnerabilities are discovered.
From all the hacked/compromised websites I ever fixed it was the fault of the customer by not updating their website and who ignored our emails to update their website, or simple the fault of a 'designer' who left things wide open.
Please re-consider this harsh decision and contact the hosting company before advising the customer to find another hosting company, I would feel hard done by, because I will have a lot of work and customer leaves because of your advise...
1:16 pm
Hi Nico,
I'm not sure you've understood what we're doing here. This does not apply to cases where an individual customer has a vulnerability. It also doesn't apply to software vulnerabilities. This relates to service vulnerabilities that exist, usually in a hosting provider configuration.
To give you a concrete example: We are currently aware of several hosting providers who have vulnerabilities in their configurations that cause customer sites to repeatedly get hacked. It is not the customer's fault. It also doesn't matter if the customer secures their site as much as they can. Their sites will continue to be hacked.
We find out about these because our site cleaning team keeps seeing infected sites from the same hosting provider. When we see a pattern like that, we investigate further and usually find a service vulnerability. We contact the host, sometimes they fix it, other times they don't. We needed to change our policy so that we can end up with a positive outcome: Either the host fixes it, or it becomes public after a time period and the customers can make an informed decision about securing their sites.
This is not a 'harsh' decision. It is exactly how Google's Project Zero works. They have a timeline, work closely with vendors and ensure that either issues are fixed or customers can make informed decisions. This is how we bring about positive change.
Regards,
Mark.
4:15 pm
14/90 is more than adequate time, thank you for being a leader and maintaining your stance as we should all continue to hold the WP community to the highest standards.
11:57 am
@Nico - I totally agree with Marc's comments above.
I had the "Pleasure" of managing a network of over 700 websites for a company and these websites were pretty important and I worked my butt off to secure and clean these websites and put them on mainWP which is a great management tool but I couldn't keep up with the sites being hacked. I tried to get the owners of the networks to change hosting but for some reason they wouldn't.
1 website hacked = bad
1 server with 20 or 30 websites on it hacked = catastrophe
I hate the idea of getting government involved in QA of hosting companies because you know they will take it beyond what's needed... but short of people like WF monitoring and reporting hosting companies, who should be taking the appropriate steps to do so before it gets to Mark's door... Web hosting is one of the few non regulated "self monitoring" industries left in the world. It needs watchdogs like WF keeping them honest.
10:56 am
Thank you SO much for the updates. Best to you and the entire staff! Happiest of Holidays to all!!!
1:52 pm
Thanks Ed.
11:15 am
It's a fair, balanced policy that everybody should be able to live with.
Thank you!
1:51 pm
Glad you feel that way Rich. Thanks.
11:15 am
It helps me sleep at night that you guys take your responsibility seriously and do your due diligence in keeping the community protected.
Keep up the good work.
1:51 pm
Thanks Mike!
11:39 am
I agree - WordFence has helped with avoiding attacks on websites built with WordPress at Nevada Website Design. Keep up the good work!...and thanks for keeping us up to date!
1:51 pm
Thanks!
12:06 pm
Kudos to the Wordfence team, guardian ninja angel heroes of the Wordpress blogosphere! Many, many thanks to you for your tireless efforts to make this digital world a safer, saner place for all of us... ??
1:51 pm
Thanks Bodhi, much appreciated.
1:29 pm
I provided a comment on Google Plus and re-Tweeted your article. Establishing guidelines and policies to make our community safer and less exposed, takes a company wide commitment. I plan to use your premium version on all my sites because I appreciate your actions so much.
1:50 pm
Thanks Gary.
3:46 pm
After having to fix around 20 sites that were hacked I discovered WordFence and it helped out tremendously. I love what you guys do and I have to say that from that day I recommended it to everyone. This disclosure policy change proves that I did the right thing. It is a very sensitive approach to please all sides involved while forcing a fix to be found. Great job!
5:43 pm
Wordfence has always been a completely trusted solution for many people security for their wordpress environments. Now more than ever; your solutions (both free and premium) help out the community at large and continues to increase confidence in all of your ethics and your solutions. Thank you for being there for the small guys all the way to the top.
Thanks,
T
10:17 pm
Greetings from Nairobi, Kenya. Hats off to the entire Wordfence team for doing exceptional work protecting the WordPress community everyday. Happy holidays to and yours. :)
10:45 pm
You wrote above, "if a vulnerability is being actively exploited, we expect the service provider to literally drop everything and fix the problem. If they do that, our deadline of 14 days should be plenty of time to implement a fix that they’ve properly tested and doesn’t break other things."
14 days seems a lot to me! Wouldn't you expect a faster turn-around time if they are truly dropping everything to fix the issue? I work for a small hosting company, and from that perspective, I can tell you that if we have 14 days to deal with an issue, we'll do just that. 14 days is enough time to respond to an issue without too much pressure. But if the deadline is 7 days, we'll just increase the priority / urgency, and make it our business to have the fix in place by then.
I understand that maybe a massive hosting company may need more time. So how about a policy that allows 7 days, with room for an additional 7 day extension if the hosting company can proove that action has been taken, and that there is a reasonable explanation why it needs more time... not just that they are letting it drag and need more time.
12:36 am
Hello Wordfence,
I have a question regarding this update. I guess you need to pay a subscription fee if we want you to contact the hosting company regarding vulnerabilites?
7:59 am
Hi Thomas, that's not really how this works. If we discover or are made aware of a service vulnerability we will take action on it. The most likely way we will discover them is while cleaning hacked websites for customers, but there is no explicit tie between subscription fees and our interest in pursuing a service vulnerability.
3:39 am
Thank you for all you do to make the Internet a better place to live, work and play. Keep up the great work!
7:09 am
Have you published a disclosure list of SPs that have ignored your findings?
1:46 pm
Not yet. Tick tick.
8:45 pm
Having formal SOPs and guidelines is a must, and I think you’ve struck a good balance here. Of course, these are living topics and should be constantly evaluated because, as you know the security landscape always changes. I don’t trust hosting providers for some of these reasons (among others) and self-host — I know exactly how my infrastructure is laid out and how my configs are set up. I can also easily maintain my network and servers. Because of this, I’ve found that my environment, as a whole and its individual parts, is tighter and more secure than my bank’s systems. Thank you for an awesome product, you are providing an extremely valuable service!
1:48 am
I wanted to scroll down to read the comments on my Xiaomi phone but my finger accidentally thumbed this post a 2 star rating. I'm so sorry! And I can't change it, no matter how I tried to press the 5th star. (I don't know why! T_T).
You guys deserve 5 stars for all the work you do. Just wanna explain this, in case you wonder who is this idiot for the 2 stars. LOL.
8:31 am
LOL Sharon! No worries at all, but you are not an idiot - we've all tapped something we didn't mean to on our phones! Thank you so very much for the kind words, though, we've shared them with the rest of the team, and it made us smile. :)
9:38 am
Thank you for your wonderful product. And if you want my opinion, I like the change to seven days. Thirty days is way too long to wait for an unresponsive creator. Thank you.
3:49 am
Great stuff Mark! Personally, I think you’re being to generous with your deadlines.
I had an outage on three of my sites (one for at least six hours) there has been no explanation even though a ticket was created and all outage reports (40) sent to my host.
Like most people, I update my plugins and themes as soon as I get a WF notice or if I’m in the back ends at the time.
All must play a part Webmasters, softW/plug-in provider and hosts. Generally it is the lack of pro-activity that makes us all vulnerable. Hosting Providers do need to do more.
Well done Mark, the Wordfence Team and of course Gravity Scan!
Respects, aye
M