Tasks

Task 1 — What Are Vulnerabilities?

The room kicks off with the leaky roof analogy. Small holes in the roof of your house. Looks fine, no big deal, until it rains and water gets in and ruins your couch. Fix the holes before that happens and you save yourself a lot of pain. The fixing-the-holes part is called patching.

Vulnerabilities in computers work the same way. A flaw in some software or hardware that an attacker can use to break in. The annoying part compared to the roof is that you can SEE a roof hole. You can’t see a vulnerability in software unless you’re specifically looking for it.

This room is about how to do that hunting in an automated way, because doing it by hand is impossible on any network bigger than three machines. We’ll cover what vulnerability scanning is, the different flavors of it, the tools people use, and then we’ll get hands-on with OpenVAS which is the big open-source option.

What is the process of fixing the vulnerabilities called? Patching

Task 2 — Vulnerability Scanning

So vulnerability scanning is exactly what it sounds like. Pointing a tool at a system (or a whole network) and having it check for known weaknesses. The tool has a giant database of “things that are bad” and it goes through and checks if any of those things are present on what you’re scanning.

Why does this matter? Two reasons. One, attackers are scanning your stuff whether you like it or not. The internet is constantly being scanned by botnets, researchers, attackers, and randos. If there’s a vulnerability on your public-facing server, someone is going to find it. Better that you find it first. Two, vulnerability scanning is a compliance requirement for basically every regulatory framework. PCI DSS wants quarterly scans. HIPAA wants regular scans. ISO 27001 wants you to have a vulnerability management program. So even if you didn’t care about security (you should), you’d still have to do it because some auditor is going to ask.

Doing it manually is a joke. The bigger the network, the worse it gets. So you use a scanner that automates the whole thing. You point it at an IP or a range, it does its thing, it spits out a report. Done.

Once vulnerabilities are found, you fix them by applying patches (those code or config changes that close the hole). That whole loop, scan -> report -> patch -> scan again, is called vulnerability management.

The two big distinctions

Vulnerability scans come in different flavors and the two main axes you’ll see are authenticated vs unauthenticated, and internal vs external. People confuse these, they’re not the same thing.

Authenticated vs unauthenticated

Authenticated scans are when you give the scanner valid credentials to log into the target. The scanner can look at installed software, check the config, see what versions of things are running, look at user accounts, the works. WAY more detailed. You see vulnerabilities that only someone WITH access could exploit. The downside is you have to manage credentials for the scanner, which is a hassle and a security concern in itself.

Unauthenticated scans are the scanner with no credentials. It only sees what an outside attacker would see. Open ports, banner versions, exposed services, that kind of stuff. Way less detailed but easier to set up and lower risk. This shows you what someone hitting you from the outside would be able to find.

Both are useful for different reasons. Real programs do both.

Internal vs external

Internal scans are run FROM inside the network. The scanner sits on a machine that’s already inside the perimeter. It sees what an attacker would see if they’d already gotten in (through phishing, a stolen VPN, an insider, etc). This finds vulnerabilities in your internal systems that aren’t supposed to be exposed to the outside world but are still important.

External scans are run FROM outside the network. The scanner is sitting on the internet somewhere and hitting your public IPs. This is the attacker’s view of you. What ports are open from outside? What services are exposed? Is there a vulnerable web app on port 443? This is what an opportunistic attacker would see scanning the internet.

A common confusion: authenticated/unauthenticated is about whether the scanner has login creds, internal/external is about WHERE the scanner is. You can have an authenticated external scan (rare) or an unauthenticated internal scan (more common). But the typical pairings are authenticated+internal (deep visibility into your own boxes) and unauthenticated+external (attacker perspective).

Which type of vulnerability scans require the credentials of the target host? Authenticated

Which type of vulnerability scan focuses on identifying the vulnerabilities that can be exploited from outside the network? External

Task 3 — Tools for Vulnerability Scanning

A quick tour of the popular vulnerability scanners. You’ll bump into these names a lot in the wild.

Nessus

The OG. Made in 1998 as an open source project, then bought by Tenable in 2005 who promptly closed it up and turned it into a commercial product. Still has a free version (Nessus Essentials) which is limited, and a paid version (Nessus Professional and the broader Tenable.io platform) which is what you deploy in enterprises. Probably the most widely-used commercial scanner. On-premises deployment, you run it on your own infrastructure.

The fact that Nessus started open source and went commercial matters here because OpenVAS (which we’re using in this room) is a fork of the LAST open-source version of Nessus from before Tenable closed it. So if you’re curious about the connection between Nessus and OpenVAS, that’s it. Cousins.

Qualys

