In this lesson, we're going to take a look
at a vulnerability scan report.
Now, a vulnerability scan report
is going to be produced by the system automatically
once you've finish doing your vulnerability scan.
Now generally, you're not just going to take this scan
and turn it into your boss though.
You need to actually do some analysis on it
to determine are these things right?
Whenever you do a vulnerability scan,
for each of these vulnerabilities, you need to look at them
and determine if they were detected by the scanner,
do they really exist in your system?
Because just because the scanner says they're there,
doesn't mean they're actually there.
Sometimes we'll have false positives.
For example, I've run scans
and I'll get things saying that I'm vulnerable to an exploit
because I'm missing a critical Windows patch
even though I'm running a Mac or a Linux system.
So that's one of the reasons why it's so important
to go through your vulnerability scan reports
and look at each identified vulnerability,
determine does it exist on your system?
And if it does, how severe is it
and how critical is it for you to get it fixed?
Then you create your plan of action and milestones
and you start remediating those things.
Now, when you look at a vulnerability scan report,
generally it's going to take a format
that's similar to this.
Most tools will have a more graphical-type format
where they'll use color coding to show you what is critical,
high, medium, low, or informational.
But at the end of the day,
what we're looking at is the information,
not the format here.
The same information that's on this report
will be on most other scanning tools
regardless of if you're using Nessus, OpenVAS, QualysGuard,
or any of the other vulnerability scanners out there.
It really doesn't matter.
They're all going to have basically
the same types of information.
Now, in general, you're going to have
your vulnerability scan report
start out with the report ID,
the scan date and time,
what system or version of software and definitions
were used to conduct that scan,
and then the name of the person who ran those scans.
Then you'll have a short summary
that's usually going to be called an executive summary.
If you're running a vulnerability scan
across a large network
that has hundreds or thousands of hosts,
you may end up having hundreds or thousands
or even hundreds of thousands of vulnerabilities,
and none of your executives
want to look through that level of detail.
So instead, you're going to summarize it
as a cybersecurity analyst or cybersecurity professional
to tell them what kind of themes and trends you're seeing.
For example, if you were scanning a network of 100 computers
and 50 of them are missing a patch
that was released five years ago,
that tells you you have a patch management problem
in that organization,
and you need to highlight that inside the executive summary.
Next, you're going to have
all of your vulnerabilities listed,
and generally they're going to list these
from critical to high to medium to low,
and then to informational.
Or you can also run these based on hosts.
So you can actually run the scan across 100 machines
and then have the report show you
which is the most vulnerable host.
Maybe you had one host that's missing 50 patches,
and you have other hosts that are missing only one patch.
So we would have the most critical
or most vulnerable host at the top
and then work our way down the list
to help us with our prioritization efforts.
Now, as we go through this report,
we're going to take a look
at these different vulnerabilities
and discuss them a little bit.
Now, when you look at this,
this is a very generic-style report.
Under the high-severity vulnerabilities,
the first thing we're going to see is our vulnerability ID,
and you'll notice it starts with CVE.
That is a common vulnerability and exposure.
Then dash 2021, which was the year it was released,
and then dash 34523,
which was the 34523rd vulnerability released in 2021.
The name of this vulnerability is CVE-2021-34523.
But to make it easier for us to understand what it is,
there's also a description.
This is a Microsoft Exchange Server
Remote Code Execution Vulnerability.
The affected system was the ExchangeServer01.domain.local,
and the impact is it allows an authenticated attacker
to perform a remote code execution.
Now, this CVSS score,
or the common vulnerability scoring system score,
is actually listed as a 9.1,
which is a very high score because the top score is a 10
and the lowest score is a zero.
The remediation that they recommend is to apply the update
provided by Microsoft in the security bulletin MS21-087.
So what this is telling me is we have a known vulnerability
on our Microsoft Exchange Server.
That's the bad news,
but the good news is there's an easy fix.
We can install this update,
which is a hotfix called MS21-087.
So if we go to Microsoft's website,
we download it and we install it on the Exchange Server,
this will solve this issue.
So we can do that, and then we could rescan the system
and we should see that vulnerability go away
because we've now patched that vulnerability.
The next vulnerability we have is CVE-2022-21882,
and this is a Windows Remote Desktop Protocol, or RDP,
Remote Code Execution.
The affected system is a desktop number 152
and desktop 178.
This particular vulnerability
will allow an unauthenticated attacker to connect via RDP
and execute arbitrary code.
The remediation is to install
the latest Windows security update
and disable RDP if it's not required.
Now, in this case, we actually have
two different recommendations here.
One is to install a security patch,
and the second one is to disable RDP.
So if these computers don't need RDP,
we don't even need to worry about the security patch
because we can just disable RDP
and therefore it's no longer going to be applicable to us.
But if we actually need to allow RDP
to remain open and available
because our service desk likes to connect it
to these desktops to be able to remotely support them,
then we're going to have to update that security patch
to make sure that it is no longer vulnerable.
The other thing I want to point out
between these two vulnerabilities
is the first one we talked about
said that it allowed an authenticated attacker,
which means that person has to be an insider threat
or have access to credentials for your organization.
But the second one is an unauthenticated attacker,
which means anybody, whether they're logged in or not,
would be able to connect over RDP with this vulnerability
if they're throwing the right exploit.
And that's why this is actually more severe.
Now, if it's more severe, why is the CVSS score lower?
Well, it's because of what it's impacting.
When you're dealing with RDP specifically on these desktops,
we are only dealing with a single workstation.
But when we're dealing with an Exchange Server,
it's serving everybody's email
across the entire organization,
so it is going to have a higher CVSS score,
and the way it attacks
and the ability you have once that attack is successful
will be more impactful,
and that's another reason why the CVSS score is higher.
The next one we have is a medium-severity vulnerability
that's called CVE-2021-25646,
and this is an Apache Druid Remote Code Execution.
Here, the affected system
is our analytics server number three,
and the attacker can send a specifically crafted request
to execute arbitrary code.
Now, because it is a specifically crafted request
and it's harder to execute,
it's only going to have a CVSS score of 6.5.
The remediation to solve this vulnerability is pretty easy.
We're going to install the latest version of Apache Druid
to address the vulnerability.
Now, unfortunately,
if there was no updated version available yet,
we wouldn't be able to do that.
Or maybe we're running this on an older server
that can't support the latest version.
In those cases, we'd have to come up
with compensating controls or other mitigations
to be able to address this vulnerability
instead of just updating it to the latest version.
Now, when you're analyzing these things
as a cybersecurity professional,
it's important to be able
to look up those CVEs on the CVE website.
If you go to cve.org and type in that CVE number,
you'll be able to get pages of information
about these vulnerabilities, how they work,
how they're exploited,
and different mitigations you can use to overcome them.
So keep that in mind as well.
If we move on to our second page,
we'll see we have two more vulnerabilities to look at.
The first one is number four,
which is vulnerability CVE-2022-22965,
which is the Spring Framework RCE
via Data Binding on JDK 9+.
The affected system here is our web application server,
and it allows the attackers to use crafted data
to bind expressions to execute arbitrary code.
Here we have a CVSS score of 5.3.
This is why it's a medium,
because it's a lower priority for us
and a lower criticality.
The reason is, this allows you to execute arbitrary code,
but it is not a remote code execution,
which means they have to be
physically present on the network
to be able to access this
and be able to send this crafted packet.
So in this case, we would remediate this
by simply updating the Spring Framework version
to one that has fixed this vulnerability.
The last vulnerability we have
is vulnerability CVE-2021-44228.
And the description here
is an Apache Log4j Remote Code Execution Vulnerability,
which is known as Log4Shell.
This affects our legacy server, which is an older server.
It is a remote code execution
in an application that uses Log4j,
so it only affects very few applications
and only the ones using Log4j,
and this makes it have a much lower CVSS score,
and it's down to a 3.7,
and you'll see in parentheses
it was mitigated by network controls,
which means we might have things in place
that are blocking people from accessing the server
and it's in an isolated area of our network.
And that reason makes it a much lower CVSS score,
because it is not as important or not as critical
at a high or medium level
because it is in this network isolated state.
To be able to remediate this CVE,
you're going to update to Log4j version 2.15.0 or higher,
and that will solve this vulnerability.
Now, after that, you'll have some additional findings.
This may be all of your informational findings.
In this case, we had a minor vulnerability
related to some outdated SSL certificates,
unused services running on several machines,
and misconfigured server headers.
In our real scanning report,
if you went to a detailed report,
we would see all of those listed out
with which machines, which IP addresses,
and which pieces of software
were being misconfigured on these different servers.
But because this is a summary report, we're not seeing that.
And then finally, we have some recommendations,
which includes prioritized patching
of high-severity vulnerabilities immediately,
reviewing your medium-severity issues
and scheduling patching in the next maintenance window,
and then addressing low-severity issues
per your standard patch cycle or when your resources allow.
Our conclusion is going to summarize the actions we've taken
and what recommendations we have.
In this case, it's going to say
the identified vulnerabilities
pose varying levels of risk to our network.
The high and medium-severity issues require prompt action,
and continued vigilance and regular scanning are recommended
to maintain the security posture.
This is the idea of what a basic
vulnerability scan report looks like.
And I will tell you, this one is a very simplified version.
You saw this was only on two pages
and it was covering an entire network.
But normally when I run this across an entire network,
I will have 50, 100, or even 500 pages of data
coming back to me
with all the details of every vulnerability,
all the criticalities, all the impacts,
and all the remediation actions that we can take
to improve the security of our network.
The bottom line here is when you're dealing
with a vulnerability scan report,
you need to take the time to look at it
and not just accept what they told you
was high, medium, and low,
because what that automatic tool tells you
is what is known in the common database
based on the CVE posture or CVSS score.
The problem with that is you may have mitigations in place
that these systems don't realize,
and because of that, you have to take that into account
and then mitigate these things.
For example, if I go back to the first page
and we had that high vulnerability for the Exchange Server,
well, if I know that the Exchange Server
is actually being decommissioned tomorrow
because we're going from Exchange Server 2016
to a modern Exchange Server,
that would tell us that that vulnerability
is going to go away anyway,
so we probably don't have to remediate it
here on the scan report,
and it's not nearly as high or critical for us
as it would be if we're going to be stuck with this server
for another six months or a year.
And so these are the things
that you have to know your organization and your network
to understand the impact
and the prioritization that needs to occur
for those vulnerabilities that you find
inside of your vulnerability scan reports.