>> Vulnerability assessments.
The learning objectives for this lesson are to
define the different vulnerability assessment approaches,
to explore various vulnerability analysis methods,
and to evaluate different types
of vulnerability analysis tools.
Let's get started. When we're
talking about vulnerability analysis,
what we're trying to do is find the bugs or holes,
or vulnerabilities before an attacker does so
this lesson is geared towards showing you
the many different ways that we can do that.
Sometimes it's going to deal with source code,
sometimes it's going to deal with networks,
but they're all trying
to achieve the same goal and that's
finding a vulnerability before an attacker does.
I also want to note that
penetration testing is a subset of this,
where we would engage
either an internal team such as a red team or
a third party company to simulate
an attack on our environment
the way an attacker might do.
Some of the areas of this lesson are
specific to penetration testing,
and when we get to those areas,
I'll let you know that these are
specific to a penetration test.
We're going to get started with a static analysis.
This is when we manually review source code
looking for any errors or bugs,
and we can also use
software to help us automate this process,
but the key is we're looking at the source code
itself and not the application while it's in use.
But a dynamic analysis is when the application is in use.
We will be able to go
through and see if there are any issues with
the program or the system and collect data that way.
A side-channel analysis is when we inspect
a system or the software while it's running,
but we do this by analyzing the data that it produces.
A good example of this would be to use
a sniffer to capture network traffic from
an application so that we can see
what information that app is putting onto the network.
Reverse engineering is when we deconstruct software,
but sometimes hardware to see how it functions.
When malware is being deconstructed
to see what exploits are included with it,
this is a good example of reverse engineering.
We can also do a wireless vulnerability scan.
This is to help us look for
any misconfigurations we might have,
but we can also use it to find our signal coverage.
Oftentimes people think that
the wireless signal stops where
the walls of the building stop, but that's not the case.
We want to find out how far beyond
the building does our wireless signal emanate.
But a wireless vulnerability scan can also
help us to find any areas of
our network that might be vulnerable to
common attacks such as Reaver or Krack.
We can also do a software composition analysis
and this is when we're
inspecting the source code of an app
but we're looking for the open-source components that
we might have included with it
and they themselves may have vulnerabilities.
Oftentimes when you're coding,
you might include third-party libraries.
If those third-party libraries
haven't been properly checked,
they may have their own vulnerabilities
and then when we include those with our app,
we're introducing those into our application.
Fuzzing is a black-box testing method that
it on purpose injects malformed data into an application.
The purpose of this is to
see how the application is going to handle it.
Is it going to reveal sensitive information?
Is it going to cause the application to crash?
We need to find these things out ahead of
time because fuzzing tools
are very common for attackers
to launch against web apps,
and we need to do this ahead of time.
Pivoting is one of those items that's
specific to a penetration test
and this is once an attacker has
exploited one particular system on a network,
they will use that to target others,
but the goal is to move closer to
their own goal inside that network.
For example, maybe a workstation
was compromised because of a phishing attack,
but the end goal for this attacker is
to get to the Active Directory.
So they will pivot to another target that is
closer in the network to that Active Directory server.
Post exploitation and persistence are also
examples of parts of a penetration test.
The post exploitation is when the attacker will
use additional work to ensure that they are
maintaining their access and also
to get additional data or resources on the network.
Whereas persistence is ensuring that they are able
to stay in the environment and remain undetected.
Once an attacker gets in,
they've exploited a particular vulnerability,
and they're on a device.
They want to ensure that they have
another way into the network.
In case that one vulnerability is ever patched,
they want to make sure they have
another way of getting in.
That would be an example of persistence.
Let's talk about some vulnerability analysis tools.
First, we have the protocol analyzer.
This is used to capture network traffic for analysis.
A common example of this is Wireshark or Tcpdump.
A network traffic analyzer
is a little different from a protocol analyzer,
but it's designed to analyze data captured by a sensor.
A good example of this is Zeek.
A port scanner looks for services that are
running on ports on a specific system.
We want to see if port 80 is open,
if port 443 is open,
but we can also scan to see if other ports were left
open that didn't intend
to be left open by the administrator.
A good example of a port scanner is Nmap,
and that's actually what's shown in the screen here.
HTTP interceptor; this will capture the HTTP or HTTPs
traffic between hosts and
the web server to inspect that data.
What we're trying to do is,
can we see any of
that information that maybe normally shouldn't be seen,
and are we able to use that
to help us exploit the server?
A good example of this software would be Burp Suite.
Next we have the SCAP scanner.
This uses SCAP to compare
a scanned device against SCAP baselines.
What we're trying to do is we
have our established SCAP baselines,
and we want to see where our systems
are in comparison to that.
The DoD SCAP scanner is a good example of this.
A vulnerability scanner will scan devices
for a database of known vulnerabilities,
some misconfiguration issues,
and any other numerous issues.
A good example of this is Nessus.
I highly recommend you
download Nessus and play with it because it will
really show you a lot of areas of
your network that maybe you
didn't think about that might need to be addressed.
Then we also have exploit
frameworks and these are a collection of
tools that are designed
for exploiting systems and software.
They have a large number
of exploits already built into them so that we
can exploit vulnerabilities and
the two most common are
Metasploit and PowerShell Empire but
these will both contain many ways to get
into many different types of
systems and different applications.
They also have password crackers.
These are designed to help us crack
passwords from a variety of sources,
and you might have hashes that are
collected from a Active Directory server,
you might have a wireless password hash,
but regardless, all of those need
to be cracked at some point.
>> You can use several methods to do this,
but the two most common would be
a brute force attack or a dictionary attack.
You can also do a combination attack of the two.
But a brute force will try
every possible combination of
whatever you've set it up to do.
It could be all numbers, all letters,
all uppercase letters, or however you set it up.
This is very time-consuming,
and for longer passwords this can
become very difficult and almost impossible to do.
That's why we have dictionary attacks as well.
There are large dictionary files available online of
the most common passwords that have
been captured through breaches.
This is typically the first method that is used.
But again there's another method where you can
even custom tailor the dictionary
to be specific to who you're targeting.
If you have information about them,
such as your parents' name,
children's name, birthdays,
that type of thing, that you
can feed in and then generate
a password list to make it more specific to a person.
But good examples of
password crackers are Hashcat and John the Ripper.
We also use Mimikatz,
which is not itself a password cracker,
but it's a very good tool for
being able to dump hashes from
Windows machines so that we can feed those into Hashcat.
Dependency management is when
we're evaluating the vulnerabilities in
third-party libraries and components
of software and hardware.
Now these items are specific to a penetration test.
When you have a penetration test you have
several components that are
outlining what you can and can't do.
We're going to start off with the scope of work.
What is allowed, what time are you allowed to do it,
and what are off-limits.
Some devices on the network
may be off-limits because if they
were to crash in the penetration test
it would do damage to the network,
and a company can't allow that.
You also want to be able to
know what time of day you're allowed to work.
Sometimes you may not want
those attacks to take place during business hours,
or you might not want them to take
place outside of business hours.
Next we have the rules of engagement.
This defines the manner in which
all of the assessments will occur.
It includes the type of testing that we're going to do.
We also need the contact information
of all parties involved,
and how the penetration testers are going to handle
any sensitive information that they
might come across while performing their test.
Then it also describe
the report formats that are needed once the test is
concluded how these reports need to
be put together so they can be given to management.
Invasive versus non-invasive is
how far a test is allowed to go on systems.
Sometimes you might want to
show that a vulnerability is there,
but you might not want to have the testers exploit it,
because exploiting it could increase the risk that
a device may crash or it
may produce undesirable side effects.
We want to make sure that we have all
of that documented ahead of time,
that everyone knows how far they're allowed to go.
Then lastly we have our assets.
The company would ideally need to provide a list
of the devices that they
want the testers to perform a test.
But sometimes you also allow them to do a blind test
where the testers are
not given any information ahead of time,
so that it more closely
resembles what an attacker in the wild would do.
They don't really know what the inside
of your network looks like,
so if you really want to make sure
that it's as realistic as possible,
oftentimes we do blind tests.
But you want all of that
defined upfront in the document,
so that again, everyone is on the same page on this.
Because the ramifications of
doing something incorrectly,
attacking the wrong system,
taking a system down that is critical, are massive.
We want to make sure that all of that is defined
ahead of time and everyone knows what's going on.
But this also serves as
the typical get out of the jail free card,
where if you were caught
doing something that you have a way of saying,
"Look, I'm supposed to be doing this,
I'm allowed to do this," so that you don't end
up in a federal penitentiary.
We also want to make sure that we
have permissions and access.
Are there any materials that
we're going to need to provide to
the testers so they complete
their assessments such as ID badges?
Are we going to make sure they have
background checks ahead of time?
All of that needs to be documented as well.
We also want to have our facility considerations
taken into account.
Are the assessments going to be done on site?
Are we going to be doing
any physical penetration testing?
Which we'll go into the next item.
But if we're having people on-site to do things,
do they need to be escorted throughout the building?
Are they going to be working from one particular office,
or are we going to allow them more access to do things so
that it more closely
stimulates what an actual attack would look like?
Next we have our physical security considerations.
Are we assessing our physical security
in this particular assessment?
If so we need to make
sure we have that signed get out of jail free card.
It's so important to have this ahead of time,
because when you're physically breaking into a building,
whether you're picking the lock on the back door,
or you're trying to bypass cameras,
or any number of things.
Those things look like
what an actual burglar would be doing,
and a lot of people may misinterpret it.
Security guards may be calling the police.
If you're going to be doing
any physical security considerations
you want to make sure that
that get out of jail free card is really front
and center on this because it's really important.
It's equally important on the network side as well.
But with physical security so many things could go
wrong because people can see what's happening.
Whereas on a network assessment
it's a lot harder for people to
detect and see what's going on as opposed to someone
trying to pick the lock on a backdoor on a dark night.
Then afterwards we want to make sure we have
a consideration in for our rescan for corrections.
After the pen test has been performed,
we want the site to be able to perform a remediation.
After that remediation has been
performed on their network,
we will need to scan it again
to show that those remediations
actually solve the problems that we
identified in that penetration test.
Let's summarize. We went
over vulnerability analysis approaches,
and we also discussed vulnerability analysis methods
and analysis tools.
Then we discussed vulnerability analysis dependencies.
Let's do some example questions.
Question 1, which type of tool is used to capture HTTP
or HTTPS traffic between hosts to inspect or modify it?
An HTTP interceptor. Question 2,
blank describes how an attacker
uses a system that has already
been compromised to access
another within the same organization.
Pivoting. Question 3.
This type of analysis uses
vulnerability scanning while a system is running.
Dynamic analysis. Question 4.
Black box testing method that
purposely inputs malformed data.
Fuzz testing. Hope this lesson
was helpful for you, and I'll see you in the next one.