Came out in 1999. Subscription-based, cloud-based platform. Big deal in enterprise because you don’t have to host or maintain the scanner infrastructure yourself, it’s all SaaS. Does vulnerability scanning plus compliance checks plus asset management. Continuous monitoring is its big selling point, it can keep scanning new stuff as it appears on your network.

Nexpose

By Rapid7, the same people who make Metasploit. Came out in 2005. Continuous discovery, vulnerability risk scoring (their own scoring system on top of CVSS, factors in things like how much the asset matters to you), and compliance checks. Has both on-prem and hybrid deployment. There’s also a SaaS version of this called InsightVM, which is basically the same engine but cloud delivered.

OpenVAS

Open source vulnerability scanner. Developed and maintained by Greenbone. The full enterprise version is called Greenbone Security Manager, but OpenVAS as the open source piece is free to use. Less polished than the commercial options, fewer features, smaller signature database, but it works and it’s free which makes it perfect for learning and for small orgs who can’t drop money on Nessus or Qualys. This is what the rest of the room uses.

A note on choosing between these. In real life it’s mostly budget and what the rest of your security stack already uses. If your company runs Rapid7 InsightIDR for SIEM, they’re probably also using InsightVM for vuln management. If they’re a Tenable shop, it’s Nessus all the way. Qualys shops stay Qualys. OpenVAS sees a lot of use in CTFs, training, small/medium businesses, and as a backup or comparison scanner alongside a commercial one.

All of them produce reports at the end. The reports list found vulnerabilities, severity, descriptions, and (in the better ones) remediation steps. Reports can usually be exported as PDF, HTML, CSV, XML, whatever you need to ship them off to management or the patch team.

Is Nessus currently an open-source vulnerability scanner? (Yea/Nay) Nay

Which company developed the Nexpose vulnerability scanner? Rapid7

What is the name of the open-source vulnerability scanner developed by Greenbone Security? OpenVAS

Task 4 — CVE & CVSS

Two acronyms that get thrown around constantly in vulnerability work. They’re often mentioned in the same breath but they do completely different things.

CVE

Common Vulnerabilities and Exposures. It’s just a unique ID system for vulnerabilities. Every publicly disclosed vulnerability gets assigned a CVE number so when people talk about it they can reference the same thing. Imagine you and your buddy are talking about a bug. You call it “that Apache thing from 2021” and he calls it “the log4j thing” and you’re both thinking of different bugs and you spend 20 minutes confused. CVE numbers fix this. Everyone just says CVE-2021-44228 and everyone knows exactly which vulnerability you mean (that one’s log4shell, by the way, and you should know it).

The format breaks down as:

So CVE-2024-9374 would be a vulnerability discovered in 2024 with the unique number 9374.

CVE numbers are assigned and maintained by the MITRE Corporation (the same MITRE that does the ATT&CK framework). The full database of CVEs is publicly available and you can look up any CVE number to read the details of the vulnerability.

CVE numbers themselves do not tell you anything about how bad the vulnerability is. CVE-2024-9374 could be a critical RCE or it could be a minor info disclosure, the number alone tells you nothing. That’s what CVSS is for.

CVSS

Common Vulnerability Scoring System. This is the severity rating. Every CVE gets a CVSS score from 0 to 10 (well, more accurately, 0.0 to 10.0) that tells you how severe it is. The score is calculated based on a bunch of factors. How easy is it to exploit? Does it need authentication? What’s the impact if exploited (confidentiality, integrity, availability)? Is there a working exploit out there? Etc. All of those plug into a formula that spits out a number.

The severity bands:

When a vulnerability scanner reports findings, every finding will have a CVSS score next to it, and your remediation prioritization usually goes critical first, then high, then medium, then low. In a real environment with thousands of vulnerabilities, you can’t patch them all immediately so you have to rank.

One important real-world note. CVSS score alone isn’t always the right priority signal. A “Critical” 9.8 vulnerability on a server that isn’t exposed to anything might be less urgent than a “Medium” 6.5 vulnerability on your public-facing web server that’s being actively scanned by attackers right now. Asset context matters a lot. Most mature programs use CVSS as ONE input to a broader risk calculation that also looks at asset criticality, network exposure, and whether the vulnerability is being actively exploited in the wild (EPSS, the Exploit Prediction Scoring System, gets used for this). But for this room, just knowing the basic CVSS bands is enough.

CVE stands for? Common Vulnerabilities and Exposures

Which organization developed CVE? MITRE Corporation

What would be the severity level of the vulnerability with a score of 5.3? Medium

Task 5 — OpenVAS

Time to use a vulnerability scanner. The room uses OpenVAS for the hands-on bits because it’s free and gets the job done.

Installation (skip if you’re just doing the room)

