SolarWinds was in the news last year, as the victim of an attack that compromised its Orion Platform software by inserting a backdoor into it, allowing for remote code execution. This attack has had an incredible impact on the security industry and recently, interest in the SolarWinds breach has resurfaced. According to Reuters, this event has caused the Biden administration to draft a new executive order that would force software vendors to disclose any breach to U.S. government users.
With big breaches, the term “sophisticated” is often used to describe the attack. However, as is often the case, we quickly learned that it might not have been so sophisticated after all. There has been plenty of commentary on this and the usual wave of attribution experts have been out in full force on Twitter.
Sadly, important issues and vulnerabilities sometimes “die” and fall through the cracks, only to resurface years later. This happens quite often, and appears to be what happened to SolarWinds. CVE-2018-16243, and vulnerabilities like it, emerged well after the attack, despite it affecting six different XSS vulnerabilities in other SolarWinds products. Despite being discovered in 2018, this vulnerability was not published until December 14, 2020. How does this happen though? To end users, especially those affected, it doesn’t make sense that a two year gap exists. You would be forgiven for asking yourself, “why didn’t anyone tell me that this existed until recently?”
How vulnerabilities “die”
The gap between the discovery and publication of a vulnerability is often because of NDAs and the general penetration test process. Anyone penetration testing is bound to find vulnerabilities, but most tests are done under non-disclosure agreements (NDAs) with vulnerabilities being reported directly to the customer. One long-standing problem with this process is that a vulnerability found during that test can also be in commercial off-the-shelf (COTS) software affecting many other organizations in the world. But many NDAs do not allow researchers to disclose any vulnerabilities, even to those now unknowingly vulnerable vendors.
If the NDA doesn’t contain these kinds of restrictions, most penetration testing shops don’t have someone designated to handle coordinated disclosure with vendors. And when it does, the task of writing the research happens during the tester’s spare time or is turned into a form of advertisement for the company. As such, those vulnerabilities that happen to affect other COTS software may or may not get reported.
This has been the case for more than 25 years, so this means that there are a lot of vulnerabilities discovered in COTS that “die” in customer reports. Sometimes pen-test customers looking for a fix will directly report these “dead” vulnerabilities to those affected vendors. But surprisingly, that does not happen often. How do we know? Many testers see the exact same vulnerabilities during a test for the same customer a year or more after the original incident.
What happened to CVE-2018-16243
There are also times where a tester will disclose those vulnerabilities long after the fact, without coordinating with the vendor. This can happen after the tester leaves the company they tested for, or when they think sufficient time has passed.
This situation may be the case for the publication of Solarwinds’ CVE-2018-16243. First, while MITRE is not consistent about the assignment year, CVE was intended to use the year to denote when the vulnerability was discovered, not disclosed. A 2018 ID assigned to an issue that was published near the end of 2020 strongly suggests the researcher requested the ID back in 2018, but waited until now to publish; most likely releasing due to increased media attention for SolarWinds related vulnerabilities.
The exact discovery date is likely August 30, 2018 per the disclosure itself. But looking at the disclosure, via gist.github.com, we can see through the revisions that it was published on December 14, 2020. It appears that the researcher sat on these SolarWinds Database Performance Analyzer vulnerabilities for 914 days. Based on known information, there was no coordination with the vendor and no fix is currently available. Also, although seven distinct XSS vulnerabilities were affected, CVE only covered six.
Extra work goes a long way
In order for fewer vulnerabilities to die in customer reports, pen-testers and the industry as a whole should opt for NDAs that allow them to report vulnerabilities in COTS to affected vendors on behalf of the customer. Researchers should manage the coordinated disclosure process and can 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! But most importantly it adds value for the customer and to any organization that uses the software. It also allows the advisories to become advertising of sorts by promoting the capabilities of the researcher. That little extra work will go a long way for the greater good.
When it comes to prioritization or mitigating risk, comprehensive, actionable and timely vulnerability intelligence is crucial for any organization looking to make truly risk-based decisions. CVE/NVD is missing over 94,000 vulnerabilities – don’t let potentially impactful vulnerabilities fall through the cracks. Data should be able to illuminate and highlight any areas of concern within your security ecosystem.