This post is about the realities both good and bad that come with the responsibility of reporting vulnerabilities.
The long days of summer are gone, fall has faded away and winter is upon us… reflecting back over the past months the Pagely security team spent some of those days uncovering and reporting a number of unreleased exploits (or 0days) being used against our customers’ sites. It’s just part of the job. When securing sites we see what vulnerabilities attackers are using and how they work, and as an extension of that task, we make sure plugin authors are notified about the vulnerability so they can apply a patch.
It’s a fantastic feeling when we see an actively targeted vulnerable plugin getting patched and secured, but that feeling only comes after the patch gets applied. Just like the feeling of the first fall colors coming in, summer must heed to fall, to allow the shorter, cooler days to prevail. If we had 365 days of summer, then the world would be a barren wasteland. Much like the seasons, vulnerability reports need to be handled swiftly, before the users of the software get burned by attackers.
The time spent waiting for the patch can be stressful, commonly we implement a work-around for our customers (via a WAF rule, hot-patching the plugin’s code, or other methods) so our bases are covered. It is stressful because we know that our customers are just a fraction of a plugin’s total user-base, and many other sites on other hosts are being successfully compromised by the same attack. We end up in an awkward position when the plugin authors don’t act on our reports. Knowing that sites are actively being compromised and the person responsible for the plugin is not taking action is dreadful.
Over the summer months, we watched as that exact scenario played out. Here is what happened from our view:
Mid-May this year we identified an attack targeting a popular plugin. We dissected the attacker’s actions and confirmed that the plugin was in fact vulnerable to a severe vulnerability (allowing attackers to upload/execute any code they wanted onto a site). We first made sure we implemented security measures to protect our customers using the affected plugin, then reported our findings to the plugin author.
We gave the plugin author our standard 30 day disclosure contingency with the report, which came and went. Politely, we did not go public with the vulnerability information, as we didn’t want to upset the author who was very nice in their replies promising they were working on it… But, however nice they were, there was no patch in sight. Weeks, then months passed, with us seeking an update from the author, but the only response we heard was that they had not implemented anything to address the problem.
In the end, the patch came late in August (almost 3 months since our initial report) and only after someone made a post to the plugin’s public support forum reporting that their sites had been hacked due to the vulnerability in the plugin. The thread was full of people sharing that they had been compromised due to the same vulnerability.
And here we sat, knowing the whole summer that this vulnerability existed, that sites were being targeted on other hosts, and knowing that the plugin author was aware but unable to implement a fix. It was horrible reading that forum thread, all those sites compromised, and we knew that it could have (nay, should have) been averted.
We learned from this experience that protecting our customers but staying silent when active attacks are targeting sites is a selfish action. We felt terrible, the plugin author called our bluff on public disclosure. Our being too nice, not wanting to rock-the-boat with the author had lead to a negative outcome for the plugin users. Even though Pagely customers were not affected (we reached out and spoke with each of you about the issue, and kept you updated as we knew more information.) it’s still terrible to be aware that site’s were being compromised for months after we notified the plugin author.
Because of that, we’re formalizing our vulnerability disclosure process.
All future vulnerability findings, when we identify they are being used in active attacks against sites, will be publicly disclosed 30 days from the reporting date. With no excuses. We will also begin to report these vulnerabilities here on our blog, with further details such as disclosure and patch dates instead of just through channels like wpvulndb.com.
You may say “public disclosure allows more attackers to be aware of the vulnerability!”, but the cases we’re reporting already have plenty of attackers actively targeting and compromising sites with the vulnerability in question. In the case above, the public exposure appears to have encouraged the plugin author to implement the patch. Public disclosure can also be used by site owners, so they know to remove or disable the plugin until the patch is available.
You may think that this is a naming and shaming campaign, but it’s far from that. We will only report the facts on these blog posts with no bias, nor shaming nor name calling. Plugin authors who quickly apply security patches will have their time-to-patch published and show that they prioritize and address an active threat for their plugin’s users. If you’re responsible for code and are slow or unwilling to apply a security patch to protect your users from active attacks, well, maybe that is useful public knowledge. But, I hope it never gets to that.
In the end, our goal is continue to uncover active attacks and 0-day vulnerabilities in plugins, to continue to protect our customers, but also now inform the community of these vulnerability findings and be transparent about the process. In short, Pagely’s security team will help everyone from plugins authors to site owners (even on other hosts) know “Pagely has your back.”
Want to follow the disclosure feed from Pagely? Just subscribe to our blog feed the whole deal, or just the Security posts.