Why You Need a Vulnerability Disclosure Program (VDP)

The world of vulnerability disclosure and research is really confusing, with lots of different opinions on what's right or wrong. No matter what you do as a researcher, someone is likely to say you're doing it wrong.

All you can do is carefully find your way through the unclear laws. If you discover something, try to handle it responsibly so it doesn't end up in bad hands. After all, the main goal is to keep people safe, isn't it?

Vulnerability Discovery

During a recent security assessment for a client, I had permission to examine all aspects of their online presence. As a part of that I chose to investigate whether they had any exposed S3 buckets or Azure storage accounts that permitted public file listing and access.

Luckily for my client, I didn't come across any buckets linked to them. However, during my investigation, I stumbled upon two buckets belonging to other companies, both loaded with sensitive data.

Vulnerability Disclosure?

Knowing about these vulnerabilities, am I now required, even though I have no affiliation with the impacted companies, to report these issues?

A frequent point raised is that reporters shouldn't even be aware of these issues. However, especially when it comes to this class of vulnerabilities, the counterpoint is that you don't need any specialized skills or to perform any scanning yourself to find them. Search engines like Gray Hat Warfare make it easy to locate exposed buckets by typing in a few keywords.

The purpose of this website is to raise awareness on the open buckets issue. - Gray Hat Warfare

For instance, a simple search for the term 'prod,' often short for 'production,' turns up 18,029 public buckets. I'm sure none of these buckets contain sensitive information /s.

Tale 1: The Gold Standard

When it comes to encouraging the public to report vulnerabilities to you (and trust me, you want to be in the loop on these matters), there are a few basics to follow:

1. At the very least, make a public security contact available.
   Look into publishing a security.txt file, this is so easy!
2. Confirm that you've received any reports, so the person reporting knows they've been heard.
3. Extend a simple 'thank you.'
4. Optional Bonus - Offer some form of recognition to the reporter, like adding them to a 'Hall of Fame', giving them kudos on a platform, or sending them some swag.

With permission from the affected, Tale 1 is about my amazing experience reporting an open bucket to Monash University.

Step 1, they publish a security.txt file. ★★★☆☆

Step 2 and 3, they acknowledged my report within 24 hours despite me emailing on a Saturday and thanked me! ★★★★★

Step 4, they invited me to put the report in Bugcrowd so I could get recognized for the report. ★★★★★ BONUS ★

They even kept me in the loop about the issue getting resolved.

So easy right? Why can't all vulnerability disclosures go this well.

Tale 2: The Sassy CIO

Note: For those who've already seen this saga on LinkedIn (follow us), to your potential dismay, I will not be disclosing the company name or those involved. The bucket is still open after all this time.

Proceeding to the next tale, let's now take a look at the worst vulnerability disclosure process I've ever experienced.

The affected company didn't provide any dedicated security contact details, leaving me with just their generic contact forms. Given this scenario, I decided to reach out directly to their CEO and CIO on LinkedIn.

To my complete astonishment and dismay, I received this response the following morning.

Did the other 2 consultants, just give up? or were they actually sales messages.

I guess they at least get 1 star for acknowledging my report within 24 hours? ★☆☆☆☆

To add to that amazing response, our sassy CIO also blocked me on LinkedIn. I never heard back from the CEO at all.

Amidst my confusion, I decided to ask my LinkedIn network about what I should do. As I should've expected, the internet just wanted to see the world burn. 😂

Getting a Third Party Involved

I don't usually involve a third party, but in this case, it seemed worth a try. The intent was to share enough evidence of the issue with this third party so they could verify it. Then they could approach the impacted company as a trusted intermediary.

Let's list out everyone I tried contacting and what their response was:

• I contacted 6 media outlets.
  • Only 1 responded who referred me to the ACSC.
• I contacted the ACSC.
  • I called their hotline to ask if they can help me with this, they referred me to submit a 'general enquiry' here with feedback type 'other'.
  • The ACSC then referred me to submit a OAIC privacy complaint.
• I submitted an OAIC privacy complaint.
  • I have yet to hear back anything from them (submitted 24 August) apart from an automated acknowledgement of contact.

Side note: OAIC's automated acknowledgement of contact PDF doesn't correctly fill out the date. Has this ever been tested by anyone?

All of that seemed like a dead end.

Troy Hunt - haveibeenpwned

As a final option, a friend recommended contacting Troy Hunt. To my relief, he offered to help verify the issue and attempt to elicit a response from the same individuals I had reached out to.

The end.

Or so I thought.

As I write this, it is now September 15th. My first message about this was sent to the affected company on August 20th. Their blob storage is still publicly accessible and I've moved on to working on other things.

Closing

In the end, the two tales show two sides of the same coin. The first story serves as an exemplary model of how to successfully handle such disclosures, demonstrating that collaboration with vulnerability researchers can help improve an organisation's security posture.

In contrast, the second story has mostly been a lesson for me in patience and empathy. Maybe our sassy CIO is actually bombarded with sales pitches similar to my message. 🤷