Of ISOs and Attorneys: Legal Action in Vulnerability Disclosure

The ZDI team is commonly asked whether we have ever been sued or threatened with legal action as a result of disclosing vulnerabilities. For many years, even after about 3,500 disclosures that I worked on behalf of ZDI, I could say no. Very recently, an issue came up where a vendor did contact our legal department. Let me tell you the story of what occurred and share some lessons we learned to help the disclosure process for both researchers and vendors.  

In May of 2017, the ZDI purchased around 25 bug reports for a product that recently moved from vendor A to vendor B. These things happen often enough. Vendor A kindly provided the new security response contact at vendor B. The new contact and I also met by phone and discussed the ZDI’s work in general and expectations from the vulnerability researcher community. It seemed like it was going to be a great new partnership. In late June, the contact gave us a new PGP key and a new email address vulnerability@VendorB.com. Great! It seemed like they were really pulling together a right and proper PSIRT. Talking to companies about how to work with the vulnerability research community is one of my favorite parts of my work at ZDI. The new contact asked a few clarifying questions at the end of June and beginning of July. We responded and everything seemed well. 

Things took a turn about 6 weeks later when we sent an email to check in and got an out-of-office reply from the contact. We wrote again a few weeks later to the named contact and to vulnerability@VendorB.com and there was no reply. We wrote again in October and four times in November. The contact had gone silent. At the end of November, I notified the vendor - by these same means we had established - that ZDI would have to publish the reports as 0-day. Strangely, I did get an out-of-office reply again from the named contact. Then the contact suddenly replied that, “New instruction for us is to coordinate this through support@VendorB.com.” Odd.

We were then forwarded a mail from the product manager saying that, “We have addressed some of the vulnerabilities you reported in our most recent release in November,” along with a request to review the status of the other cases. We happily agreed to a call.

Given the dropped communication, they were in better shape than I had feared. They had indeed fixed 18 of the reported vulnerabilities. They also provided a fix and action plan document. Again, in our conversations, it seemed like they were going to get on top of security response and form a response team. And although progress was made, at the end of the year, three vulnerability reports remained unpatched. I informed them that we did have to disclose the remaining cases as 0-day reports but we noted in our advisory, “the vendor has indicated the intent to patch later in January 2018.” Once they did release patches in mid-January, we updated our advisories. All was settled, and I felt the vendor had learned a lot about vulnerabilities and response. It had been a little rockier than I first imagined along the way, but I was satisfied this would be a great relationship going forward.

ZDI did not have contact with this vendor again until April of 2018. I had not removed the address vulnerability@VendorB.com from our records, as somehow, I still believed they were forming a PSIRT team to respond from this address. When my counterpart saw 5 new vetted reports for this vendor, he promptly sent them over to this address – the address I had recorded for them. We did not receive any bounced message, but in the very high report volume we had at the time, we did not immediately notice that we did not have a reply from them either. Thinking they were properly notified, and thinking they had not really made the commitment to vulnerability resolution that I believed they had in 2017, and with a shorter deadline to work with (120-days in 2018 vs. 180 days in 2017), we decided to send a notification to vulnerability@VendorB.com and 0-day the reports in September 2018.

A few days later, I got an email from Trend Micro counsel that the vendor’s counsel had contacted them about these ZDI 0-day postings. There were a few points of varying validity, but their response was primarily, “We have not seen these reports and have no record of your contacting our support team, but these are already patched.”

Well, it’s a bold position…

The vendor posted a knowledge base (KB) article telling their customers, our attorney, and all the world that, though they have not seen these reports, the bugs were patched and they had not spoken with ZDI prior to the publication of these advisories. The KB article stated Vender B believed all cases were successfully mitigated.

I had to concur with one bone of contention they had. When we post any 0-day advisory, we post a timeline and some sort of mitigation. The ZDI advisory template for 0-day was not a different template than the standard advisory. Consequently, it read “Vendor states” because this is where the vendor advisory/patch link usually goes. However, on an 0-day, this text fell over the timeline and the mitigation. What we offered as a mitigation was,

