If you work in IT Security Department of any large software developing company, you were probably searching for Apache Struts in your environment on this week.
And it’s all because of CVE-2017-5638:
Apache Struts is a free, open-source, Model-View-Controller (MVC) framework for creating elegant, modern Java web applications, which supports REST, AJAX, and JSON.
In a blog post published Monday, Cisco’s Threat intelligence firm Talos announced the team observed a number of active attacks against the zero-day vulnerability (CVE-2017-5638) in Apache Struts
This is a good example, that shows the usefulness of the Vulners.com service.
I have already wrote earlier how to automatically retrieve data from the Vulners.com vulnerability database: if you need objects of some particular type, it’s better use Collection API, if you want to get different types of objects using advanced queries, your choice is Search API v.3.
But what if we want to get, not all the objects, but only new or modified ones in a some date range? How can we do it in Vulners?
Each object in Vulners (vulnerability, patch, bulletin, etc.) has a publication date, and modification date. You can see it if you open some Vulners object in json format, for example CVE-2017-6301:
Today I would like to write about a popular type of “security research” that really drives me crazy: when author takes public Vulnerability Base and, by analyzing it, makes different conclusions about software products or operating systems.
The article is based on Flexera/Secunia whitepaper. The main idea is that various security software products are insecure, because of amount of vulnerability IDs related to this software existing in Flexera Vulnerability Database. In fact, the whole article is just a listing of such “unsafe” products and vendors (IBM Security, AlienVault USM and OSSIM, Palo Alto, McAfee, Juniper, etc.) and the expert commentary: cybercriminals may use vulnerabilities in security products and avoid blocking their IP-address; customers should focus on the security of their proprietary code first of all, and then include security products in the protection scheme.
What can I say about these opuses of this kind?
They provide “good” practices for software vendors:
Hide information about vulnerabilities in your products
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.
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.
All CVEs: 80196
OpenVAS CVE links: 29240
Nessus CVE links: 35032
OpenVAS vs. Nessus: 3787;25453;9579
In this post I would like to provide some links, that you can use to find out necessary information about vulnerability by its CVE ID. I also want to share my amazement, how the method of using the CVE identifiers is changing.
Traditionally, CVE was a global identifier that most of vulnerabilities had. Have you found malicious bug in some software? Send a brief description to MITRE and you will receive CVE id. Some time later NIST will analyze this CVE, will add CVSS vector and CPEs and will put a new item to the NVD database. MITRE and NVD CVE databases were really useful source of information.
This is my personal blog. The opinions expressed here are my own and not of my employer. All product names, logos, and brands are property of their respective owners. All company, product and service names used here for identification purposes only. Use of these names, logos, and brands does not imply endorsement. You can freely use materials of this site, but it would be nice if you place a link on https://avleonov.com and send message about it at email@example.com or contact me any other way.