All right, vulnerability research.
Everything we've just been talking about, everything up till now in this modulethas
been finding things that we previously haven't detected, things that have made it
past our AV, things that we don't necessarily have, or endpoint detection,
things that we don't necessarily have signatures for.
This would be after the fact, after we've
done our vulnerability research and vulnerability analysis.
I might have actually ordered the module a
little bit differently, but we're going to talk now about vulnerability research,
vulnerability assessments, and pen testing.
A lot of this is going through cataloging
your devices and identifying known vulnerabilities using known databases of
known vulnerabilities, and then also utilizing a lot of automation,
vulnerability scanners, things like that, for automating the process.
A lot of your security testing and assessments is automated.
That's the reason we have computer tools.
They make repetitive tasks more efficient.
But there's always something to be said about the human component.
We can try to automate all this stuff, but
at the end of the day, nothing quite replaces that human discerning judgment.
But vulnerability research is a process of analyzing protocols, services, and
configurations to discover vulnerabilities and design flaws that will expose an
operating system and its applicationsto exploit, attack, or misuse.
Your vulnerabilities are classified based on severity levels, which is typically as
broad as low, medium, or high, and exploit range like local or remote.
The low, medium, and high is based on the criticality, the sensitivity, the
resultant impact of the vulnerability being compromised.
The exploit range is whether the vulnerability can be exploited locally,
meaning you have to be on the box, or remotely, which means you've got a
network listener, something that can be connected to to deliver the exploit.
An administrator needs vulnerability research to figure out what needs to be
rectified in their network before attackers find it and exploit the system.
So a vulnerability assessment itself,
you have security audits, vulnerability assessments,
penetration tests, and a variety of other types of security tests.
An audit checks for compliance.
So all you're really doing is determining
whether or not you're following a set of prescribed standards.
The vulnerability assessment is where you're going in and cataloging known
vulnerabilities based on discovered systems.
The penetration test is where you go in and actually exploit the vulnerabilities.
So penetration test proves the exploits are exploitable or the vulnerabilities are
exploitable, and then you recommend your remediation measures.
We will be talking more about that here in a few slides.
The vulnerability assessment, an in depth
examination of the ability of a system or application to withstand the exploitation,
identifying weaknesses that could be exploited, predict the effectiveness of
additional security measures, protecting information and resources from attacks.
Now, a lot of times we'll do this using a scanner.
Scanners like Nessus, Open Boss, LandGuard, Saint, Retin, Xpose, etc.
Information that is obtained from the vulnerability scanning process, you're
going to start off with discovery of operating system version,
service versions, software versions, and so forth.
Open ports and running services,
application and service vulnerabilities, application service configuration errors,
accounts with leak passwords, missing patches and hot fixes.
Now, there's a couple of different categories of vulnerability scanners.
There's a couple of different categories
of how invasive or authenticated the scan can be.
So if you're running a vulnerability
scanner on a local box, you might be running it with elevated privileges, and
it can look into the registry, look at accounts and so forth, look at everything.
If you're running a scan from a network location and you don't supply a valid set
of credentials, you're going to see a lot less.
So depending on what your reasons for the
test are, you're going to determine what the best way to test is.
For example, if we're determining how easy it would be for an attacker to discover
vulnerability from the internet, we'd use a network based scan from our location.
If we wanted to get every possible issue on a system,
software installed, applications, patches, and so forth, we might decide to run a
command line interface or on local box with admin privileges.
We're going to differentiate between the
different types of scans here in a few slides.
Two approaches, speaking of which, two
approaches to network vulnerability scanning.
You have active scanning, which is interacting directly with the target to
find vulnerabilities, also known as intrusive.
An example, the attacker sends probes and specially crafted packets to the target
host and the network to identify vulnerabilities.
In passive scanning, you're trying to find vulnerabilities
without directly interacting with the target network.
Okay, anything that's passive in nature, you sit by and just see what you can see.
In active, you actively engage the target.
This gets you detected pretty quickly, this does not.
If I'm passive and I'm just sitting there
not saying anything and just listening, I'm much less noticeable than if I am
blurting out questions and probing and poking at you and demanding responses.
Passive generally gives you less useful
detail information than active because active allows you to probe directly.
Again, if we are worried about being
detected, we might choose passive types of footprinting.
If we're not worried about being detected, we'd definitely run active scans.
The vulnerability scoring systems and databases.
I'm going to show you an example here of a Nessus scan.
Now, you know a lot of labs on this, but
every so often, we're going to break it up here and show you a little demo.
Vulnerability scoring systems and
databases are helpful for rating the severity of the vulnerability, especially
when you're presenting your findings to a non technical type like an executive.
I've got a couple of examples for you here.
The CVSS version 3 versus version 2, you can see the severity level and then the
base score range and there are various criteria go into that ranking.
We don't need to really deliberate too much on that.
Then we also have the common vulnerability
scoring system calculator, which does give you a breakdown of everything.
And there's some temporal and a couple of subcategory scores.
We'll keep it at a nice high level here
and say, hey, on a scale of 1 to 10, this thing's a 10, or a 3, or a 4, etc.
Now, a lot of times this is actually given in the results of a vulnerability scan.
Let me show you an example of a vulnerability scan using Nessus.
Let me go back to my scans.
These are a couple demos I do with a CEH class.
Demo number 2, I run across my 10 subnet,
and we've got a real range or spectrum here of legacy systems,
number of vulnerabilities to a much lower ratio of vulnerabilities to newer systems.
For example, my 2003 systems got lots of critical vulnerabilities.
Those criticals typically have base scores
of a 10.0. On a scale of one to 10, that thing's at 11,
which is helpful when you're communicating these vulnerabilities to a stakeholder,
you try to explain a buffer overflow, they're nodding like, Is that bad?
Well, on a scale of 1 to 10, it's a 10. Oh, get it.
Okay, that's bad.
So that rating system is helpful to communicate the severity of the
vulnerability in a universally understood metric.
My 10, 0, 0, 19 machine is a patch 2019.
You see much less critical vulnerabilities.
And the local versus remote exploitation, which we talked about, you're seeing a lot
less remotely exploitable vulnerabilities as the operating systems evolve.
A lot more emphasis on client side or application vulnerabilities.
The rating system is included in the Nessus report.
And then you've also got
references to the database entries like common vulnerabilities and exposures,
which is our master catalog, probably our largest vulnerability repository.
It's been around since 1999, and everything is IDed by year of discovery
and ordering inclusion, and the CVE is viewable.
Let me change a couple more examples here.
Let me actually back up here.
Let's do a critical.
All right, so this particular
vulnerability gives us a base score, again, of 10.0.
Our temporal score, again, we're not going to worry too much about that.
If you scroll down, you'll actually see it's CVE Identifier down at the bottom.
Microsoft Knowledgebase article.
Bug Track ID was a database maintained by
Security Focus, which is no longer the same.
It was purchased recently in the Bug Track database is quite different.
Then the Microsoft Security Bullet for it.
Knowledge based article, Security Bullet.
If I click on this CVE, it takes me to
NIST's National vulnerability database listing for that vulnerability.
Let's contrast that with the CVE on meter.
Org, where I can view the CVE list, sorry, downloads, all items HTML.
This shows you a little bit on the format here.
Again, it's CVE, prepended, 1999 order of
year of discovery, 0001, number and order of inclusion.
It gives you some basic information about the vulnerability.
A bunch of references, not much on remediation, which is why the references
are there so you can look up more information on the vulnerability.
A lot of times this stuff gets included in the results from your scanner.
Again, we've got the National vulnerability database.
Let's back up here.
Then you can go out to various exploit
database sites like Exploit DB and lots of other security research sites.
All right,
sothis National vulnerability database, which again, that CVE identifier doesn't
really tell you a heck of a lot about the vulnerability, but lots of references.
And it gives us a master catalog or index number which we can use to
commonly name it and cross reference it between different databases.
The common weakness enumeration is a variation on the common vulnerabilities.
Category system for software
vulnerabilities and weaknesses sponsored by the National Cybersecurity Initiative,
owned by the Meteo Corporation with support from US Cert.
Again, this is the same body that controls
or maintains the CVE, and you're going to be doing a lab on CWB.
Types of vulnerability assessment.
Again, you have an active assessment using
a network scanner to find host services and vulnerabilities.
Passive, which is just sniffing network traffic, we've talked about this.
External is where you're scanning from and what you're scanning.
Internal is also where you're scanning from and what you're scanning.
Outside the security perimeter against
publicly available devices would be an external assessment.
Inside the perimeter against devices that
aren't necessarily publicly available would be an internal assessment.
There's a lot more to attack internally than externally, without a doubt.
When you're doing a penetration test,
where you're launching the test from, external or internal, has a huge impact on
what you have access to and what you can identify and exploit.
You're basically running a scan from one or both locations, and then you're
cataloging OSes, software versions, and then probing for vulnerabilities.
A host based assessment is a configuration level check
configurations, user directories, file systems, registry settings, etc.
To evaluate the possibility of compromise, you run that on the local host.
Network based assessment, you're running
from a network location, determines possible network security
attacks that may occur in the organization system.
Application assessment is a typically web
applications is what we're talking about here.
Those types of scanners are more pricey
for sure and do a lot of heavy lifting for you.
Test and analyzes all elements of web infrastructure for any misconfiguration,
outdated content, or known vulnerabilities.
Then database assessment, a lot of that is actually done through application
assessment since a lot of database attacks occur through web applications.
So focusing on testing databases like MySQL, MSSQL, Oracle Postgres, SQL, etc.
Looking for things like SQL injection.
Then we've got a wireless variety network assessment which determines
vulnerabilities in the organization's wireless networks.
I think that goes without saying.
But you're scanning for rogue devices,
unauthorized access points, weak protocols, weak configurations.
A credential assessment is where you enter
a username and password combination in the scanning tool, which gives you maybe an
unrealistic advantage as the tester, that may not be the same level of access that a
threat actor or a hacker has, but it can also give you a lot more information.
Again, there's a couple different reasons
for running a vulnerability scan or vulnerability assessment.
One is to get an accurate picture of what could be discovered by an unauthorized
attacker, and the other is to get every possible issue so that it can be
remediated because you need to correct the vulnerability.
One of them simulates an attack from the outside world.
One of them doesn't.
A ctually, there's two different flavors of pen test, white box and black box,
we're going to talk about here shortly, which also is based on the amount of
information you have about the target prior to the assessment.
Manual assessment.
You are manually assessing vulnerabilities, ranking, score, etc.
You're not using a tool.
You're doing things old school, living off
the land, using native tools, and so forth.
Then distributed assessment.
Assess the distributed organization's assets, client server applications,
simultaneously through appropriate synchronization techniques.
Again, you're looking for a distributed architecture.
Non credentials.
We don't have any credentials.
We can't log into it.
This again simulates the opposite of a credential assessment.
Then automated assessment, we run an automated scanner.
Automation is great.
Gets a lot of things done automatically,
but you still want to supplement that with manual assessment, without a doubt.
The vulnerability management lifecycle.
The life cycle is to identify assets and create a baseline.
First off, catalog and inventory your systems.
Then run a vulnerability scan,
then assess the risk associated with the discovered vulnerabilities.
If it warrants remediation, remediation is removing the vulnerability.
Apply a patch, some configuration procedure.
Verification is verifying that the vulnerability has
been remediated, and then ongoing monitoring.
This is a circular process, round and round and round, never ending.
A vulnerability management program is
always being updated, always ongoing, running vulnerabilities at periodic
intervals, remediation, wheel goes round and round.