“Given the nature of the vulnerability, the only salient mitigation strategy is to restrict interaction with the service to trusted machines. Only the clients and servers that have a legitimate procedural relationship with the service should be permitted to communicate with it. This could be accomplished in a number of ways, most notably with firewall rules/whitelisting.”

They objected to this since it could be interpreted as coming from them based on the “Vendor states” placement. Fair enough. Through the attorneys, we also learned that vulnerability@VendorB.com had been abandoned. It was replaced with an online vulnerability reporting submission page.

When we tested the updates they advised in their KB article, we found that not all cases were patched. Only one bug was patched. The other four were not effectively patched in each supported version. When I tried to re-submit the reports to the page, I found many limitations, in size and the inability to submit files. One report errored out yet provided no error message at upload. These reports went to their technical support team, who called me three times, each time to read the same canned information that I had already advised their attorney was incorrect.

In the end, we ended up removing the 0-day designation from one of the advisories as indeed it had patched within our disclosure window. We updated two of the five advisories as they patched post 0-day, and two of the five remain unpatched. These were post-auth cases the vendor felt they were a lower priority for them. We removed the inadvertently poorly placed “vendor states” from above our mitigation and timeline and we began work with our Ops team to have different templates for 0-day advisories vs. regular advisories. 

I also updated the contact information for this vendor in our database and plan to be more careful when I know a vendor is growing or transitioning in this manner, to look for updates to their disclosure policy (vs. more mature or established security response teams). I can honestly compliment this vendor: I do believe they are attempting to mature into these processes. They are headed in the right direction, in my opinion.

Lessons Learned

The first big takeaway from this is that you should never, ever abandon a secure@ or vulnerability@ mailbox. That is an invitation for trouble. If you do choose to go another way, post an automated reply linking to your new process. 

Second, webforms are rarely the best way to go for vulnerability reporting. It can be done, and there are a few exceptionally successful teams who do use them. However, they do have some limitations, and most who use webforms don’t use encryption. If you go this route, be flexible in form and size – and support PGP or some other form of encryption. The ability to upload a file is a MUST HAVE. 

Another common failure is relying on technical support teams to do vulnerability response. Those that do are usually not very successful in my observation. Most technical support email and phone teams simply do not have the technical familiarity with vulnerabilities. No offense to those who do tech support – it’s just a different skillset.

Similarly, most attorneys simply do not have the familiarity with vulnerabilities either. After some initial back and forth about the language on the advisories, the attorneys yielded to something closer to the natural process. I talked through the issues, which patch, what date, which advisory with the vendor’s Senior R&D Director. We were able to settle our differences with the vendor. In the end, they followed through in all of these cases, and we do thank them very much for their commitment to resolution.

Enter the ISO

When standing up a new response organization, it can feel as though you must invent every process from scratch. Thankfully, this isn’t the case. ISO 30111 provides “guidelines for how to process and resolve potential vulnerability information in a product or online service.” It goes along with ISO 29147, which provides guidelines for vendors on how to receive vulnerability reports and then provide resolution information to affected users. In other words, those two ISO documents lay out a response program in fair detail. They even made ISO 29147 freely available to assist those setting up new programs. Even if you don’t end up implementing everything in these standards, it’s good to know what the industry sees as standard.

Conclusion

Disclosing bugs to vendors can be an interesting journey. Much depends on the maturity of the vendor response process, but one cannot discount the nature of the bug report as well. For those just entering the space – reporting or receiving vulnerabilities – the process can be confusing. Open and regular communication between all parties involved is a key to a successful resolution of a bug report. It helps if all involved also go into the process with realistic expectations, which are laid out in the ISO standards.

If you’re a researcher and all of this sounds a bit daunting, that’s one of the benefits of reporting to the ZDI program. In addition to public recognition and financial compensation, we work with the vendor so you won’t have to. If you’re interested in getting the most out of your research submitting to our program, be sure to check out my previous blog on the topic. I hope to disclose some great reports on your behalf. Until then, follow the team for the latest in exploit techniques and security patches.