What does "Responsible" mean for Vulnerability Disclosures?

If a security issue is identified, how much effort should be spent to responsibly disclose it? What if the problem is found with several different companies — should you wait for all of them to acknowledge or to fix the problem? (What if it is a problem that will happen again and will be found again periodically?)

In early November, we identified a type of security problem while doing some unrelated research. We later read some papers and articles that discussed the security vulnerability from a different point of view but with few details and no examples about our angle. We developed some tools and techniques to further find more examples. The vulnerability varies depending on the setup, but in some cases is very critical. We planned to report about the vulnerability with examples this week, but due to world-wide events and communication difficulties, this will be postponed. This article will discuss what responsible vulnerability disclosure policy means. We look forward to hearing your opinions and advice.

Beginning in November we began attempting to contact 23 companies to report the vulnerability. Here are the types of contacts:

SOA RNAME and Emails

For near 37 years, it has been documented there should be a responsible person associated with each domain to resolve problems (see RFCs 881, 882, and 883). The DNS SOA resource record's second field, as also defined in RFC 1035, "specifies the mailbox of the person responsible for this zone." (Our DNS audit service checks for its sanity.) Also see RFC 1033 which also suggests complaining publicly if you are have problems caused by someone's server.

RFC 2142 suggests using POSTMASTER@domain and HOSTMASTER@domain for the SMTP and DNS services, respectively, and ABUSE@domain and TROUBLE@domain. We didn't try these names specifically unless they were listed as a SOA RNAME.

We attempted emailing several companies using their SOA RNAMEs. We also tried some SOA RNAMEs for domains of parent companies (if we knew if the vulnerable domain was a subsidiary for example). We also searched websites for the companies attempting to find technical contacts. Many emails bounced. Even if the SOA RNAME is a point of spam, maybe companies could have an autoresponder that indicates a way to contact.

Sending emails took more time that expected. SenderBase, Office 355 server rules, and other mail filtering rejected multiple mails, which caused manual effort of going to sites, using captchas, submitting for delisting or to allow emails, responding to automated emails, etc.

Using emails resulted in only a few companies getting fixed. Some didn't even acknowledge the email. Some had autoresponders, such as "Someone will contact you as soon as possible based on the priority of the issue and current situation."

Some of the emails were sent with links to artifacts and examples from our research, so we can know at least when the URLs were followed (by a human or by a tool like "urldefense.com").

It is nice that a few companies provided some gratitude: "Thanks for taking the time to let us know" and "... we immensely appreciate the time and energy you've put into reaching out to us about this." Even the simple "Thank you for your inquiry" while confusing was much better than no acknowledgement.

Contact Forms

We attempted to use contact forms and support forms on websites. We asked for contact information for reporting security vulnerabilities. In some cases, we simply explained the problem. We received some auto-response emails for some. And for some it was just silence.

One company used Zendesk for customer support. We reported the issue. The ticket was acknowledged and the vulnerability fixed after two days.

Disclosure Procedures

We found that only a few of the companies has documented disclosure procedures. These led us to HackerOne and BugCrowd as discussed below. Some companies had webpages about vulnerability disclosures but didn't provide any contact details for actually reporting to them.

HackerOne

One Fortune 500 company used HackerOne for reporting a vulnerability. We used the form to submit and signed up for an account. On the same day, we received a note:

We have evaluated your submission and validated the vulnerability that you've reported. We are investigating next steps. Thanks again for your submission.

Twenty-two days later and we received no more communication, so we updated the report. We were quickly thanked again and told they were still investigating the remediation and prevention steps. Within two days, they asked for confirmation about the vulnerability's current status. It was fixed. That HackerOne process took about 24 days. (That same company though we had attempted contacting with several emails months earlier.)

HackerOne also has a directory listing various companies including some that don't have "known guidelines". They provide a form for requesting disclosure assistance. We submitted three more reports using their "assistance" form. Twelve days later they were set to "triaged" state and we received a note for each: "This appears to be a legitimate issue." They thanked us and said they will try to reach out to the company. "The next steps of the process may take some time." No further success with that, but we are still waiting. (We also tried contacting these companies by email, Twitter, and LinkedIn.)

BugCrowd