The room walks through installing OpenVAS via Docker, because installing OpenVAS the normal way is genuinely awful. It has a million dependencies, services that have to start in a specific order, certificates to generate, signature databases to download, and the whole thing takes hours and often doesn’t work on the first try. Don’t ask me how I know.

Docker side-steps all of that. Docker is a tool for running pre-packaged applications (containers) with all their dependencies bundled in. So instead of you installing all the pieces of OpenVAS yourself and praying, you pull down a container image where someone smarter than you has already done all the work, and you just run it.

The install steps if you wanted to do this on your own machine:

sudo apt install docker.io

sudo docker run -d -p 443:443 --name openvas immauss/openvas

The image used is immauss/openvas which is a community Docker image that packages everything into one container. -d runs it in the background (detached). -p 443:443 maps port 443 of the container to port 443 on your host so you can hit the web interface at https://127.0.0.1.

For the room, OpenVAS is already installed on the provided VM, so you don’t need to do any of this. Just hit start machine and go.

Accessing the interface

Open a browser, go to https://127.0.0.1. You’ll get a cert warning because it’s a self-signed cert. Just click through, this is fine for a lab. Then you get a login page. After logging in (default creds are admin/admin in the lab) you land on the dashboard.

The dashboard shows you summaries, recent tasks, severity breakdowns, the usual stuff. Not super useful when you haven’t run any scans yet.

Running a scan

The workflow is to create a Task, point it at a Target, run it.

  1. Click “Scans” in the top menu, then “Tasks”. This shows you all your scan tasks, which is empty right now.

  2. To create one, click the little star icon (top left of the tasks table) and pick “New Task”.

  3. Give the task a name. Now you need a target. Click the star icon next to the Scan Targets field and pick “New Target”.

  4. Give the target a name (e.g. “Test Server”) and enter its IP address. Click Create. You’re back at the task creation form with that target selected.

  5. There’s a Scan Config dropdown with several options. “Full and fast” is the typical default and works for general use. Other options exist for specific cases (web app scans, deep scans that take forever, etc). Click Create.

  6. The task now shows up on the Tasks dashboard. To run it, click the play button icon under Actions.

  7. Wait. Scans take a while, this is not a fast process. Even on a single host it can take minutes. On a network range it can take hours. Be patient.

  8. When it’s done, status changes to “Done”. Click the task name to see results.

  9. Click on the count of vulnerabilities to see the full list. Each vulnerability is its own row with name, severity, CVSS score. Click any individual one for the full details, including description, the affected service, and (if available) suggested remediation.

  10. Reports can be exported in tons of formats. PDF for sharing with humans, XML/CSV for shoving into another tool.

The room asks two specific questions about the example scan that they showed: the IP of the scanned machine and how many vulnerabilities were found.

What is the IP address of the machine scanned in this task? 10.10.154.44

How many vulnerabilities were discovered on this host? 13

Task 6 — Practical Exercise

Now the exercise. The setup is that you’re an info sec engineer at a firm and the security team has already run an OpenVAS scan on a critical server. The report is sitting on the desktop of the provided VM. You can either just open the existing report (faster) or run a fresh scan yourself (slower, but you get to do the whole flow).

Start the machine. Once you’re in, you’ve got two options.

Option 1: Just read the existing report

The report file is right there on the desktop. Open it. You’re looking for the high-severity vulnerability that was found on the scanned host.

Option 2: Run the scan yourself

If you want the full experience, start the OpenVAS container first because it’s not running by default:

docker start openvas

Then browse to https://127.0.0.1/login/login.html. Login with:

Create a task, point it at MACHINE_IP (the target’s IP), pick a scan config, run it. Wait. Heads up the scan can take a real while. The pre-made report is on the desktop specifically because the scan is slow.

What you’re looking for

Either way, once you have the results, look at the list of vulnerabilities and find the one marked High severity. It’ll have a CVSS score of 10.0 which puts it at the top of the High range (and basically into Critical territory, depending on the CVSS version OpenVAS uses to band them). A score of 10.0 is the maximum, this is as bad as it gets.

Click into that vulnerability to see the details. Scroll down to the Solution section. OpenVAS includes a recommended remediation, and for this one the suggestion is basically “change the password.” Which is a big hint about what kind of vulnerability this is, almost certainly some kind of default or weak credentials issue on an exposed service. SSH with root:root, MySQL with no password, that kind of “how did this even ship like this” finding that you’d be horrified to see on a real production server. Yet absolutely you find this in the wild more often than anyone wants to admit.

What is the score of the single high-severity vulnerability found in the scan? 10

What is the solution suggested by OpenVAS for this vulnerability? Change the password of the mentioned account(s).