Dec 12, 2017 3 min read

Responsible Disclosure, Responsible Accountability

Responsible Disclosure, Responsible Accountability

One of the most frustrating parts about finding and reporting security vulnerabilities is dealing with companies and organisations who either completely ignore the issue, or simply brush it aside.

Responsible Disclosure

Responsible Disclosure is the process of disclosing a security vulnerability in a responsible manner. So what does that mean? In the simplest form, it is the process of reporting a finding to the affected party, allowing them to rectify the issue before making the details about the vulnerability public.

I typically give a 3 attempt rule, meaning I will attempt to contact the party 3 times. If I do not receive an appropriate response acknowledging the issue, I will then make the details about my findings public. However if I do receive an appropriate response, I will work with the affected party to help rectify the issue. Only once has it been rectified (in an appropriate time period) will I publicly release the details about my finding.

Poor Response

I’d like to share my experience with 2 vendors which I felt weren’t very forth coming or responsive. My intention with this blog post is not to point fingers, so I will try anonymize the vendors as best possible.

Vendor 1

With this vendor I identified that most (in not all their servers) were supporting the weak protocol SSLv3 and weak cipher RC4. I won’t go into the details of each, but in 2017 both should be disabled on servers. It took me 3 attempts to obtain some form of feedback from the vendor over a course of weeks:

2017-12-12-2B18_37_25-Inbox-2B-25E2-2580-2593-2Bsean.wright7-2540googlemail.com_

I then requested a timeline, of which I received no response. After waiting for a few days I decided to make my findings public. Most worrying of all the issue of supporting SSLv3 was reported to them back in April this year. How many times have we come across an vulnerability which had been previously disclosed to the vendor?

Vendor 2

The second vendor was equally frustrating. Again it took me 3 attempts before I received any response.
What was most amusing about the exchange is that they some how managed to “fix” the issue without even knowing what it was. Not surprisingly the issue was not fixed.

2017-12-12-2B18_52_24-Inbox-2B-25E2-2580-2593-2Bsean.wright7-2540googlemail.com_

I have since responded with the details of 3 issues which I managed to identify.

Update 14/12/2017: The vendor did respond back and since have been fantastic and have already addressed 2 of the reported issues and are currently working on the last issue.

Responsible Accountability

I do not expect any compensation for my findings. If I did, I would have joined a bug bounty program. I simply want to make the Internet a safer place. A lot of  emphasis has been placed upon responsible disclosure, but little has been done in the way of making companies equally accountable when a vulnerability is disclosed to them. I would love to see an industry type standard which companies adhere to when vulnerabilities are reported to them. Which makes them accountable for the issue, and more importantly resolving the issue.

Typically I would imagine it would involve something like:

  • Timely, response to the initial communication of the finding, acknowledging the finding.
  • Expectations, set as to how long it will take to resolve the finding.
  • Transparency, being open about the finding including what measures have been put into place to avoid a similar situation again.

Conclusion

While a lot of effort is put into reporting security vulnerabilities in a responsible manner, there is sadly cases where equal effort (or in some cases, no effort) is put into acting accordingly to the reported issue. Companies need to realize that admitting a security vulnerability is not a sign of weakness. In fact, simply ignoring it is and there are countless examples where this has got companies into trouble down the road. Embracing and actively responding to security findings, including learning from, is a sign of a mature and responsible security stance.

Sean Wright
Sean Wright
Experienced application security engineer with an origin as a software developer. Primarily focused on web-based application security with a special interest in TLS and supply chain related subjects.
Great! You’ve successfully signed up.
Welcome back! You've successfully signed in.
You've successfully subscribed to Sean Wright.
Your link has expired.
Success! Check your email for magic link to sign-in.
Success! Your billing info has been updated.
Your billing was not updated.