Hackers are really good at finding tiny gaps in your security,
therefore a great way to protect yourself is for you to find the gaps first!
That's where vulnerability scanners come in.
They can automatically assess the devices on your network and find the gaps hackers might try to exploit.
Two of the most popular tools for this are Nessus and OpenVAS, also known by the name Greenbone.
Both of them have free versions that anybody can use, so the question is: which should you install?
Welcome back to the Pro Tech Show!
Before looking at these two tools, a quick note about what vulnerability scanners are;
and more to the point, what they are not;
because some companies are taking advantage of a general lack of knowledge to rip people off.
Patch scanners are not vulnerability scanners.
Missing updates can result in vulnerabilities, that's true,
but not all vulnerabilities can be fixed with an update.
Many vulnerabilities are not caused by unpatched software, but by poor configuration choices.
Sometimes an update will be released to fix a vulnerability;
but because it has the potential to cause issues for legacy systems
the fix will not be enabled automatically.
Patch scanners that present missing patches as vulnerabilities
will tell you it has been resolved as soon as the update is installed,
but the reality is you're still at risk.
Another thing that isn't a vulnerability scan is a penetration test,
although a vulnerability scanner might be used in a pentest.
A vulnerability scanner is a tool that checks for a list of known problems that hackers can exploit.
A penetration test involves a skilled human applying their brain to look for less obvious ways in.
An analogy: a vulnerability scan checks your door is locked,
your windows are secure, and you haven't left a key under your mat.
A pentester does that... but also dresses up as a gas man,
goes to see your neighbour, and asks if they have the spare key because they need to service your meter.
There are companies out there who are charging people for a full penetration test
but all they're doing is clicking a button to run an automatic vulnerability scan.
Be warned, the scammers are out there; but vulnerability scans are what we're concerned with here,
so when it comes to clicking that button... whose button should you click?
Let's introduce our two contenders: Nessus and OpenVAS.
These two are related. In fact the entire vulnerability scanning market is pretty incestuous.
In the beginning there was Nessus, and it was open source, until it wasn't.
What happens when an open source project suddenly switches gears and goes proprietary?
Someone forks it.
The fork was called GNessUs.
It was a horrible name and a bit too close to the original, so it got renamed to OpenVAS -
the Open Vulnerability Assessment Scanner.
It has since been renamed again to Greenbone Vulnerability Management,
making reference to Greenbone, the company that develops it;
but the name OpenVAS is so well known that it still hangs around
and these days the names Greenbone and OpenVAS get used pretty much interchangeably.
What might be interesting to know is that although there are lots of other vulnerability scanners out there,
if you look closely, most of them are actually running OpenVAS under the covers.
In fact, I could have called this video Nessus Vs.
Everything,
and it wouldn't have been all that far from the truth!
Both Tenable (the company behind Nessus) and Greenbone (the company behind OpenVAS)
produce commercial products with free versions.
It's the free versions we're focusing on, so let's compare their limitations.
Nessus is pretty straightforward.
The free version is called Nessus Essentials.
Disregarding the compliance and infrastructure as code scanning features of paid versions,
and focusing on traditional vulnerability scanning,
the primary limitation of the free version is that scans are limited to a total of 16 hosts.
Other than that, you're not really limited in features,
you just can't scan more than 16 things with it and you won't get free technical support.
OpenVAS is a little more confusing because they keep renaming things.
Greenbone Enterprise is the paid version.
It comes as a physical or virtual appliance,
and is a self-contained Linux distribution with commercial support.
There are two free editions.
The Greenbone Enterprise Trial is a virtual appliance based on Greenbone Enterprise.
The Trial version receives vulnerability definitions from the Greenbone Community Feed,
but not the Greenbone Enterprise Feed.
The Enterprise Feed adds detections for more products,
though what is and isn't included in the Community Feed seems a bit inconsistent.
Officially, the Community Feed covers "home application products"
and the Enterprise Feed covers "enterprise products",
but the Community Feed has detected plenty of server vulnerabilities
so I guess the developers think most people run servers at home?
I suppose the kind of people who run vulnerability scanners may well do,
but hey, a lot of what I run at home would be considered to be part of the Enterprise Feed,
so I have no idea where the line is here.
The Enterprise Trial edition has one more limitation to be aware of.
Although it receives updates for vulnerability definitions,
the Greenbone platform itself does not receive updates.
Ironically, over time, your Greenbone Enterprise Trial appliance will itself become a vulnerability.
Besides that, you can run it indefinitely.
You can get a time-limited trial of the Enterprise Feed,
but the appliance itself will run forever using the Community Feed
with no limit on the number of hosts you can scan.
There is another free edition, though, and that's Greenbone Source Edition.
The Source Edition is distributed as open source code.
It's basically the same as the Enterprise Trial,
but instead of being an appliance you can install it on another distro
and you don't have any issues with installing updates.
In terms of limitations: it uses the Community Feed
and there is no binary version provided,
so you have to either compile the code yourself
or use a distro that already does so.
Kali Linux is a good option.
They provide Greenbone Source Edition binaries within their standard repos,
and that's what I used for this video.
To confuse matters, you may also come across the Greenbone Community Edition.
Community Edition is what the Enterprise Trial used to be called.
They renamed it to better reflect the intention of it being a trial for the commercial product.
The problem is that when links to Community Edition suddenly redirected to Enterprise Trial
people got the wrong idea and thought Greenbone had done a Nessus and closed the source.
To clear up the confusion the name Community Edition has been resurrected,
but now it's an alternative name for the Source Edition.
But this means that depending on what link you follow,
something called Community Edition might take you to either the Enterprise Trial or to the Source Edition.
If you want to test Greenbone, the quickest way to get up and running is to download the Enterprise Trial.
If you want to run it long-term as your vulnerability scanner of choice
I'd instead recommend downloading Kali Linux and installing the source version from the repo.
That way you aren't locked out of platform updates, and you don't have to compile anything yourself.
Ok, now we know what's what, let's take a look at the user experience.
This one is a pretty clear win for Nessus in my book.
Greenbone's user interface is best described as "functional".
I mean it works, it's just not going to win any beauty competitions.
How much does this matter though?
Well, there's an element of personal preference here.
It works, and it provides the same information;
but Nessus does a better job of walking you through the setup of a scan,
with the options presented in a logical and digestible way.
With Greenbone, they're all there, somewhere, possibly in a different part of the interface,
or in a massive list of text.
Once you've run a scan, it's a similar story.
Both give you the same information, and both have ways to create and save filters.
Nessus does a few things more nicely, like grouping similar vulnerabilities together
and pulling out some remediation actions.
With Nessus, it's easier for a novice to spot the low-hanging fruit
that you probably want to tackle first after running a scan.
Although Greenbone is perfectly functional, the interface is dated and less easy to use.
Moving on from ease of use, how good are they at detecting vulnerabilities?
I have a couple of different scenarios to test this.
The first is what I'm going to call the "kill it with fire" scenario.
For this, I've downloaded the Turnkey Linux Drupal appliance.
This is a prepackaged LAMP stack with Drupal installed.
Basically, you mount or burn an ISO, run through a simple install wizard,
and you have a server running Drupal.
It's designed to get you up and running with minimal effort and minimal knowledge.
The version I've downloaded is an old one.
It's several years out of date and uses an end-of-life version of Drupal
running on an end-of-life version of Debian.
From a security perspective, it's a mess.
Sadly, this is something I do come across,
either because the web developer doesn't know anything about the platform their site runs on,
other than they click a button and website happens;
or because they handed over a perfectly functioning system to someone who never bothered to maintain it.
Pointing Nessus and Greenbone at this appliance turns up literally hundreds of vulnerabilities.
They use a similar scoring system to rate the severity of the vulnerabilities,
but Greenbone doesn't have a critical category.
A 10 out of 10 is still discounted as "high".
Looking at the raw numbers, you might think Nessus has performed better.
But in a case like this, the raw numbers don't really matter.
Whether your end-of-life Drupal install has 20 high severity vulnerabilities or 40
doesn't make any difference the action you need to take.
What's more interesting is the types of vulnerabilities each product has detected,
so let's break those down.
From the results here it's clear that neither solution was perfect,
with each missing a few items, although Greenbone did manage marginally better in terms of coverage.
I should note that Greenbone did log the untrusted SSL certificate,
but it didn't consider it to be a problem.
Nessus is working with its hands tied a little though.
We can change this option to have it run in paranoid mode.
That improves your chances of detecting vulnerabilities
but it does increase the likelihood of false positives.
If we do that, it finds a bunch more vulnerabilities,
but these ones are incorrect.
These are false positives. The target is not actually vulnerable to them.
For this test, I'd call it a draw.
Greenbone performed slightly better than the standard Nessus scan, but it's close.
Nessus outperformed Greenbone in terms of real detections when running in paranoid mode,
but it did so at the cost of introducing false positives.
Let's be honest though: this one was a sitting duck.
You're not going to run a vulnerability scan on something like this to find out if it's vulnerable.
You're either doing it because you've inherited a network and don't know what's on it,
or to gather evidence to convince management that they really need to spend some money.
Our next test is going to be more of a challenge.
It consists of a Red Hat server, a Rocky Linux server, and a Windows server;
all configured as a basic web and database stack.
Unlike the Drupal box, these are all running the latest versions of their respective software,
and I've installed all available patches from their native update service -
DNF and Rocky and RHEL's case, and Windows Update in the other.
I haven't performed any configuration to harden these servers, though;
and this is where vulnerability scanners are really useful.
A lot of admins would deploy this, run the updater, and consider it job done;
but is there more I could do to secure it?
Are the out-of-the-box defaults good enough?
What if I brought a few bad habits to the configuration?
To test our scanners I've added a few settings that are not good practice and will introduce vulnerabilities.
On Windows I've disabled Network Level Authentication for Remote Desktop,
which isn't exploitable itself,
but it does remove a layer of protection that may make other vulnerabilities easier to attack.
Another thing I've done is I've edited the SQL Express service's executable path to remove the quotes.
The reason for the quotes is to make it clear that this is a single string of text and the spaces are part of it.
If I remove the quotes, it will still work, but only because Windows has a guess at it.
Taken literally, this actually means
"Run a file called program, located on the C drive, and give it this as a list of parameters."
There is no file called program, so Windows assumes it's a mistake and figures out the correct path;
but if I did manage to place a file on the C drive called "program.exe"
that would be more correct; and Windows would run it instead,
under the identity of and with any privileges held by the service account.
The SQL service was configured correctly
but this is actually a common problem when software gets installed without adding the quotes
because the vendor wasn't paying due attention.
The software works, but it introduces a privileged escalation vulnerability.
On the Red Hat server I'm adding a similar and also very common misconfiguration.
I'm adding a cron job that calls DNF.
This is a fairly pointless cron job given DNF Automatic and makecache exist.
It's just an example.
The mistake is I have not provided an absolute path to the DNF executable.
It should be this.
Without the full path, how does Linux know where to find the file?
The answer, as many of you will know, is it searches the directories in the PATH environment variable.
Just like the Windows service account, this is imprecise;
and it introduces an opportunity for privileged escalation.
If an attacker can slip a file with the same name into a folder that's early in the search path than the real one,
then Linux will run it.
This last little misconfiguration I've added is setting the SUID permission on the "find" file.
The SUID permission, short for Set owner User ID,
causes the file to execute under the user context of the file's owner rather than the person who actually ran it.
There are times this can be useful, and several executables on a typical Linux system rely on it,
but you need to be really careful with it because it effectively grants temporary permissions you wouldn't otherwise have.
Setting it on the "find" file might appear harmless.
If you forget to run "find" with sudo, it might throw loads of permissions errors.
It's owned by root, so SUID lets it run as root;
and you're just looking for files, you're not executing anything... right?
Well, "find" can be manipulated to spawn a shell; and that shell keeps the permissions of the user running "find".
"Find" with SUID set runs as root, so now an unprivileged user account has a way to access a root shell and take control of the system.
That's why this is bad.
The final trap we've set for our vulnerability scanners is Rocky Linux.
Rocky is a RHEL rebuild. It's built from the source code of Red Hat Enterprise Linux, so it should be the same.
One of the challenges of looking for vulnerabilities on Linux is that the same version of the same program on different distributions can be different.
Red Hat, for example, will often backport security fixes to older versions of software the original owner has stopped supporting.
So the public instance of application X version Y might have a vulnerability, but application X version Y distributed by Red Hat could be perfectly safe.
Vulnerability scanners therefore need to not only look at the software that's installed on Linux, but also take into account its origin.
Is this the original version, or is it Red Hat's version?
Red Hat has been around for nearly 30 years and is very well supported by vendors.
Rocky Linux has only been around for a couple of years, so although they're effectively the same there's a higher chance a vulnerability scanner might not pick up on it and could generate a false positive result.
How did our two contenders fare?
This time around, Nessus has found considerably more vulnerabilities than Greenbone.
Perhaps more importantly, it found high and critical vulnerabilities that Greenbone missed.
The numbers don't tell all though, so let's take a closer look at what each of them found.
First, the highs and criticals.
Nessus has found a bunch of vulnerabilities in SQL Express.
This is accurate.
I ran Windows Update, but the patches for SQL were not distributed by Windows Update.
This is a very common issue I come across in the real world.
A lot of applications automatically install SQL Express as a dependency.
When the admin runs Windows Update, it doesn't get patched.
When they patch the application that installed it, it doesn't update SQL either.
There are a lot of unpatched SQL Express instances on production systems for this reason.
The next high severity vulnerability Nessus has found is an unquoted service path.
That's a vulnerability I introduced by removing the quotes on the SQL service executable path.
The next one: WinVerifyTrust Signature Validation.
This is one of those opt-in fixes.
The update to resolve this vulnerability was released years ago and is included in current versions of Windows out-of-the-box;
but unless you set a registry value to explicitly activate it, the system will remain vulnerable.
The Sweet32 detection means you're using weak encryption.
Both this and the last one are there for compatibility reasons.
Fixing them might break something, so Windows leaves it up to you.
Unfortunately, most people don't know these are even a thing, so they remain vulnerable.
Now we're into medium severity detections and we have a couple picked up by Greenbone but not Nessus.
Both of these I will dispute, however.
The keyboard execution one is basically saying you can plug in a keyboard and use it to type.
Yeah, really?
That's kind of the point of a keyboard.
It's not entirely stupid.
What it's getting at is that it's vulnerable to plug-in devices like a USB Rubber Ducky that emulates a keyboard to send malicious keystrokes.
The suggested solution is to whitelist specific models of keyboard and have it block every other model,
but this isn't the most practical suggestion for most people.
Even if you went to the effort of manually whitelisting every single model of keyboard you might ever need to use,
and never use anything else, this is a highly targeted attack.
It requires a physical device to be plugged in.
These things cost money.
You can't just blind fire millions of them like a spam email.
If you're going to go to the effort of using one of these to attack someone
I don't think it's a stretch to say you could find out a model of keyboard they have and tell it to emulate that.
I don't consider the ability to plug in and use a keyboard a useful vulnerability detection.
It's normal functionality and the suggested mitigation is tenuous.
The next one has similar issues.
It's possible to enumerate RPC services remotely.
Without going too deep: yes, that's how they work.
I would agree it's an issue if it's accessible from the internet.
It can't be exploited, but it does give away information that a hacker could use to help shape their attack plan.
On an internal network, though; if you block this on a Windows server you basically block it from doing its job or being managed correctly.
It's a by-design function.
Nessus does pick up on this, but it logs it as an informational event.
It doesn't consider it a vulnerability, and unless it's exposed to the internet neither do I.
Next, both Greenbone and Nessus detect the HTTP TRACE function in Apache as a vulnerability.
Apache disputes this.
They say it's a valid part of the HTTP specification and you can't exploit the server using it.
They're right.
The abuse of this function actually has more to do with badly configured load balancers or weaknesses on old web browsers.
It's not Apache's fault, but disabling this function can reduce the overall risk to your network,
and it's highly unlikely you actually need it in a production system, so I'm ruling in favour of the vulnerability scanners on this one.
Whizzing through the next few medium detections, and most of them are fairly non-controversial.
This one I'd probably argue should be a low, as it's not exploitable and more indicative that there may be incomplete configuration.
This one is detected by Greenbone, but as a log event. It's not considered a vulnerability.
My opinion is that if it's exposed to end users or the internet, it's a problem.
If it's only accessible from a privileged location such as localhost when logged onto a server, it's less of an issue, but it'd still keep it as a low in that case.
These detections are false positives.
Greenbone has managed to avoid them, whereas Nessus has a couple even on its standard scan.
Nessus did fall for the Rocky Linux trap.
The Apache vulnerabilities it found were because it compared to the public version of Apache instead of the Red Hat version used by Rocky.
The other two were a similar story, but it miss-detected them on both Red Hat and Rocky.
Of my planted configuration issues, Greenbone missed all of them.
Nessus found the unquoted service path and the disabled Network Level Authentication on Windows, but it missed the SUID permission and the ambiguous cron job on Linux.
Neither is perfect, but I'd prefer to trade a couple of false positives for the additional vulnerabilities detected by Nessus in this example.
Overall, I'd look at it like this:
do you have more than 16 hosts?
If you don't, Nessus seems to provide the most coverage and the best user experience when comparing the free versions.
If you have more than 16 hosts, Nessus will hit a hard stop, but you can keep on using Greenbone as far as you want.
Of course, either of these options is much better than doing nothing.
You might be surprised at how many problems they find, and if you're not really convinced that vulnerabilities like this actually matter
I'll show you exactly why you need to care about it in this video, where I actively exploit one of them and completely own a target system.
You don't want this to be you, but you do want to like the video and subscribe to the channel;
and let me know in the comments if you want a deeper dive into either of these tools.