Vulnerability scanners, in particular, are critical for ensuring that any threats that may have made it past the firewall are picked up before they can infect and destroy entire networks.
The enterprise/proprietary vulnerability scanner market is filled with competitors (such as QualysGuard or Nessus), and while some companies prefer running proprietary enterprise scanners, there are also many companies that prefer using collective intelligence and open source scanners.
One such product is OpenVAS (now renamed Greenbone Vulnerability Management or GVM). In this post we’ll refer to OpenVAS/GVM interchangeably, as the old name is still used to identify the software.
What is OpenVAS/GVM?
OpenVAS/GVM is a fully-featured vulnerability scanner, but it’s also one component of the larger “Greenbone Security Manager” (GSM).
OpenVAS dates back to 2009 and the project is maintained by a commercial/open-source company. With its focus on the enterprise market and its long history, any risks of enterprises adopting a technology that might become abandoned are greatly reduced.
Here are some notable positives of OpenVAS/GVM:
- Has a long history (since 2009) with daily updates and over 50,000 vulnerability tests
- Is backed by an enterprise software-security company
- Can perform various types of authenticated/unauthenticated tests
- Supports a variety of high- and low-level Internet and industrial protocols
- Has an internal programming language that can be used for implementing custom vulnerability tests
Who should use it?
OpenVAS/GVM is useful for companies’ DevOps/security teams. In most scenarios it would be used by people in a “blue team” environment.
While pentesters and people doing bug bounties can use it as well, other available tools may be preferable, geared toward their areas of expertise.
There are multiple methods for installing OpenVAS/GVM. We’ll discuss the two most popular methods before proceeding with the installation.
Note: It is always important to use some type of sandboxing environment when installing new software. You can opt for a virtual machine (VM), container or a remote test server.
Compiling from source
This is probably the most complicated method for installing OpenVAS/GVM. If you are comfortable compiling software written in C, this shouldn’t prove too challenging for you. However, we recommend not doing this because OpenVAS is a large piece of software with many parts.
We’ve compiled software before in previous software reviews (see: Masscan), but OpenVAS does have two great alternatives: it’s pre-packaged on Kali and has a PPA* for Ubuntu.
Installing on Kali Linux
Installing OpenVAS on Kali requires just a few commands:
apt-get update && apt-get dist-upgrade -y sudo apt install postgresql reboot apt-get install gvm -y
Kali runs as root, so there is no need for sudo. The second part of the setup on Kali will be similar to the Ubuntu install. We will mention at which point you can run the commands on Kali to achieve the same setup on Ubuntu.
Installing on Ubuntu 20.04
Our first discovery when attempting an install on Ubuntu was that much of the existing documentation discusses the ‘openvas’ PPA.* The problem encountered here is that OpenVAS was renamed GVM (Greenbone Vulnerability Management), so we need to adjust the commands appropriately. We’ll use Ubuntu 20.04 to install GVM.
First we update Ubuntu itself:
sudo apt update sudo apt upgrade
Now let’s install the required package that will enable us to add the PPA.*
sudo apt install software-properties-common sudo add-apt-repository ppa:mrazavi/gvm
A prompt like the following will be displayed:
Press Enter and the PPA* will be added to the system. We will install PostgreSQL and fetch package data before installing GVM:
sudo apt install postgresql sudo apt update
We should now be able to install OpenVAS/GVM.
sudo apt install gvm
The installation process on Kali Linux should be similar to the process from here onwards. During the install you’ll get a prompt about Redis that looks like:
We can proceed by selecting ‘yes’.
You will then see a few more prompts like this
asking to configure the PostgreSQL database. We can proceed by selecting the default options.
We now run the following commands to fetch the Network Vulnerability Tests from OpenVAS Feed and sync the ‘scap’ and ‘cert’ data:
sudo greenbone-nvt-sync sudo greenbone-scapdata-sync sudo greenbone-certdata-sync
greenbone-scapdata-sync processes should take some time (depending on your internet speed).
In order to get OpenVAS/GVM to run on an external interface (meaning not
localhost), we need to modify the
sudo vim etc/default/gsad
Look for the following line:
and modify it to:
We can now save and exit vim. After this, we need to restart a few services:
sudo systemctl daemon-reload sudo service gvmd restart sudo service gsad restart
You can now browse to your local container/VM IP address remember to include the HTTPs in front of the IP and the port number, so that it looks like: https://x.x.x.x:9392) and you should see an output like the following:
Stay in the loop with the best infosec news, tips and tools
Follow us on Twitter to receive updates!Follow @SecurityTrails
How to use OpenVAS/GVM
We can login to the dashboard using the following username/password details:
You should then see the dashboard of OpenVAS/GVM as shown here:
Our first test will be to configure a simple scan using OpenVAS/GVM on a single IP address. We have chosen one of the malvertising IPs we track as a test: 184.108.40.206
To conduct a new scan, we follow the path of: Scans > Tasks
Once the page loads, there is an option to create a new task on the top left of the screen:
Create a new task
We can click on “New Task” and fill in the details as follows:
The “Scan Targets” option is where the IP is added. It is currently greyed out because only existing scans can be selected in the drop-down, but next to it we can create a new target.
Clicking on it, we can fill in the details as follows:
Now we can click on Save, which will display “Malvert1” under the “Scan Targets” option. We can click on Save to save the task. “Once” has been chosen as the schedule option to run the scan only once.
The Schedule option is useful when your scans are targeting your own infrastructure and you want it continuously monitored. The other options on the task have been left as default, as an exercise to see the outcome of the scan.
The bottom of the Task screen should look like the above. Now we click on the “Start” option to run the scan. The scan should take some time to run, as it looks through multiple threats and scans multiple ports. Once the scan is complete, we can look at the results under: Scans > Reports.
Analyzing the results
Now we’ll discuss the results. We’ll ignore all results with “of 0” present for now.
The Results tab provides us with a broad outlook of what occurred. “Services” checks for web servers running on ports other than 80/443. “CPE Inventory” tells us what software/OS is running on a system. In our case, the results were:
220.127.116.11|cpe:/a:nginx:nginx:1.17.9 18.104.22.168|cpe:/a:openbsd:openssh:7.4p1 22.214.171.124|cpe:/a:python:python:2.7.13 126.96.36.199|cpe:/o:debian:debian_linux:9
“SSH Protocol Algorithms Supported” is highly valuable as it goes one step beyond just finding an open SSH port and discloses the different SSH algorithms supported by the SSH service on the target (you can take a look at our Top 15 Best SSH Security Practices to learn more about SSH and to improve security for your SSH connections).
Another interesting check is the “Response Time / No 404 Error Code Check” which looks for a misconfigured 404 page.
The “Hosts” tab provides an overview of a short summary of the target IP/Host, the OS, Ports and Apps (not actually listing them but indicating how many).
The “Applications” tab lists the applications found on the target IP. The results we found were mentioned above, but we’ll quickly list them as: OpenSSH, Python2.7 and Nginx
“TLS Certificates” shows which CN issued the cert and its Activation/Expiry date. The results we have show that this IP has a Let’s Encrypt certificate being used that was activated on Wed, Sep 30, 2020. This confirms a point made by many infosec experts — that threat actors are using the free SSL certificates available to encrypt their websites too (using a combination of free SSL and stale DNS records, attackers can turn unused subdomains into phishing/malware attacks).
“Error Messages” is the last tab, which indicates what errors occurred along with the reasons for them.
Performing an advanced vulnerability scan
We can now create a more advanced scan by using the different configuration options to add custom details. In this case we’ll add custom ports and a larger IP subnet to scan.
First we will add a custom port list. Our targets will simply be the different SQL databases. Here is the full list:
- Microsoft SQL Server: 1433
- MySQL: 3306
- Firebird: 3050
- PostgreSQL: 5432
- Pervasive SQL: 3351
All of these are TCP ports, but the Port Lists option supports both TCP and UDP. Let’s add this list under: Configuration > Port Lists:
We expect to see quite different results from the default scan above, by narrowing down our focus to the SQL ports only.
Create a new target
Now we can move to creating a new target, which will be the larger subnet of the malvertising IP mentioned above:
Under Configuration > Targets, we can add the details of the subnet and our custom SQL Ports port-list:
We go back to Scans > Tasks, add the new task, and then we can run it. Once again we run this scan on the schedule of “Once”.
We ran into the following error when attempting to run the scan:
Host process failure (set_redisctx: Argument ctx is required).
We attempted the following to debug the problem:
- Reduced the size of the subnet
- Used one of the built-in port list options
- Changed the IP subnet to one of the domains in the subnet
After a considerable amount of time spent debugging, we found the issue related to Redis (either the temporary DB was too full or something else). What we did first was modify some configs in:
By modifying: ‘databases 16’ to ‘databases 128’.
Then we executed the following:
sudo redis-cli -s /var/run/redis/redis.sock flushall sudo service redis-server restart sudo service gvmd restart sudo service gsad restart sudo -S greenbone-nvt-sync
These changes managed to get the scan to run but the results we obtained were inconclusive.
We attempted a third scan using the subnet, but this time using one of the built-in Port Lists and setting the Scan Config to “Discovery”.
We’re documenting this failed test in our write up so that if you experience similar issues, you won’t be alone. We’ll also discuss the failure of this scan in our summary below.
Other notable features
The Resilience tab contains some interesting features. Here you can view existing Remediation tickets, and create and view both Compliance Policies and Compliance Audits.
The SecInfo tab is probably one of the most exciting features we discovered when testing OpenVAS. Under the different options like NVT (Network Vulnerability Tests), CVE (Common Vulnerabilities and Exposure), CERT-Bund Advisories and more, you can browse through the listed items and click on each to provide a quick summary of the vulnerability/test/item.
The Administration tab also provides a lot of useful functionality if you’re running OpenVAS among your DevOps/infosec team. You can add or modify users, groups, roles and permissions. For example, if you needed to create a view-only instance for external auditors to see your investigations after a possible breach, you could configure them as a guest account with viewing permissions only.
On each page/tab there is a button that links you to the documentation regarding that section. This is very informative as it allows you to quickly understand the purpose of each part of OpenVAS.
OpenVAS/GVM is a very powerful all-in-one solution for enterprise vulnerability management. If you’re working in an environment that needs this type of solution, it really is worth considering.
The biggest drawback for us when testing the software was that we spent more time configuring and debugging problems that required an advanced knowledge of Linux (systemd and Redis).
Another minor issue is the name change. If you search for “openvas” online, a lot of documentation referencing versions 8/9 will show up and it might not be clear that OpenVAS has now been renamed GVM and that there are versions 10/11 and more.
The naming of the various components is also confusing, and might require a steep adjustment and/or learning curve. Much time can be spent figuring out that a ‘gsad’, ‘gvmd’ and ‘openvas’ are all installed and would probably require reading the documentation extensively to understand the exact purpose of each.
Perhaps a drawback of all enterprise software is having complicated naming conventions, but OpenVAS/GVM being part of a larger component setup without making clear which parts are “open core” or what licensing is required probably makes OpenVAS/GVM more friendly to companies with legal teams to wade through the language.
*PPA: We’ve mentioned PPA a few times in the article, so it’s important to understand what it means. PPA stands for Personal Package Archives. These are community-provided packages and come with third-party risks. You can learn more about PPAs here: What are PPAs and how do I use them?