Tag Archives: Linux

Problems of Vulnerability Prioritization and Detection

It’s the third part of our talk with Daniil Svetlov at his radio show “Safe Environment” recorded 29.03.2017. In this part we talk about Vulnerability Prioritization and Detection:

  • Common Vulnerability Scoring System (CVSS)
  • Environmental factor
  • Manual and  automated vulnerability detection
  • Unauthenticated and authenticated  scanning
  • Why vulnerability scanners are so expensive and why the can’t detect everything

Scanner does not detect all vulnerabilities

Video with manually transcribed Russian/English subtitles:

Prioritization

– Here also the question how to prioritize vulnerabilities properly. Because if you have, as you said, two Linux servers and 20 workstations running Windows, then in principle, you may not need to do prioritization. But if you have fifteen hundred servers: some of them are on perimeter, some are in your DMZ, some are in the internal network. It is still necessary, probably, to understand correctly which vulnerabilities and where should be patched in in the first place.

Yes, this is absolutely true and it’s a very good question. How to prioritize?

Common Vulnerability Scoring System

A natural way. If we look at vulnerabilities with a CVE identifier, for them in the US National Vulnerability Database we can find CVSS Base Score. It is an assessment of vulnerability criticality level.

How is it calculated?

Some person fills the questionnaire: can it be remotely exploited – no, is there public exploit – no, etc.

CVSS framework

The result is a CVSS vector – this is a line in which you can see the main characteristics of this vulnerability and CVSS Base score is the score from 0 to 10 depending on criticality.

This is a natural way of prioritization. But sometimes this method does not give very good results.

Continue reading

PHDays VII: To Vulnerability Database and beyond

Last Tuesday and Wednesday, May 23-24, I attended PHDays VII conference in Moscow. I was talking there about vulnerability databases and the evolution process of vulnerability assessment tools, as far as I understand it.

To Vulnerability Database and beyond

But first of all, a few words about the conference itself. I can tell that since the last year the event got even better. I’ve seen lot of new faces. Some people I didn’t know, but they knew me by my blog and accounts in social networks. What a strange, strange time we live in! I was very pleased to see and to talk with you all, guys! 🙂

PHDays is one of the few events that truly brings all Russian community of security professionals together. I’ve seen people I have studied with in university, colleagues from the all places where I have been worked, and nearly all researchers and security practitioners that I follow. Big thanks for the organizers, Positive Technologies, for such an amazing opportunity!

It is also a truly international event. You can see speakers from all over the world. And all information is available both in Russian and English. Almost all slides are in English. Three parallel streams of reports, workshops and panel discussions were dubbed by professional simultaneous interpreters, like it is a United Nations sessions or something, recorded and broadcast live by the team of operators and directors. Final result looks really great.

Video of my presentation:

I was talking too fast and used some expressions that was hard to translate. The translator, however, did an awesome job. He is my hero! 🙂 If you didn’t understand something on video, I made a transcript bellow.

A version without translation for Russian-speakers is here.

Slides:

Unfortunately gif animation is not working in the Slideshare viewer.

Today I would like to discuss vulnerability databases and how vulnerability assessment systems has been evolving. Prior to discussing vulnerability databases I need to say that any vulnerability is just a software error, a bug, that allowing hacker to do some cool things. Software developers and vendors post information about such vulnerabilities on their websites. And there are tons and tones of vendors, and websites, and software products, and vulnerabilities.

Continue reading

Why you can’t update it all at once?

It’s the second part of our talk with Daniil Svetlov at his radio show “Safe Environment” recorded 29.03.2017. In this part we talk about vulnerabilities in Linux and proprietary software, problems of patch an vulnerability management, and mention some related compliance requirements.

How critical these vulnerabilities are? Are they really exploitable in our infrastructure?

Video with manually transcribed Russian/English subtitles:

Previous part “Programmers are also people who also make mistakes”.

Taking about the fact that if you use fully updated software and do not use some self-written scripts, programs, then in theory everything will be safe.

But recently there was some statistics that critical vulnerabilities stay in Linux kernel about 7 years from the moment they appeared as a result of a programmer’s error till the moment they were found by our white hat researcher.

But it is not clear during these seven years if cybercriminals have found them, used them and how many systems were broken using this vulnerabilities. Not to mention that some special government services may use it too.

For example: The latest Linux kernel flaw (CVE-2017-2636), which existed in the Linux kernel for the past seven years, allows a local unprivileged user to gain root privileges on affected systems or cause a denial of service (system crash). The Hacker News

