[This was originally published on RiskBasedSecurity.com.]
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.
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!