[MUSIC PLAYING]
In our first lesson on vulnerabilities,
we're going to start with, what is a vulnerability?
So you might think many different things, frankly,
when you start thinking about what a vulnerability is.
For anyone who's been around in the space for a while,
you might automatically go to CVEs.
And while that is important and it's definitely
something we're going to cover, there's
more to vulnerabilities than just that.
NIST had a nice definition of it for us.
It's very technical.
A weakness in computational logic code
found in software and hardware components
that, when exploited, results in a negative impact
to confidentiality, integrity, and availability--
or availability, and/or.
I like to think of it all like a heist.
I love thinking about cybersecurity like a heist
because what we're trying to do is protect something
that other people want to get.
Now, in a heist, thinking of a heist movie
or real life crime--
I don't know.
This stuff might actually happen.
I just don't hear about it.
There's jewels.
There's money.
There's information that's being stored somewhere.
And a group or an individual is trying to get access to it.
And if you think about any of the movies
that you might watch--
I love heist movies--
there's so many different pieces that go into it
that they have to think about.
And there's many different vulnerabilities.
There's little things that can be exploited to get in.
Now, generally, for a heist or bank robbery,
you might be thinking about physical vulnerabilities.
And that's a layer on the OSI model.
We got to think of the full stack of the OSI model.
And the physical layer is there.
You can cut power.
You can cut lines.
You could gain physical access.
You could get around people.
That is very important.
And that's something that we have
to worry about ourselves when talking about cybersecurity.
There are physical controls.
And that is something that's really important.
Man traps, vaults, proper door locks, gates, fences, lighting,
cameras, those are all parts of physical controls.
And there can be vulnerabilities in those as well.
Let's move to some more in the computer type things.
Cybersecurity vulnerabilities-- they
are weakness which can be exploited by a threat actor.
And there is a whole course specifically about host
and system based attacks, where you will dive in and learn
how to exploit really well vulnerabilities on a machine,
usually about the operating system or a service running
on it.
And those are the common places where
these technical vulnerabilities come from,
from the operating system itself or a service that
is part of the operating system or in something that's
been installed, a service that's running that's software
installed on that machine.
So these can be found either by DevSec engineers, people
who are looking at applications, updating them, looking
for these vulnerabilities in the products
that they're putting out or that they're now working on
for their team.
Security researchers-- got some good friends
who go ahead and do this on the regular for MSSPs
or researching firms trying to find vulnerabilities to better
our infrastructure, our ecosystem.
Pen testers often find vulnerabilities.
The difference between a pen tester
and a cybersecurity researcher is a very narrow line.
It all depends on what your scope is,
what you're doing day to day.
But they think a lot the same.
Software developers might find their own vulnerabilities.
They might find vulnerabilities in other people's code.
Again, the lines between these different roles are very thin.
Users-- users often find vulnerabilities.
And by playing like a user, that's
often how researchers or pen testers come
across some vulnerabilities.
Fortunately, the United States government in it's
always putting a lot of money and effort behind things
no matter what has a national cybersecurity federally funded
research and development center that worries about CVEs,
that tracks the CVE program.
CVE is being common vulnerabilities and exposures.
And there is a CVE website that is
managed by MITRE Corporation.
They maintain the system and a lot of the logistics behind it.
And it's funded through the National Cyber Security
Division of US Department of Homeland Security since 1999.
Or at least it's been around since 1999.
Homeland Security-- not so much.
We've got NIST, who maintains the National Vulnerability
Database.
It's very similar, very related.
And we will take a look at both the CVE page and the National
Vulnerability Database.
Now, CVEs have identifiers.
You could also call it a CVE name, number, IDs, or just
CVEs, CVE blank.
A few that we're going to look at--
CVE-2021-44228, Log4j.
If you're seeing this, there's a fresh course.
You might not want to hear that term, Log4j, right now.
CVE-2014-0160, which was the Heartbleed vulnerability--
we'll dive into that one.
And then CVE-2017-0143 or MS MS17-010,
also known as EternalBlue, part of the WannaCry ransomware.
And NotPetya and a few others.
These are vulnerabilities that had high impact
or were critical vulnerabilities.
And we'll dive into what all that means with some examples
in just a second.
The things that we kind of need to understand
and get comfortable looking at are the vulnerability details
pages.
So there's going to be a description.
It'll go into severity.
And we'll talk about severity while we're
looking at the page.
And there's a nice tool that we can
look at to kind of weigh the severity ourselves
to criticality, depending on our situation
and how a vulnerability actually goes from the impetus to being
exploited or used.
Some weakness enumeration and preferences--
what white papers, what exploits,
what proof of concepts have been collected
as part of the database.
Again, this enumeration, what do they produce
or what has been collected so that these vulnerabilities
can be found more easily by vulnerability scanners
or other research firms?
And then known affected software configurations--
that's also quite important.
Those are things that as a pen tester
you might want to become familiar with.
Some of the obvious ones come out at you.
And we'll talk about those when we get there.
But others-- if someone is implementing,
these software configurations, they
need to be aware that the vulnerabilities exist in them
prior to implementation.
And we'll get to it later.
But accepting certain levels of vulnerability,
certain levels of risk, it's kind of up to the organization.
But they need to be aware of what is out there.
So we're going to swap on over to the CVE page.
This is CVE-2021-44228 Log4j.
And let's take a look at what we got.
We have the CVE ID.
And there's a link to the National Vulnerability
Database.
They are interconnected.
And we will look at both.
Then we've got a description.
And so this one, it says that Apache Log4j 2.0-beta9 through
to 2.12.1 JNDI features used in configuration, log messages,
and parameters do not protect against attacker controlled
LDAP and other JNDI related endpoints.
Now, this might not make any sense to you right now.
And that's fine.
In the next lesson, we're going to go
into the details of what all this means
and what it means for an attack.
But you can see here that there's a description of what's
going on.
There's some technical jargon.
And if you weren't a programmer, if you
haven't worked with Java, if you aren't familiar with LDAP,
then this might not make a lot of sense to you.
And we will get to that in a little bit.
I promise.
But the important thing here is seeing that there is
an explanation of what's going on and we can read that and use
that later, as you become more familiar with all of these
things, because that's kind of what's required
in cybersecurity-- become more aware of the different
technologies, the different languages,
the different software being used and how we can either
utilize it for pen test or help organizations become more
secure by pointing out the vulnerabilities and being able
to explain this and why this is a problem--
that's going to go in our report.
We need to understand what this means.
If we exploit it and we can't explain why it matters,
then there's no value in our report.
So that's important to understand.
I'll give you the full screen so you can see it better.
It goes into some more detail, some more versioning.
That's fine.
There's references.
And these can include proof of concepts,
articles, white papers.
And these actually feature different versions of software
here, which is [INAUDIBLE].
You can see who the assigning CNA is.
And that's the CVE numbering authority, the CNA.
This one, its Apache Software Foundation.
Apache owns and produces Java and Log4j.
So it kind of makes sense.
See the date created, came out at the end of November 2021,
and the date reflected when it was allocated or reserved,
not necessarily when it was discovered.
So that's important to know.
That is the CVE page.
Sometimes there's more information.
But this one usually just launches you
to the NIST National Vulnerability Database.
Now, we see the same information, CVE-2021-44228,
with details and another description.
These are very, very similar.
Pretty much the exact same language.
Now, here there is analysis description,
which in this situation is the exact same description.
That's fine.
If it gets updated, then this information might change.
That's perfectly fine.
That's good.
You want the most up to date information in the database
correct.
So here we have a gauge of severity.
And there is an older version and a newer version.
I tend to just look at the 3.x.
But there is debate on which one is more useful.
And we'll dig into criticality.
In just second, I'll come back up to it.
There's the references to advisory, solutions, and tools.
And in here, there's websites talking
about how to utilize it.
We should have some tools and proof of concepts in here.
And then we get into the weakness enumeration.
So this, they're created by these sources.
So either Apache themselves or NIST alongside the Apache
came up with CWE IDs.
And we could dive into those and what they mean.
But, basically, the weakness enumeration
then is part of identifying how this could be solved
in the future and avoid it.
But your known affected software configurations
are critically important.
The CPE is hugely important.
And if you're at all curious what a CPE is,
NIST has this understanding vulnerability details pages
and description.
It gives an explanation of that, explains severity references
or what they are.
But your it affected software configurations--
this common platform enumeration specification
is very, very, very important.
This is how vulnerability scanners are then
going to take this signature, if you will,
to find the vulnerability throughout an ecosystem,
throughout a network.
And you dive in and read the heck out of this.
It's worthwhile to get an understanding of it
and if you were searching for a specific vulnerability
to become familiar with the CPEs.
But there are a lot of configurations.
Java is used in a lot of places.
And over 84% of Java applications
utilize the Log4j library.
So there it is, all the places it
is used, which I'm going to use that to bring us back
to this base score for criticality.
And you can see if I hover over the critical right there,
it highlights.
We can click on it.
And it brings up the scoring calculator.
Now, there are some base metrics, base score metrics.
And that 10.0 was a very big part of it.
And a lot's based on how the attack vector gets in.
It comes through the network.
You have to be on the network.
Some of it, you need physical access.
You just need local access.
You can be on an adjacent network.
That will change your base scores--
the complexity.
It's not a very complex attack.
You're exploiting the vulnerability.
It doesn't require any privileges.
User interaction is low.
You don't need someone else to click on anything.
The scope in this situation has changed.
And you can get into the details of what all
that means if you really want to.
And then there's the impact.
And, again, impact is going to be
the part that really is going to matter to our customers.
They want to know.
And that's the customers or our pen test
or our security net analysis, if you will.
Whoever it is that we're turning over the results to
and whoever is going to take this and run with it,
they need to know what the potential impact is.
And so that's why these are worth looking at.
Confidentiality, integrity, and availability
are very high for this because if exploited,
they can run whatever code they want.
And you could change data.
You could deny data.
You could steal data.
And that's all three.
That's all three sides of the triad.
Now, if we dig in a little more, this temporal
score-- you could see there are functional exploits that exist
because it's been exploited.
The remediation level has an official fix.
Java has put out a fix, and a lot of organizations
are implementing those changes.
A lot of software vendors in this situation
had to update-- once they updated the Java,
then they had to update their application,
and then organizations needed to then update and patch
that software once the patch was available.
And there is confirmed report confidence.
So that's high.
And then if we look at exploitability metrics,
this is where we can see an impact
on the score in a highway.
Already by changing that temporal,
it dropped down to a 9.3.
That still matters.
That still matters a lot.
But if you only need access to the network,
you could be actually in--
yeah, in the network, the complexity is still low.
If you find a place to do your JNDI injection,
then the rest kind of falls together.
It's not very complicated.
You don't need privileges usually.
User interactions-- none.
You don't need anyone to click on any links in emails.
In this situation, it shows you what
unchanged or changed means.
We went with unchanged and then high impacts.
And here, requirements is useful.
And again, these ones are going to be high.
We can see how the modifiers change the overall score.
Now, in the end, doesn't matter that much.
It's still a 9.1.
So the severity-- it's very severe.
Then it becomes, OK, what's the impact?
If they have something that's publicly
facing that anyone can attack and it takes down
the whole server, then that's not good,
especially if they don't need to be authenticated
and there's no way of protecting it.
Now, during your pen test, you will find
how critical it actually is.
If it's exploitable, you can say how you exploited it
and how easy it was to do and give recommendations
for remediation.
What could they put in place to avoid that and stop it?
If it's as easy as patch the software, that's one thing.
But what if they can't patch the software?
What if it's an application that requires that older
version of Java, that requires that older version
of Log4j for some reason?
The software vendor that created the software that's
being used by the company, maybe they've gone out of business.
Maybe they can't patch.
These are all things that need to be taken into account when
you're making recommendations from your pen test,
from your reports.
Now, those are our vulnerability details pages,
both from the CVE page and the National Vulnerability
Database.
And you might be wondering about zero day attacks.
These vulnerabilities that we were looking at
have all been submitted to the CVE numbering authority,
and they have determined that it's worth actually posting
somewhere to the CVE database.
Now, there's going to be exploits out there
for vulnerabilities that haven't been found.
That we call a zero day exploit, meaning no one else
knows about it, or no one else has exploited,
or no one else has at least reported it
to the CVE organization.
Many pen testers like to find zero days.
It bolsters you as a pen tester in a lot of the community
for finding something by going through the fuzzing steps,
by doing the research, by identifying something
that the developers didn't find, that no one else found.
And there's a lot of prestige among some pen
testers for finding and utilizing zero days.
And that's neat.
Software is going to be vulnerable.
And if you can find one, utilize it.
Help the ecosystem, help the industry
by identifying these things, putting them in your reports,
and sharing them with a numbering authority.
That's going to help everyone.
And that's all good things.
Now, not all vulnerabilities are computer code.
We talked about this when we were talking about heists
and physical security.
You've also got layer 8, the people.
Often, social engineering and utilizing interpersonal skills
are going to be just as helpful for a hacker or a pen tester
in order to get access to information or the network
as a whole.
That can include using known social engineering
techniques for passwords or taking advantage
of maybe some of your physical operational technology
controls, such as card readers or access badges.
If you can make up an access badge that looks like it's good
and you know that the guards don't check that well
and there's nothing stopping someone
from tailgating, perhaps, through a gate if there
is a gate, then that's an easy way for an adversary,
or a pen tester pretending to be an adversary, to get in and get
physical access.
If you get physical access to a network,
then it changes the game.
There's a lot of things that you can do internally
that will give you more access than if you were
trying to attack externally, maybe through a web server
or externally facing services.
Again, scope, impact, and usefulness
will all come down to business needs.
Smaller businesses might look at things differently.
Giant corporations might look at things differently.
Hospitals or banks or specific organizations
with specific needs and compliance and regulations
are all going to have different requirements.
The management of all this goes alongside business risk
management into overall risk management.
Some risk management has to do with mergers, acquisitions,
hiring, firing, a lot of different parts of the business
that aren't at all technology, IT, or cyber.
Including cyber in there will help the organization
as a whole.
And you need to understand your recommendations go
into that overall risk management concept.
Even if it's a small organization,
they don't have a foundation or a framework
for risk management, they're going
to be doing it at some level.
They're going to be sitting down and deciding
where are we going to spend our money
and how are we going to use it.
And if it's not formalized, it's still happening.
And your recommendations for cybersecurity
are going to get included in that.
And they might get prioritized lower
than what you think they should as
a cybersecurity practitioner.
So this is, of course, about pen testing.
So you might be wondering, when are we going to get to that?
And risk management includes vulnerability management,
which is what we're covering here,
and vulnerability assessment, in order
to manage your vulnerability.
So you need to know what they are.
With that, there's vulnerability scanning and pen testing
for gap analysis.
Because often, there might be a level that you know.
You might know what software you have.
You might know that it's vulnerable.
And you might assess the risk that it is behind the network
boundary, internal only, and the impact of it
is low enough that it's not worth spending
the time or the money to update it.
And that's up to the organization to decide.
You can make your recommendations.
But I know what recommendations you would make
because I would make the same.
Let's mitigate as much as possible.
But as a pen tester, running vulnerability assessments,
doing that gap analysis, it's all
going to be part of this chain.
So how do we find these vulnerabilities?
We've done foot printing and scanning in this pathway.
We've done some service enumeration in this pathway.
That's all going to be part of it.
Asset identification and research--
OK, hey, there's this service running.
It's this version on this operating system.
We need to go and see, what does that mean?
And we'll get into that in the lab.
But there's places like Exploit-DB
and the on-hardware version SearchSploit maintained
by offensive security, and it's a great asset
for the community.
Or there's fuzz testing.
You might get access to something
and not be able to find any vulnerabilities that
are out there in the wild, that are known.
So perhaps you need to just try some things
and see if there's a vulnerability there.
Input and handling validation is important.
And that's, again, how pen testers find a lot of things.
You try putting in passwords that don't
look like normal passwords.
You try usernames that don't look
like usernames because maybe there's
a chance for SQL injection.
Those are things that we'll get into in other parts
of this pathway in other courses.
But that's generally how we find vulnerabilities.
In the next video, we're going to take
a look at some well-known CVEs.
We'll look at why they matter and what we can take from them
now today.
Even though a couple of them are bit older,
one's fairly new and relevant.
And I think we'll learn a lot.