Well yes. There is such a statistic. There is also some criticism from proprietary software developers. Like you say “many eyes that looks in code will find any error.” This is a quote from Linus Torvalds, if I’m not mistaken.

Not exactly. Linus’s Law is a claim about software development, named in honor of Linus Torvalds and formulated by Eric S. Raymond in his essay and book The Cathedral and the Bazaar (1999).[1][2] The law states that “given enough eyeballs, all bugs are shallow”; or more formally: “Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone.” Wikipedia

But in practice, yes, there are really old vulnerabilities that come up after many many years. Because apparently they did not looking for this vulnerabilities well enough.But we still don’t have anything else, except Linux kernel. Therefore, they can say anything, but they will use it anyway. It is in the first place.

Continue reading

ZeroNights16: Enterprise Vulnerability Management

17-18 November I was at the great event  Zero Nights security conference in Moscow. For the first time as a speaker. Being a part of such famous and prestigious security event was very exciting. There were three of us, Ekaterina Pukhareva, Alex Smirnoff and me, and only 20 minutes available for all. I was talking mainly about VM solution problems and custom reporting/ticketing, Ekaterina shared some experience in using Tenable SecurityCenter for Vulnerability and Compliance management, and Alex was talking mainly about Asset and Risk Management.

Alex ArkanoiD Smirnov, Alexander Leonov, Ekaterina Pukhareva at ZeroNights 2016

Presentation was recorded and some time later video will be available on YouTube. However, I suppose audio will be only in Russian not earlier than February 2017. So I think it will be a much more useful to share some points of the presentation right now. Lucky here I don’t have any time restrictions. =)

The first thing to say about Vulnerability Scanners and Vulnerability Management product is that there are plenty of them. On this picture I mentioned some of the products/vendors.

Vulnerability Scanners and Vendors

Some of them are highly specialized, like ErpScan for SAP, others are universal. Some of them are presented globally: Tenable Nessus / SecurityCenter, Rapid 7 Nexpose, Qualys, F-Secure etc., others are known mainly in Russia: Positivie Technologies Maxpatrol, Altx-Soft RedCheck, Echelon Scaner-VS. Some products are expansive, some of them not and even have versions available for free: OpenVAS, SecPod Saner Personal, Altx-Soft ComplianceCheck, Qualys SSL labsHigh-Tech Bridge SSL Server Security Test, etc.

In my opinion the main problems of VM solutions are expansiveness and low reliability of the scan results.

Continue reading

Fast comparison of Nessus and OpenVAS knowledge bases

In my opinion, quality of knowledge base is the most important characteristic of Vulnerability Management (VM) product. Maybe it’s because I have spent significant amount of time making different security content for vulnerability scanners and this is some form of professional deformation. 🙂 The fact is that nowadays we have dozens of VM solutions on the market, which have very different knowledge bases and thus different abilities for detecting vulnerabilities. And really nobody talk about this. I can recommend related post “Tenable doesn’t want to be Tenable anymore” and especially HD Moore’s comment to that post. It describes the reason why nobody interested now in quality of detection. Maximum what we, end-users, can hear from the vendor about it’s knowledge base is an amount of vulnerability checks: 40000-80000 and approximate list of supported systems. There is a massive false belief that detection quality of the products is approximately the same and it’s better talk about dashboards, reports, SIEM-like capabilities. To demonstrate that the difference actually exists I made a pretty primitive comparison of Nessus and OpenVAS knowledge bases.

I chose these two products, mainly because information on their NASL plugins is available at Vulners.com. As I also wrote earlier how you can use easily parse Vulners archives in python, so you can repeat it for yourself. I talked about this topic at Pentestit webinar about Vulners. If you are familiar with Russian, you can also check this out. 😉 The slides for this presentation are available here.

Why I call this comparison fast and primitive? I don’t define the structure of KBs for this product and don’t carefully map one nasl script to another. I suppose it may be a theme for another posts. Instead I am looking at the CVE links. If two scanners detect can the same vulnerabilities, they should have the same CVE links in all the NASL scripts, right? In reality we have a great difference between the products and more than a half of the CVEs can’t be detected by using both of them.

CVE links from NASL plugins

All CVEs: 80196
OpenVAS CVE links: 29240
Nessus CVE links: 35032
OpenVAS vs. Nessus: 3787;25453;9579

Continue reading