In the last 5 or so years of research we’ve found a substantial number of products with vulnerabilities in their supporting apps and infrastructure, as well as in the devices themselves. Some were low-impact, some were just curiosities, but many critical flaws exposing personal data and worse. We’re at the stage now where we’re making 5-6 disclosures a week to different vendors. The weekly disclosure record at PTP is 10!
We’ve found instances of children’s safety being put at risk, of devices and services that enabled spousal and domestic abuse, of physical security devices being completely undermined by their ‘smart’ components, of missing or roll-your-own crypto in use on transactional devices. Bear in mind that these are a just a sample of what we’ve seen.
Going through disclosure might be stressful for the vendor, but generally it ends well for all concerned, unless you’re Atrient of course and one of your staff is accused of assaulting a disclosing researcher. True story.
We haven’t yet been assaulted, but we’ve been threatened plenty of times.
Probably our favourite response happened just yesterday:
“So, normally, only if you have admin rights you can fondle with those files to cause a vulnerability”
Suggesting that if the users didn’t have local admin, there wouldn’t be a problem. We’ve never been accused of fondling yet, but hey!
So, without further ado, let’s have a look at some of the responses and replies we get from vendors when we try to start a healthy dialogue with them. Come on and play Disclosure Bingo!
Here’s a translation of what each entry means, in our opinion:
We have had no reports of our product being hacked before
We have had no idea if our products have been hacked before
Without a support contract, we cannot accept your report
Only existing contracted users could possibly find vulnerabilities in our product
Our normal users would never do that, it’s not a problem
We have predicted every possible use case and user action in advance. Yeah, right…
The product is end of life
Screw you, customer. Pay to upgrade and your vulnerability is fixed
Cease and Desist
Maybe if we threaten them, they’ll go away. Streisand Effect here we come!
<fingers in ears, la-la-la-la> maybe they’ll get bored
We’ve called the police
We don’t understand the law
We use military grade encryption
We haven’t got a clue about security, so will say something that sounds good
That is intended functionality
We are so bad at security that we designed vulnerabilities in to it
We know about that already, but we’re still shipping
Please don’t tell the FTC/DPA/ICO
We don’t consider that to be a vulnerability
We don’t have a clue what a vulnerability is
It was left in default configuration
We designed it so badly that most users struggled. What’s zero-touch secure config?
Who are you working for?
We’re so unethical that we couldn’t believe anyone would do anything altruistic for us
This limitation is documented and everybody is fully aware of it. We see no reason to fix it
AKA ‘It’s our customers fault if they get hacked’
The product is for internal network use only/meant to be air gapped
We decided to avoid building in defence-in-depth so that our margins would be higher
First, make it easy for researchers to get in touch. Make sure you have security@<yourdomain>.com email address functioning and monitored.
Publish similar contact data for your security team at www.<yourdomain>.com/.well-known/security.txt.
Make sure that your social media team know how to recognise, respond and escalate vulnerability disclosures.
Then engage the vulnerability reporter. Often, researchers just want a ‘thank you’, public credit or perhaps some swag if you’re feeling generous.
Work with a bug bounty program too.
Caution: don’t just say that you take security very seriously, demonstrate that you take security seriously. You will do your brand more harm by trying to keep a researcher quiet and protect your reputation than you will by taking swift corrective action to protect your customers.
Heard of the Streisand Effect? See what happens when you ask a researcher to sign an NDA…
Useful resources include: <https://www.owasp.org/index.php/Vulnerability_Disclosure_Cheat_Sheet>
There’s even and international standard! <https://www.iso.org/standard/72311.html>