Vulnerability Testing

00:00

Hello and welcome to another penetration. Testing execution. Standard discussion today is our first section, or first discussion on vulnerability testing within the vulnerability analysis section of the Pee test standard. Now a quick disclaimer.

00:17

The Pee test videos do cover tools and techniques that could be used for system hacking.

00:22

Any tools discussed or techniques discussed during any of our demonstrations should be researched and understood by the user. Please research your laws and regulations regarding the use of such tools and techniques in your given area to ensure you don't land yourself in any trouble with the law. Now, today's objectives are pretty straightforward.

00:41

We're going to look at what is vulnerability testing. We're going to discuss examples of flawed types, and we're going to discuss vulnerability testing goals overall within our penetration test.

00:52

Now, what is vulnerability? Testing? Well, vulnerability testing is the process of discovering flaws and systems and applications in which they can be leveraged by an attacker. So although the process used to look for flaws Berries and is highly dependent on the particular component being tested,

01:10

some key principles do apply to the process and so, always remember vulnerability. Testing is about scanning systems reviewing systems looking for indicators

01:19

that that system is vulnerable to an attack. It may be known or unknown, but that is the key component of vulnerability analysis and testing.

01:30

So here's a high level process for you. So the tester should properly scope the testing for the application or applicable systems, and it should meet whatever depth and breadth goals are in mind to get the desired outcomes on kind of rode over that, but that there is desired outcome.

01:49

And so the depth of testing should always be validated to ensure that the results of the assessment meet the expectations of the client.

01:57

This is to what extent should attest to go to find vulnerabilities. So remember,

02:02

you've got some manual methods to do testing, and typically what we do is we start with an automated methods, so we use some form of scanner or tool to give us open ports service versions things of that nature. Some of those tools have capabilities. Database is built in that correlate that information and give us

02:21

whether or not a system could be vulnerable,

02:23

and then we could use manual methods to do some additional testing

02:28

to them. Validate that that vulnerability is there. But a client may not have the budget or time for us to do the zero day approach, which will discuss in later discussions

02:38

what we're trying to find new or unknown vulnerabilities on the system that could be exploited so again, taking into consideration depth and breadth of the particular engagement and whether or not it will meet

02:50

the client's needs. Breath of testing is what Target network segment host applications will be scanned for vulnerabilities. Always consider time and overhead for the given testing methodology. So again, if we're doing network testing

03:04

and we've got 1000 systems in that in that network segment,

03:07

are we scanning all 1000? Are we only scanning critical systems what is and isn't included in there? And what do we want the outcomes to be? If the client is looking more at compliance driven scenarios,

03:20

and it's just to say that they've identified vulnerabilities and they'll re mediate him an automated scanning, maybe all that's required. But if they want to go deeper to see if critical systems could be exploited with either known or unknown exploit types or by finding those vulnerabilities than

03:35

that scope may be much more heady and require a lot of additional labor and work.

03:40

So let's go into some examples of flawed types.

03:45

So sample applications air left on systems being that there may be pre configured applications, and they have known vulnerabilities. This is oftentimes, if you install test applications or if your development team is

03:59

maybe just working on something to try and get a proof of concept, right and they don't take those tests applications off the system, they could have

04:08

known vulnerabilities in them. And so that could be an example of a flaw that could be found. Directory listing is not disabled to being able to see directories and information. Air messages are allowed on systems. And so while this may seem harmless, that could be considered a vulnerability. If the system divulge is additional information that gives

04:27

an attacker contextual information on the version of let's Say, a server database

04:31

server application and that information could then be used to format, maybe a particular exploit. Or maybe it gives us outputs for databases and things that nature in the air message, which then would tell us the database version, which could potentially be used to mount an attack. Different things we can do there.

04:50

Default credentials, air left in place on not just production servers. But I've seen this with network equipment applications. Things of that nature routers, switches.

05:00

I mean, while it doesn't seem

05:02

like it would be considered a vulnerability, it most certainly is. This is a way for an attacker to get into a system. So while there's some human error here and some lack of best practice, that's still a vulnerability to consider.

05:14

Parameter sanitization is not properly implemented, and so that could be used in tandem with a system that produces air messages. And if we get air messages and are able to get the system to return certain parameters instead of just giving us a standard air Paige, you're not giving us any data

05:31

that could be used to the benefit of an attacker.

05:34

Now let's go into vulnerability testing goals, so to properly scope and scan systems that will provide the desired outcome. So that's gold number one to reduce risk by mitigating common attack vectors and known security exposures

05:50

to assist in creating an inventory of devices on the network, those that are known and unknown

05:57

defined the level of risk on the network and establish a business risk benefit analysis. And so

06:03

again, these aren't

06:05

all encompassing. But these air definitely some of the primary goals that we want with vulnerability scanning.

06:12

So we want to scope it to me. Kline expectation. We want to reduce risk by knowing the things that an attacker would know if they're common. Attack meant they're known security exposures, and we confined there's with a tool and address them than that assists us in reducing risk.

06:29

Now the inventory component to me is,

06:32

ah, great part of vulnerabilities, gaining as well because a lot of times what we see as organizations grow and or they could be smaller organizations, we deal with what's called shadow I T. Or where systems were implemented without the knowledge of I t. T i T. Staff or the business owner.

06:48

And so that could introduce vulnerabilities because we don't have accountability of the actual assets that are on the network. So

06:57

by doing vulnerability scans and identifying assets that may be unknown to the team, we can then

07:03

start to address risks that we weren't aware of defining the level of risk on the network. Of course, that comes through a combination of the scan scores that are produced by most systems, as well as the manual scoring and then benefit

07:17

analysis.

07:19

I mean, essentially, if you can, if you can qualitatively or quantitatively give a client a risk score

07:27

that they can then work from then that produces a benefit of the testing.

07:32

So with that in mind, let's do a quick check on learning true or false vulnerability. Scanning does not involve exploitation of identified vulnerabilities.

07:46

All right, so if you need some additional time on this particular question, please pause the video and go from there.

07:50

So vulnerability scanning does not involve exploitation of identified vulnerabilities. This is a true statement now. There may be tools out there that will attempt to take the scans a step further for validation purposes. But the nature of vulnerability scanning is not exploitation of the vulnerability.

08:09

It's to identify

08:11

the vulnerability, validate the vulnerability and overall, provide a risk score or potential impact for that vulnerability. But we should not be going through and exploiting any of the vulnerabilities that are found in this particular face that is a part of the exploitation phase. And if you ever have a client

08:31

that is wanting to do vulnerability, scanning,

08:35

never make the assumption that they understand what that means. I've run into clients before who want to do vulnerability scanning, but they use language that's indicative of penetration testing, and then we discover that they want to do penetration testing. So always ask those questions and confirm that the work that you're doing, the scans that you're doing,

08:52

whether is a part of the penetration test

08:56

or is a part of a separate service will meet the client's expectations. So

09:01

in summary, we discussed what is vulnerability testing. We looked at some example flaws and things that would be considered vulnerabilities on systems. And then we discussed at a high level vulnerability testing goals. Again, the goals are going to be dependent upon your organization's methodologies and means as well as

09:20

the client organization.