Sitting on Undisclosed Vulnerabilities (e.g. SolarWinds Stragglers)

The company SolarWinds is in the news, victims of an attack that compromised their Orion Platform software by inserting a backdoor into it, allowing for remote code execution. Like most big breaches, we hear the term “sophisticated” used for the attack. And like many breaches, we quickly learn that it might not have been so sophisticated after all. There is plenty of commentary on this and the wave of attribution experts are out in full force on Twitter. You can read about all of that elsewhere as I cover a different aspect of vulnerability disclosures here.

For anyone who has done penetration testing, they have found vulnerabilities of course. Since those tests are done under non-disclosure agreements (NDA), the vulnerabilities are reported to the customer. One long-standing problem with process is that a vulnerability found during that test may be in commercial off-the-shelf (COTS) software that affects many other organizations in the world. But that NDA often says you cannot disclose them elsewhere, including to the vendor. Even if it does, most penetration testing shops don’t have someone designated to handle coordinated disclosure with the vendor. When it does happen, it is often in the tester’s spare time or if the company uses security advisories for advertising, may task them to write it up.

For more than 25 years, this means that a lot of vulnerabilities are discovered in COTS that die in customer reports. The customers may sometimes report them to a vendor themselves looking for a fix. But surprisingly, that often does not happen. How do we know? Many testers have seen the exact same vulnerability during a test of the same customer a year or more after the original. There are times where a tester will disclose those vulnerabilities long after the fact, without coordinating with the vendor. This can happen after they leave the company they did the testing for or when they think sufficient time has passed.

I think we saw this yesterday with SolarWinds with the publication of CVE-2018-16243. First, while MITRE is not consistent about the assignment year, CVE is intended to use the year to denote when the vulnerability was discovered, not disclosed. A 2018 ID assigned to an issue that was published yesterday strongly suggests the researcher requested the ID back in 2018 but waited until now to publish. The exact date is likely 8/30/2018 per the disclosure itself. But looking at the disclosure, done via gist.github.com, we can see via the revisions that it was published 12/14/2020. So the researcher appears to have sat on these SolarWinds Database Performance Analyzer vulnerabilities for 837 days. Based on the disclosure, there was no coordination with the vendor and no fix currently available. On the upside, seven distinct XSS vulnerabilities were disclosed but the CVE only covers six of them.

Why now? Because SolarWinds was in the news albeit for a vulnerability in a different product (SolarWinds Orion Platform). Looking at prior vulnerability disclosures, it is easy to tell where the researcher works. A quick LinkedIn search verifies that bit of information and brings us to the fun question; did they find these SolarWinds vulnerabilities at their prior job, the downtime between jobs, or at Optiv? All three have interesting implications if you think about it. =)

Jumping back to the point, I will renew the call I have made in the past; penetration testing shops should use an NDA that allows them to report vulnerabilities in COTS to the vendors on behalf of the customer. They should manage the coordinated disclosure process and publish an advisory after a fix has been made available and they verified their customer has mitigated the vulnerabilities. Yes, it is a little extra work! Yes, it also is a value add to your customer, value to any organization that uses the software, and the advisories become advertising of sorts. That little extra work will go a long way for the greater good.