In my years as a security analyst I have worked with many clients who were in very dire straits. A website compromise is never a pleasant experience but there are a number of cases that stick out in my mind as particularly memorable:
The ecommerce website owner whose business was on the brink of disaster after having to pay thousands of dollars in fines to Visa due to the presence of a credit card skimmer.
The food bank website who was infected and blacklisted by Google, unable to coordinate donations to help out poor families in need in their community.
The website development agency who had dozens of clients shouting at them because one compromised password on one account coupled with one poor choice of a WHM configuration caused their whole server to be disabled by their host due to an overwhelming phishing infection.
Perhaps most of all: the kind soul who ran a shelter for battered and abused women who was reporting credit card theft from the folks trying to give them a donation to help keep the lights on.
Helping people out of situations like that is what reminds me that our work as security analysts has meaning. When somebody’s entire livelihood is on the brink of disaster we are the ones they turn to, and we can confidently say that we’ve got their back. When a client thanks us for saving their business, or even just getting their hobby site back up and running, it’s a reminder that behind every website compromise is a very real person dealing with a very real, sometimes crisis-level situation.
This brings me to the importance of responsible disclosure and why not abiding by this simple principle brings very real harm to very real human beings.
What is Responsible Disclosure?
Responsible disclosure is the practice of reporting a software vulnerability to the responsible developers in order to give them an opportunity to issue a patch. The issue is made public only after the responsible parties have been allowed sufficient time to patch or remedy the vulnerability. This is the opposite of full disclosure, which is when the vulnerability is made public immediately, often with a proof-of-concept that hackers can use to exploit it. Responsible security researchers will always find the best way to report a bug and have patience to ensure the public has a fix.
In website security the difference between a publicly disclosed vulnerability with no known patch versus a situation where an update is readily available is night and day. It is the difference between thousands upon thousands of compromised websites on one hand, or very few at all on the other.
Let’s explore a few different examples and how they all played out in the real world.
When Things Went Swimmingly
Throughout 2021 there were a couple examples of very popular WordPress plugins that had some pretty nasty vulnerabilities present. With the hard work of and cooperation between security researchers and developers the issues were patched and the public notified promptly afterward. I am thinking, specifically, of WooCommerce and All In One SEO. Between the two pieces of software there are millions of affected websites.
As far as critical security issues goes I can’t think of any better examples of how things were dealt with promptly and efficiently. If your website had automatic plugin updates enabled your website would have been patched before you could even utter the words “Have I been pwned?“. Other users could follow suit shortly thereafter, not giving the attackers enough time to craft and exploit a proof of concept on any meaningful scale.
Despite a brief scare, fallout was minimal, and security analysts and website owners alike slept soundly that night.
When Things Didn’t Go So Smoothly
Back in 2014 the popular, premium website plugin RevSlider was the culprit of one of the biggest website malware campaigns that we had ever seen to date. Rather than properly notify the public of the security issue and available patch, the developer thought it best to just not tell anybody and hope that nobody noticed. Shortly thereafter the vulnerability was circulated on some underground hacker forums. Chaos ensued.
The problem was compounded by several additional factors. Namely, that the slider plugin was bundled with many premium themes, with countless folks totally unaware that they even had the software present on the website at all. Moreover, being a premium (paid) plugin, it wasn’t so easy as just grabbing the new copy from the open source WordPress repository. This issue plagued the website security ecosystem for years to come. It was, without a doubt in my mind, the most poorly handled security incident involving WordPress to ever occur since I started my work in the field.
When Things Just … Break
There are other examples of security incidents where responsible disclosure is simply not possible and developers are left scrambling to issue a patch in the shortest possible time frame.
The 2018 Spectre vulnerability that affected Intel CPUs was one such example. It allowed private data to be viewed by attackers. A website could read data stored in the browser for another website, or even the browser’s memory itself. Given how ubiquitous these CPUs were in servers and other computer hardware, the vulnerability was so severe that Intel had to issue an immediate, and very much rushed patch.
It turned out to be a fundamental design flaw, and Intel had to redesign their CPUs to accommodate the issue. Patches for existing CPUs caused severe performance decreases and random, unannounced restarts, but that was of course preferable to uncontrollable data leaks of potentially private information to prying eyes.
Enter: Wreckers
We’ve discussed responsible disclosure in this post and what can happen when that principle is not followed. WordPress and other CMS platforms have a very simple and very effective method of reporting and addressing vulnerabilities within components available within their repository. The objective is to reduce risk and fallout as much as possible. Simply email them directly. They will get in touch with the responsible developer, notify them, and ensure that a patch is issued as soon as possible. Once the patch is available, the users are made aware and encouraged to update, and users with auto-updates enabled need not worry at all.
Worse than developers hiding the release of a security patch is the security researcher who wholesale rejects the straightforward practice of responsible disclosure in favor of immediate and public full disclosure.
Going public with a vulnerability along with the proof of concept (steps on how to exploit it) before alerting the developers is tantamount to providing instructions to attackers. This leads to very real, sometimes crisis-level situations for website owners and can sometimes personally benefit the security researcher, too.
It is essentially providing an instruction manual to those with no moral compass willing to exploit vulnerable people for money. This actively undermines the always-fragile state of security of our online ecosystem and serves only to sow insecurity and chaos.
In Conclusion
Occasionally security researchers will report a vulnerability to a vendor who is unresponsive, or refuses to issue a patch for an extended period of time. This can prove frustrating to researchers trying to do the right thing and can sometimes result in a public disclosure if they feel that no other avenue exists. However, this is more understandable than going immediately to public disclosure without first providing the developers an opportunity to issue a fix.
That being said, aiding the attackers is not security research, and website security is not a game. Frankly, those who willingly and irresponsibly provide the attackers with everything they need to hack websites are no better than the attackers themselves. This harms the reputation of IT security practitioners and generally sows distrust within a vulnerable public.
