Tag Archives: security bulletin

Vulristics: Beyond Microsoft Patch Tuesdays, Analyzing Arbitrary CVEs

Vulristics: Beyond Microsoft Patch Tuesdays, Analyzing Arbitrary CVEs. Hello everyone! In this episode I would like to share an update for my Vulristics project.

For those who don’t know, in this project I am working on an alternative vulnerability scoring based on publicly available data to highlight vulnerabilities that need to be fixed as soon as possible. Roughly speaking, this is something like Tenable VPR, but more transparent and even open source. Currently it works with much less data sources. It mainly depends on the type of vulnerability, the prevalence of vulnerable software, public exploits and exploitation in the wild.

Elevation of Privilege - Windows Win32k

I started with Microsoft PatchTuesday Vulnerabilities because Microsoft provides much better data than other vendors. They have the type of vulnerability and the name of the vulnerable software in the title.

Elevation of Privilege - Windows Win32k MS site

But it’s time to go further and now you can use Vulristics to analyze any set of CVEs. I changed the scirpts that were closely related to the Microsoft datasource and added new features to get the type of vulnerability and name of the software from the CVE description.

Elevation of Privilege - Sudo (CVE-2021-3156) - High [595]

Continue reading

No left boundary for Vulnerability Detection

No left boundary for Vulnerability Detection. It’s another common problem in nearly all Vulnerability Management products. In the post “What’s wrong with patch-based Vulnerability Management checks?” I wrote about the issues in plugin descriptions, now let’s see what can go wrong with the detection logic.

The problem is that Vulnerability Management vendors, in many cases, have no idea which versions of the Software were actually vulnerable.

OMG?! How this can be true? 🙂 Let’s take an example.

Each vulnerability at some points in time:

  • was implemented in the program code as a result of some mistake (intentional or not)
  • existed in some versions of the program
  • was detected and fixed

Read more about this in “Vulnerability Life Cycle and Vulnerability Disclosures“.

No left boundary in Vulnerability Detection

Let’s suppose that we have some Software A with released versions 1, 2 … 20.

Just before the release of version 10, some programmer made a mistake (bug) in the code and since the version 10 Software A has become critically vulnerable. Before the release of version 20, Software Vendor was informed about this vulnerability and some programmer fixed it in version 20. Then Software Vendor released a security bulletin: “Critical vulnerabilities in the Software A. You are not vulnerable if you have installed the latest version 20.”

And what does Vulnerability Management vendor? This vendor only sees this security bulletin. It is logical for him to decide that all versions of Software A starting from 1 are vulnerable. So, it will mark installed versions 1 … 9 of the Software A as vulnerable, even so actually they are NOT.

Continue reading