During my years as a security analyst, I worked with many clients who were in a very difficult situation. A compromised website is never a pleasant experience, but there are a number of instances that strike me as particularly memorable:
The e-commerce site owner whose business was on the brink of disaster after having to pay Visa thousands of dollars in fines due to the presence of a credit card skimmer.
The food bank website that was infected and blacklisted by Google, unable to coordinate donations to help poor families in need in their community.
The web development agency that had dozens of clients yelling at it because a password compromised on a account associated with a a wrong choice of a WHM configuration caused their host to disable their entire server due to an overwhelming phishing infection.
Perhaps most of all: the benevolent soul who ran a shelter for battered and abused women who reported the theft of credit cards from people trying to donate to them to help keep the lights on.
Helping people get out of such situations is what reminds me that our work as security analysts has meaning. When someone’s entire livelihood is on the brink, it’s us they turn to, and we can confidently say we have their back. When a customer thanks us for saving their business, or even just getting their hobby site back up and running, it reminds us that behind every website compromise is a very real person facing a very real, sometimes at crisis level.
This brings me to the importance of responsible disclosure and why failing to follow this simple principle does very real harm to very real human beings.
What is Responsible Disclosure?
Responsible disclosure is reporting a software vulnerability to responsible developers in order to give them the opportunity to release a patch. The problem is made public only after responsible parties have had sufficient time to patch or correct the vulnerability. This is the opposite of full disclosure, which involves immediately making the vulnerability public, often with proof of concept that hackers can use to exploit it. Responsible security researchers will always find the best way to report a bug and exercise patience to ensure the public has a fix.
In the field of website security, the difference between a publicly disclosed vulnerability with no known fix and a situation where an update is readily available is night and day. It’s the difference between thousands and thousands of compromised websites on the 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 were going great
Throughout 2021, there were a few examples of very popular WordPress plugins that had some pretty nasty vulnerabilities. Thanks to the hard work and cooperation between security researchers and developers, the issues were fixed and the public was informed quickly afterwards. I am thinking in particular of WooCommerce and All In One SEO. Between the two software, there are millions of websites affected.
When it comes to critical security issues, I can’t think of better examples of how things were handled quickly and efficiently. If automatic plugin updates were enabled on your website, your website would have been fixed before you could even speak the words. “Have I been pwned?“. Other users could follow suit soon after, leaving attackers with insufficient time to build and operate a proof-of-concept on a significant scale.
Despite a brief scare, fallout was minimal, and security analysts and website owners slept soundly that night.
When things weren’t going so well
Back in 2014, popular premium website plugin RevSlider was the culprit of one of the biggest website malware campaigns we’ve seen to date. Rather than properly informing the public about the security issue and the available fix, the developer thought it best not to tell anyone and hope no one noticed. Soon after, the vulnerability was posted on some underground hacker forums. Chaos ensued.
The problem was compounded by several additional factors. Namely, that the slider plugin was provided with many premium themes, with countless people completely unaware that they even had the software present on the website. Also, being a premium (paid) plugin, it wasn’t as easy as just grabbing the fresh copy from the open source WordPress repository. This issue has plagued the website security ecosystem for years. This was, without a doubt in my mind, the most mishandled security incident involving WordPress since I started my fieldwork.
When things just… break
There are other examples of security incidents where responsible disclosure just isn’t possible and developers are scrambling to release a fix as soon as possible.
An example of this was the Specter 2018 vulnerability that affected Intel processors. It allowed private data to be viewed by attackers. A website could read data stored in the browser for another website, or even the memory of the browser itself. Given the ubiquity of these processors in servers and other computing hardware, the vulnerability was so severe that Intel had to release an immediate and very rushed patch.
This turned out to be a fundamental design flaw, and Intel had to redesign its processors to fix the problem. Patches for legacy CPUs caused severe performance drops and random, unexpected reboots, but that was of course preferable to uncontrollable data leaks of potentially private information to prying eyes.
Enter: the wreckers
We have discussed responsible disclosure in this article and what can happen when this principle is not followed. WordPress and other CMS platforms have a very simple and very effective method of reporting and dealing with vulnerabilities within the components available in their repository. The objective is to minimize risks and consequences. Just email them directly. They will contact the responsible developer, notify them and ensure that a fix is released as soon as possible. Once the patch is available, users are notified and encouraged to update, and users with automatic updates enabled need not worry at all.
Worse than the developers hiding the release of a security patch is the security researcher who outright dismisses the simple practice of responsible disclosure in favor of immediate and public full disclosure.
Making a vulnerability public with proof of concept (steps on how to exploit it) before alerting developers is like give instructions to attackers. This leads to very real, sometimes crisis-level situations for website owners and can sometimes personally benefit the security researcher as well.
It’s basically about providing an instruction manual for those who have no moral compass and are willing to exploit vulnerable people for money. This actively undermines the still fragile state of security in our online ecosystem and only serves to sow insecurity and chaos.
In conclusion
Sometimes security researchers report a vulnerability to a vendor who either fails to respond or refuses to release a patch for an extended period of time. This can be frustrating for researchers trying to do the right thing and can sometimes lead to public disclosure if they feel no other avenue exists. However, this is more understandable than going immediately to public disclosure without first giving the developers the chance to release a fix.
That being said, helping attackers is not security research, and website security is no game. Frankly, those who willfully and irresponsibly provide attackers with everything they need to hack websites are no better than the attackers themselves. This damages the reputation of computer security practitioners and generally sows mistrust among a vulnerable public.
Comments are closed.