Tag Archives: NASL

Adding third party nasl plugins to OpenVAS

If you want to develop nasl plugins for OpenVAS, you might be interested how to import them in scanner. So, I was also interested.

First of all, I decided to copy one of existing nasl scripts. I chose script that successfully detected vulnerability on a target host. Thus, in the case of importing error, I would know for sure that it’s not because of syntax errors in script, but, for example, because non-existing plugin signature.

I scanned target CentOS host, chose and copied script file, changed id of the script (oid) and script title, rebuilt database. Then I rescanned target host.

CESA edited

As you can see, new script is also in results. Pretty straightforward.

CESA edited description

Now, let’s review the actual commands.

Continue reading

GSM Community Edition and lagging OpenVAS Plugin Feed

As I already wrote in “Installing OpenVAS 9 from the sources“, since May 2017 OpenVAS 9 is available in a form of free virtual appliance. It is called GSM Community Edition (GCE) and is based on Greenbone commercial product GSM ONE.

What’s the difference between GSM ONE and free GCE? GSM Community Edition uses different Community Feed of NASL plugins, it can’t be updated automatically and does not have some management features. The most important, in my opinion, is that it does not support OpenVAS Management Protocol (OMP), API for managing scanners. Only HTTPS for WebGUI and SSH are available.

GSM start screen

Talking about different NASL plugin feeds, I need to mention recent message by Jan-Oliver Wagner in Openvas-announce list.

That seems like Greenbone is rather tired of developing OpenVAS by themselves and watching how other companies use theirs engine and feeds, positioning themselves as an “alternative to Greenbone’s product at a better price”. So, they decided:

  1. “OpenVAS NVT Feed” will be renamed to “Greenbone Community Feed”
  2. Public access to the “openvas-nvts” SVN repository will be forbidden, but the license of nasl plugins won’t be changed.
  3. Now Community Feed lags 14 days from commercial feed, but Greenbone would like to make an actual feed, but without some features for enterprise customers.

I really care about Greenbone and they, of course, do as they think is better for the company and OpenVAS community, but at the same time it reminds me situation with Tenable and Nessus. Maybe not so radical. But definitely in the same direction.

Feed delayed for 2 week can’t be used effectively for obvious reasons. If you see exploitation of critical vulnerability like WannaCry in the wild and will need to wait 2 weeks to check your infrastructure, it’s a nonsense! 🙂 That’s mean that you just can’t rely on OpenVAS anymore. And if you use it, you should think about migration on commercial solution, for example on Greenbone’s GSM, or think about getting actual plugin feed somewhere else.

The good thing, it might show customers once again that knowledge base of Vulnerability Management solution is important and stimulate other security content developers to make own nasl scripts and feeds.

But let’s go back to GSM Community Edition. Detailed description of installation process you can find on official site. I will just describe my own experience.

Continue reading

What’s actually new in Tenable.io VM application

My last post was about the structure of a new Tenable.io cloud platform. Now, let’s see what is actually new in Tenable.io Vulnerability Management application.

Tenable.io VM is obviously based on Nessus Cloud, which in its turn had features similar to Nessus Manager briefly reviewed earlier. So, today I want to concentrate only on new features.

Tenable.io VM

According to the public interface screenshots and Tenable.io datasheets, it will have some new dashboards and reports, free integration with PVS and Nessus deployed on-premise, and something very new in asset management.

Continue reading

.audit-based Compliance Management in Nessus

In this post I will briefly describe how Nessus .audit-based Compliance Management works, why I like it, what could be improved and why I suppose Tenable won’t do it soon. 😉

Nessus compliance checks are mainly presented in a form of special .audit scripts. This scripting language is very different from familiar NASL (Nessus Attack Scripting Language).

Basically, it is a collection of universal checks for various objects (e.g. existence of the line or parameter in the file, access permissions of the file,  service status, etc.). Of course, nowadays Сompliance Management is not only about Operating System and software (mis)configuration. We have different network devices, databases, cloud services, etc. but originally it was the main case.

By combining the universal checks  any requirement of low-level configuration standard (CIS, DISA, etc.) can be implemented. The similar principles are used in OVAL/SCAP content.

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. 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.

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