[BreachExchange] Down The Vulnerability Rabbit Hole

[Destry Winant]

https://www.riskbasedsecurity.com/2021/04/15/down-the-vulnerability-rabbit-hole/

In a recent article, The Importance of a Living Database, we detailed
why it is important to revisit entries as new information comes to
light. Like the times, vulnerabilities are a-changin’. We’ve been
known to revisit a vulnerability record over 1,200 times, which may
seem excessive, and some may claim that we’ve gone down the rabbit
hole. However, we are convinced that such meticulous methods are
necessary and we invite you to tea-time as we explain the reasons for
the madness.

>From time-to-time, you may have read Risk Based Security articles that
describe “rabbit hole” situations during our vulnerability research.
The “rabbit hole”, of course, refers to an opening scene in Lewis
Carroll’s iconic 1865 book, “Alice’s Adventures in Wonderland”, where
Alice literally falls down a hole after the White Rabbit, transporting
her to Wonderland. 150 years later, the term might be used to describe
spending a lot of time researching a topic on the Internet.

Falling Short of Expectations

A vulnerability rabbit hole means that we spent an exorbitant amount
of time trying to figure out details for a vulnerability. Hopefully
you are already asking yourself the same question we always do, “why
should we have to do that?” This is typically the result of a
vulnerability disclosure that fell short, in our opinion, either by
not providing enough information to make it actionable or by giving
conflicting or ambiguous information.

In some cases, we go down these rabbit holes trying to figure out
which vulnerability the vendor, researcher, or client is even talking
about, just so that we can match it against a known disclosure. Again,
we hope you are now asking the fair question “That is ridiculous, why
didn’t they just provide a clean cross reference?” If only it could be
so simple.

This article will provide one such example of where several elements
of vulnerability communication have fallen short. We’ve included a
timeline of our rabbit hole adventure at the end, to remind everyone
that timelines related to vulnerability disclosures are a big help.

Down the Rabbit Hole

In January, a customer asked us which VulnDB ID is associated with
Qualys ID 119389, a vague Java vulnerability. Without access to the
software and no additional information, we began digging. Google
searches were useless, and none of the Qualys plugins could be found
online. Later that day, we reached out to Qualys, Oracle, and ZDI
since they were involved in the disclosure.

A week passed before we received a reply from Oracle, who told us that
the vulnerability in question was “addressed in JDK 7”. However, they
didn’t provide any details about the vulnerability, where it
originated, or anything that gave us a real sense of risk. We
followed-up with them and they confirmed quickly that it was a
“Security-In-Depth issue” and as a result, no CVE ID was assigned.

However, a few days later, Qualys Support replied saying that the same
vulnerability “is a zero day vulnerability there is a limited
information [sic]”. They also provided a cross reference, citing the
blog the alert originated from. It went all the way back to July 8,
2011, where Acros Security disclosed an issue titled “Binary Planting
Goes ‘Any File Type’”. This link allowed us to check our database to
determine we covered it as VulnDB 74330. At that point we were able to
start updating our entry with additional details as we followed-up
with Qualys on how they were performing the check.

After more research, Qualys confirmed that they were doing a simple
check for the version of Java to determine a vulnerable system.
Ultimately, we were able to answer our customer’s question with the
help of both Oracle and Qualys, despite us not being a direct
customer. In this case, the three of us had a mutual customer that had
questions. This highlights why Support or PSIRT answering questions
related to older disclosures is still very beneficial to everyone.

The Timeline

January 19 – Customer inquires about QID 119389
January 19 – RBS contacts Qualys on customer’s behalf
January 19 – Qualys assigns support case #920749
January 19 – RBS contacts Oracle
January 19 – RBS contacts ZDI
January 19 – RBS reaches out to industry colleagues for screenshots of Qualys ID
January 19 – Colleagues come through, provide screenshots but
questions remain unanswered
January 26 – Oracle states “addressed in JDK 7”, provides no further details
January 27 – Oracle confirms it “is a Security-In-Depth issue” and
that no CVE has been assigned
February 1 – Qualys states “is a zero day vulnerability there is a
limited information [sic]” but provides a cross reference
February 1 – RBS asks Qualys how they are detecting it without details
and RBS provides additional cross references
February 3 – RBS notifies ZDI that issue has been resolved
February 24 – Qualys says they are still working on details of the check
March 4 – Qualys says detection is based on a version check of Java

All said and done, it took a good amount of time to answer all of the
questions and close out the issue. While digging into an issue like
this is a bit painful, it achieves positive results.

It would be a disservice to our customers if we accepted every
disclosure as they appear. Organizations are having enough trouble
dealing with the incredible amount of vulnerability disclosures and we
would prefer that our clients start managing vulnerabilities as fast
as they can. If that means that we have to take the time to research
on their behalf we will gladly do so. After all, isn’t vulnerability
intelligence supposed to make your life easier?

Supporting both products and security has its hurdles and rabbit holes
but it is entirely worth it. After all, VulnDB is the most
comprehensive, actionable and timely source of vulnerability
intelligence available. If we don’t go down the rabbit hole every now
and then it would be off with our heads!