Category Archives: Vulnerability Database

How Debian OVAL content is structured

Hello everyone! As we saw in the last episode, the results of vulnerability detection for one host produced by two different APIs can vary greatly. Therefore, in order to find out the truth, it is necessary to understand what vulnerability data is provided by the Linux distribution vendor and how this data is structured.

Alternative video link (for Russia): https://vk.com/video-149273431_456239114

Why is it important to do this? Because using data from a Linux distribution vendor, we can ask vulnerability detection API vendors questions: why are you detecting in a different way than described in this data? And then we will understand what caused the difference. And we will either adjust the API for vulnerability detection, or we will adjust the content of the Linux distribution vendor. Either way, it will be a success! In any case, the transparency of the vulnerability detection process will increase.

Last time we looked at vulnerabilities for Debian host and Debian Docker base image. So let’s continue with Debian. In particular, with the official Debian OVAL (Open Vulnerability and Assessment Language) content.

Debian OVAL content can be downloaded from the https://debian.org/security/oval/ website. For Debian 11.6 it will be https://debian.org/security/oval/oval-definitions-bullseye.xml (~48M).

Continue reading

The most magnificent thing about Vulnerabilities and who is behind the magic

What I like the most about software vulnerabilities is how “vulnerability”, as a quality of a real object (and the computer program is real), literally appears from nothing.

The most magnificent thing about Vulnerabilities and who is behind the magic

Let’s say we have a fully updated server. We turn it off, lock it in a safe and forget about it for half a year. Six months later, we get it, turn it on. It is the same and works absolutely the same. But now it is also exposed to dozens of critical vulnerabilities that, with some (un)luck, can be exploited by any script kiddie. New important characteristic of the material object appeared from nowhere, isn’t this magnificent? ?

Continue reading

Martian Vulnerability Chronicles

Well, there should have been an optimistic post about my vulnerability analysis & classification pet-project. Something like “blah-blah-blah the situation is pretty bad, tons of vulnerabilities and it’s not clear which of them can be used by attackers. BUT there is a way how to make it better using trivial automation“. And so on. It seems that it won’t be any time soon. ¯\_(ツ)_/¯

I’ve spent several weekends on making some code that takes vulnerability description and other related formalized data to “separate the wheat from the chaff”. And what I get doesn’t look like some universal solution at all.

Pretty frustrating, but still an interesting experience and great protection from being charmed by trendy and shiny “predictive prioritization”.

Martian Vulnerability Chronicles

Literally, when you start analyzing this vulnerability-related stuff every your assumption becomes wrong:

  • that vulnerability description is good enough to get an idea how the vulnerability can be exploited (let’s discuss it in this post);
  • that CVSS characterizes the vulnerability somehow;
  • that the links to related objects (read: exploits) can be actually used for prioritization.

Actually, there is no reliable data that can be analyzed, trash is everywhere and everybody lies 😉

Let’s start from the vulnerability description. Great example is the last week critical Linux kernel vulnerability CVE-2019-8912.

Continue reading

Vulnerability Life Cycle and Vulnerability Disclosures

Vulnerability Life Cycle diagram shows possible states of the vulnerability. In a previous post I suggested to treat vulnerabilities as bugs. Every known vulnerability, as same as every bug, was implemented by some software developer at some moment of time and was fixed at some moment of time later. What happens between this two events?

Vulnerability life-cycle

Right after the vulnerability was implemented in the code by some developer (creation) nobody knows about it. Well, of course, if it was done unintentionally. By the way, making backdoors look like an ordinary vulnerabilities it’s a smart way to do such things. 😉 But let’s say it WAS done unintentionally.

Time passed and some researcher found (discovery) this vulnerability and described it somehow. What’s next? It depends on who was that researcher.

Continue reading

What is a vulnerability and what is not?

It looks like a pretty simple question. I used it to started my MIPT lecture. But actually the answer is not so obvious. There are lots of formal definitions of a vulnerability. For example in NIST Glossary there are 17 different definitions. The most popular one (used in 13 documents) is:

Vulnerability is a weakness in an information system, system security procedures, internal controls, or implementation that could be exploited or triggered by a threat source
NISTIR 7435 The Common Vulnerability Scoring System (CVSS) and Its Applicability to Federal Agency Systems

But I prefer this one, it’s from the glossary as well:

Vulnerability is a bug, flaw, weakness, or exposure of an application, system, device, or service that could lead to a failure of confidentiality, integrity, or availability.

I think the best way to talk about vulnerabilities is to treat them as bugs and errors. Because people deal with such entities more often in a form of software freezes and BSODs. 😉

You probably heard a joke, that a bug can be presented as a feature if it is well-documented and the software developers don’t want to fix it.

Bug, feature and vulnerability

Vulnerability is also a specific bug that can lead to some security issues. Or at least it is declared.

Continue reading

MIPT/PhysTech guest lecture: Vulnerabilities, Money and People

On December 1, I gave a lecture at the Moscow Institute of Physics and Technology (informally known as PhysTech). This is a very famous and prestigious university in Russia. In Soviet times, it trained personnel for Research Institutes and Experimental Design Bureaus, in particular for the Soviet nuclear program.

MIPT open lecture about vulnerabilities

Nowadays MIPT closely cooperates with Russian and foreign companies, trains business people, software developers and great scientists. For example, the researchers who discovered Graphene and won Nobel Prize for this in 2010 were once MIPT graduates.

This is a very interesting place with a rich history. So it was a great honor for me to speak there.

Continue reading

PHDays8: Digital Bet and thousands tons of verbal ore

It’s time to write about Positive Hack Days 8: Digital Bet conference, which was held May 15-16 at the Moscow World Trade Center. It was the main Russian Information Security event of the first half of 2018. More than 4 thousand people attended! More than 50 reports, master classes and round tables held in 7 parallel streams. And, of course, impressive CTF contest for security experts and hackers with an fully-functioning model of the city.

Hack Days 8: Digital Bet

I was very pleased that there was a separate section dedicated to Vulnerability Management. Something similar happened only at ISACA meetup last year. But here we had an event for several thousand people!

The session was held in Fast Track format: 20 minutes for the presentation and questions. I was the first to speak. My report was called “Vulnerability Databases: sifting thousands tons of verbal ore”. Here is the video:

And here’s a link to the version with only Russian sound track.

Continue reading