Technology Vulnerabilities Part 2

Video Activity
Join over 3 million cybersecurity professionals advancing their career
Sign up with
Required fields are marked with an *
or

Already have an account? Sign In »

Time
4 hours 25 minutes
Difficulty
Intermediate
CEU/CPE
4
Video Transcription
00:04
>> The next type of vulnerability we're going to talk
00:04
about is a configuration vulnerability.
00:04
Before when we talked about
00:04
software vulnerability we were talking
00:04
about an actual flaw in the coding of the software.
00:04
In the case of configuration vulnerabilities we're
00:04
not talking about flaws in the coding itself,
00:04
but we're talking about flaws in the way that
00:04
the hardware or software is configured or deployed.
00:04
There's no bug in the actual code,
00:04
but the way we implemented it is not the most secure way.
00:04
Some common examples of
00:04
this are things like lack of encryption.
00:04
Maybe we created a website
00:04
we forgot to turn on encryption on the website.
00:04
It's not a flaw in the code. It's just
00:04
we forgot to turn on encryption.
00:04
Excessive access, maybe we
00:04
didn't lock it down properly,
00:04
or maybe we disabled logging,
00:04
and the security team can't really see
00:04
when there's any attacks against the system.
00:04
Mitigation for configuration vulnerabilities.
00:04
Just like you can scan for vulnerabilities,
00:04
those same scanning technologies
00:04
usually have configuration scanning built into them.
00:04
In this case, we're talking about CIS scanning.
00:04
CIS stands for center for Internet security.
00:04
What CIS does is they maintain a list of
00:04
best practices in regards to
00:04
how different software is configured,
00:04
how different applications are configured.
00:04
When you scan your environment for vulnerabilities,
00:04
you can also come back with a CIS score that tells you,
00:04
hey, this encryption is disabled
00:04
or this isn't password protected or whatever it is.
00:04
It'll give you the same types of things.
00:04
Regular scanning is just like
00:04
the software vulnerabilities will
00:04
help identify configuration vulnerabilities.
00:04
Standard images is another good one.
00:04
We have a session later in the course on this.
00:04
But when you're talking about standard images or
00:04
golden images we're just talking about,
00:04
if you deploy Windows
00:04
10 to 5,000 systems in your organization,
00:04
instead of going through
00:04
the entire installation process from
00:04
scratch and having
00:04
a custom installation every time you do it,
00:04
standard images just give us
00:04
a way to create a base image.
00:04
Then we know this base image is hardened,
00:04
it has all the right security features in place,
00:04
and then we can use that image to
00:04
deploy and to distribute
00:04
across the environment instead of trying to
00:04
rebuild it every time where we may make mistakes.
00:04
It's also critical in
00:04
configuration vulnerability mitigation to
00:04
have a go-live or a go-dead process.
00:04
As new systems come into the environment you should have
00:04
a process in place that has checkboxes that say yes,
00:04
the system is hardened.
00:04
I've done all of the right things.
00:04
There should be a go or no go decision
00:04
that says yes, everything is checked,
00:04
go ahead and put it in production and
00:04
then the system gets added to the environment.
00:04
Same thing when the system
00:04
gets removed from the environment.
00:04
I've seen a lot of times,
00:04
especially in the virtual environment where you've
00:04
got a system that you're trying to decommission,
00:04
and you take it off the network,
00:04
you shut it down but because it's still out there,
00:04
it's a virtual system,
00:04
there's a snapshot of it still out there
00:04
a lot of times that thing will just pop back up
00:04
because someone did not follow
00:04
through of deleting that snapshot or
00:04
archiving it or moving it to a place
00:04
that it couldn't accidentally get turned back on.
00:04
These things will pop back up,
00:04
and you'll have these vulnerable
00:04
systems that you thought you
00:04
got rid of that pop back into the environment.
00:04
We call those zombies sometimes.
00:04
The next type of vulnerability we're going to talk
00:04
about is a hardware vulnerability.
00:04
When we're talking about hardware,
00:04
these are much more complex
00:04
and these are flaws in the way
00:04
the physical electronic components handle data.
00:04
Some examples of this are meltdown, specter,
00:04
and MDS, or otherwise known
00:04
as microarchitectural data sampling.
00:04
Let's take a look at an example.
00:04
Let's take a look at meltdown as an example.
00:04
Before we talk about meltdown we have to talk about
00:04
how normal compute operations works.
00:04
In a normal environment,
00:04
a request comes into the CPU.
00:04
There's a request that comes in,
00:04
the CPU it will go and retrieve the information from RAM.
00:04
So there's an application running,
00:04
maybe there's something that's loaded into active memory.
00:04
So the request comes in,
00:04
the CPU goes and retrieves it from active memory,
00:04
and then it actually stores it in its cache.
00:04
The CPU actually has memory of its own.
00:04
The reason it does this is to speed up processing.
00:04
When a request comes in if there's things that are used
00:04
all the time it'll go grab it out of RAM.
00:04
If it's something that's used all the time
00:04
it'll store it in its local cache on
00:04
the CPU so that the next time a request comes in,
00:04
it can process it and respond much quicker.
00:04
Now this was great and this worked well,
00:04
but as competition got
00:04
more and more fierce to get faster and faster CPUs,
00:04
chipmakers hit a limit.
00:04
There's a limit to the speed of a CPU
00:04
in today's technology and how
00:04
fast it can actually process request.
00:04
Not all, but some chipmakers introduced the concept of
00:04
speculative execution to speed up the CPU even more.
00:04
Essentially, what speculative execution is,
00:04
is a request comes in and now what
00:04
happens is the chip will start to speculate.
00:04
What that means, when a request comes into
00:04
a CPU there's only certain requests that are valid.
00:04
Operating systems can make requests to CPUs,
00:04
but applications can't, directly.
00:04
Applications are supposed to go
00:04
through the operating system to make a request.
00:04
With speculative execution we
00:04
have this request that comes in,
00:04
the chip will start to actually
00:04
processes that request before
00:04
it even knows if it's valid.
00:04
It'll simultaneously start to process
00:04
requests while it starts to see if it's valid.
00:04
The reason for that is that
00:04
whenever it identifies that it's valid,
00:04
it can instantly respond,
00:04
and it doesn't have to then take another step and
00:04
that speeds up the overall execution.
00:04
It won't actually send
00:04
the response back until it knows it's a valid request.
00:04
But what it will do is it'll mark the request
00:04
essentially as ready for delivery.
00:04
Then as soon as the chip
00:04
determines that that was a valid request,
00:04
then it releases it.
00:04
A speculative execution,
00:04
same thing happens,
00:04
request comes in, it speculates.
00:04
It then goes and looks at
00:04
its local cache to see if it has the answer,
00:04
it goes and looks at RAM to see if the answer is there,
00:04
and then it responds to the request.
00:04
Well, meltdown takes advantage
00:04
of that speculative execution.
00:04
What it does is when a request
00:04
comes in meltdown will send a request.
00:04
A malicious application can
00:04
use the meltdown vulnerability.
00:04
The malicious application can send a request to the CPU,
00:04
and it's a small request.
00:04
Let's just say, for example, it says, hey,
00:04
the current user is
00:04
the first letter in the password the letter T?
00:04
Then at the same time the malicious application
00:04
will start a timer.
00:04
Now when the chip starts to speculate,
00:04
remember I said the chip will speculate,
00:04
and then it will mark that request as
00:04
ready to be responded to.
00:04
It won't respond to it,
00:04
but it will mark it as ready to be responded to.
00:04
The malicious code can actually,
00:04
it can't see the response,
00:04
but it can see that it's ready to be responded to.
00:04
That's where this timer comes in.
00:04
The malicious code knows that if the response was marked
00:04
in a certain time it had
00:04
to have been in the local cache on the CPU,
00:04
which means it's true.
00:04
If it took longer for the request to be marked ready,
00:04
it knows that the CPU had to go
00:04
retrieve that information from RAM.
00:04
We're talking about nanoseconds here.
00:04
We're talking about a miniscule amount of time,
00:04
but the malicious code knows that if it's
00:04
a certain amount of time
00:04
then the answer to the question is true.
00:04
Just by timing the amount of time
00:04
speculative execution took to mark
00:04
the request as ready for response,
00:04
the malicious code can now say,
00:04
I know the first letter in the password
00:04
is T. You can see how
00:04
doing this over and over and over again
00:04
can give the malicious code the password.
00:04
That's a rundown of the meltdown exploitation.
00:04
Now what do you need to know about,
00:04
how do you mitigate hardware vulnerabilities?
00:04
Well, first of all,
00:04
you cannot patch hardware.
00:04
We're talking about a vulnerability in the way
00:04
the piece of hardware is actually
00:04
made in the chip itself,
00:04
the way it actually functions.
00:04
You cannot patch the hardware itself.
00:04
You could replace it but if you're replacing
00:04
one manufacturer with another one then you may
00:04
have to replace underlying
00:04
the motherboard and other things,
00:04
and it gets very complicated.
00:04
However, you can patch
00:04
the software that uses that hardware.
00:04
In this case, you can patch
00:04
the bios or the operating system.
00:04
Hardware for a meltdown specifically,
00:04
there's a patch for a bios and for
00:04
Windows operating system that you can apply,
00:04
but it comes with a downfall.
00:04
Remember speculative execution,
00:04
the reason it was actually invented
00:04
was so that the CPU runs faster,
00:04
it can return responses faster.
00:04
By applying this patch you're not
00:04
allowing the chip to do speculative execution,
00:04
thereby hurting your performance.
00:04
You have to weigh the risk versus the reward.
00:04
What's the likelihood that this is going to be
00:04
exploited in the risk if it is
00:04
versus the cost for a slower CPU?
00:04
Now the good news is hardware vulnerabilities,
00:04
the exploitation of them is much
00:04
rare than other types of vulnerabilities.
00:04
So you're not going to see exploits near as much as you
00:04
would software vulnerabilities and other types of things.
00:04
That brings us to the end of
00:04
our technology vulnerabilities section.
00:04
Next up, in Lesson 1.2 we're going to
00:04
talk about process vulnerabilities.
Up Next