We had a S&P Global 100 Bank to report to. They had a responsible disclosure webpage which has a form to submit the vulnerability via BugCrowd. We submitted the issue and created an account there. We were thanked two days later by BugCrowd and asked for a proof-of-concept. Discussions went back and forth for 21 days. The company chose not to fix the problem and the issue was closed and marked "Won't Fix." Maybe we couldn't explain the vulnerability good enough for them. (The same type of issue was understood and fixed by another company via BugCrowd as follows.)

We also had a Fortune 500 company to report to that also has a responsible disclosure policy webpage and used BugCrowd. We submitted the vulnerability. We explained the issue a little better including linking to a third-party paper about the scenario. We received a thank you acknowledgement the same day. It was triaged six days later. Six days later (about 12 days total), the problem was fixed and the company rewarded a US$200 bounty (and some points). For some reason, BugCrowd marked it as "Unresolved" (even though it was fixed, we were rewarded, and an email said "This submission has been accepted as a valid issue. Congratulations!").

Social Media

We searched for CISOs and security contacts for several companies. We found some names and attempted to use LinkedIn to message them via the connect form. No luck as of yet. (We didn't use the LinkedIn message service, but in the past the commercial service didn't help us.)

We also attempted to tag companies via Twitter. We only had one contact us back with an email contact address. Their problem was quickly fixed. None of the companies allowed messaging. We also found some individual accounts, but only one allowed Twitter messaging. The individual messaged back with an email to use. Emailing that generated an auto-response. (Problem not fixed yet.)

Taking Control

We could have used the vulnerability quickly in some cases to immediately draw attention. We chose not to.

Responsible Disclosure

So again, we wonder, how much effort should a researcher make to report vulnerabilities? Some researchers find that only half or less of their contacts remedy the problems. In our specific case, we have six companies currently fixed out of 23 (with two others in real contact and one rejecting it). We have spent significantly much more time reporting each issue again and again via different mediums than we did for finding the vulnerabilities themselves. It has been a difficult and exhausting effort.

The Full Disclosure Mailing List list has the guideline:

"If a vendor is ignoring your reports or does not make contact information available, we recommend sending full details of the bug through to the list and hopefully the vendor will see it. After all, this is the Full Disclosure list. And if the vendors don't like that, maybe they will publish security contact information and take the reports seriously."

BugCrowd's standard rules say "Communication regarding submissions must remain within ... BugCrowd" — we didn't follow that as we also tried emails and social media first. It also says "ALL SUBMISSIONS ARE CONFIDENTIAL INFORMATION OF THE PROGRAM OWNER" and the disclosure documentation says researchers are able to externally disclose as approved by program owners. Looking over our BugCrowd report which we received a bounty there is not any clear statement about this. We did receive an email noting "This program does not allow disclosure. You may not release information about vulnerabilities found in this program to the public." (But we also were emailed "Information on final processing ... will be sent to you shortly - so stay tuned!" and we are still waiting on that information.)

HackerOne's guidelines briefly discusses safe harbor and about disclosing the contents of the report made public in 30 days, or on an agreed timeline, or immediately if there is "active exploitation or imminent public harm."

The disclose database provides vulnerability contact details for several organizations. This includes via BugCrowd and HackerOne. And the list is also hosted at BugCrowd (note bounties aren't required). They provide documents and statements to help organizations with vulnerability disclosure best practices including recommendations for not pursuing law enforcement or civil action for security research, and example disclosure timelines such as soon as the vulnerability is fixed.

Responsible disclosure allows providing time for issues to be fixed. But if the issue is wide-spread and the vulnerability will continue to be found again (and again), a researcher shouldn't have to wait to teach about it. We are looking forward to your feedback.


Where/How to Contact?

Here are some companies we want to contact (as of 2020-04-06). Do you know of the responsible disclosure details for these companies? (Please share and help us.) We will remove them from this list when they have acknowledged communication. (It would be great to add them to the disclose database mentioned above too.)

  • Coca-Cola
  • United Natural Foods
  • Qurate Retail (QVC)
  • Skandinaviska Enskilda Banken (SEB)
  • FoxTV / Fox Communications
  • L'Oreal
  • Television Nacional de Chile (TVN)
  • ClickTripz
  • Channels TV
  • The Himalayan Times