Validation

00:00

Hello and welcome to another penetration testing, execution Standard discussion. Today we're going to be looking at validation within the vulnerability analysis section of the Pee test standard. So it's a quick

00:13

disclaimer, and he tells her techniques that we discuss or used during the pee test. Videos could be used for hacking, and they should be researched and understood by the user.

00:22

Please ensure that you understand applicable laws and regulations for your given areas so that you don't break any of those holes of regulations and end up in hot water. Now

00:33

the objectives of today's discussion are to discuss what validation is to look a correlation between tools, manual testing and protocol specific information and then discuss some attack avenues. And so how we go about validating that, looking at that information and ensuring that we can

00:52

step through to proper exploitation.

00:55

So

00:56

with respect to validation, the active validation is when the tester takes the information from a vulnerability scan

01:03

tool and test the target system to validate the information provided is correct. So this is a way to weed out false positives and ensure you focus on valid vulnerabilities. You don't wanna waste time effort and energy, chasing a false positive

01:19

and testing systems and really not providing any risk reduction or meaningful information out of the tests of being able to identify those false positives. That front

01:30

prior to

01:33

giving that information to the client can save you some time and face

01:37

now. Correlation between tools. So when working with multiple tools, the need for correlation of findings can be somewhat complicated, so correlation could be broken down into this two distinct styles. Specific and categorical quarter relation of items. Both are useful

01:53

based on the type of information, metrics and statistics you're trying to gather on. The given target

01:57

says specific correlation relates to a specific define herbal issues such as vulnerability i D C v E O S v b d B. Vendor. Indexing numbers known issues with software etcetera and can be grouped with micro factors such as host name I P. Fully qualified domain name, Mac address, et cetera.

02:16

An example of this would be grouping the findings for host X by CV number, as they would index the same issue into multiple tools. And so I've seen this before, where one tool will take an SSL vulnerability and break it out in 2 30

02:35

independent and separate vulnerabilities for the one system,

02:38

or it will group everything by one C V E. That has a sub

02:43

vulnerabilities within it. So, really, in this case, you're going to take the two tools.

02:49

You'll do a bone scan with one. You'll get results for one host

02:53

that same host, and the other tool may have the same vulnerabilities. But the way the tool categorizes those may be different. And so you'll have to dovetail but both of those together and make sure that they fit nicely and that there's not anything that one tool found that the other tool did not.

03:10

Now, manual testing and protocol specific testing. This is just some examples for, like Web and male testing, so Web service is providing large landscape Attackers. Unlike most other protocols, Web service is air often found running on multiple ports of a single system.

03:28

Administrators may focus their Harding on common ports for Web service, is or published directories and neglected properly Hardin additional attributes

03:37

so Web service is should always be reviewed in a manual. Fashion as an automated assessment tool may not be capable of identifying most weaknesses in their service is so it may provide you with some foundational information, and it may get you started. Like it may ballade that a service is vulnerable to cross site scripting. It may validate

03:54

that it's vulnerable to SQL injection,

03:58

but you may have to do some manual testing to further validate that. And, you know, show that that that server is, in fact week against attacks. Mail servers can provide an abundance of information about target organizations as well, so using inherent in functions in the target device,

04:15

confirmation of valid accounts could be conducted as well Is developing a list of potential user names

04:20

for additional attacks on other systems? Vulnerabilities such as male relay can be leveraged for additional attacks on the organization for like fishing.

04:29

Often, mail servers will provide a Web interface for remote access that can be targeted and brute force campaigns where allowed in the scope of of work and in the rules of engagement.

04:40

So if you get valid, email address is often times you know they'll use first initial last name. Our first name last initial. A lot of times organizations mimic user names with that, so that could give you a pretty easy user list. There are at least some Valenti's your names that you can use

04:59

now attack avenues. Creation of attack trees. So during security assessment, it is crucial thio

05:08

the accuracy of the final report to development Attack Tree As testing progresses throughout the engagement, so his new system, service's and potential vulnerabilities are identified, and attack tree should be developed and updated regularly. This is important during the exploitation phase of the engagement, as

05:25

one point of entry that materializes could be repeated across other vectors and mapped out

05:30

during the development of the attack tree. So that's going to be important for your documentation and ensuring that you fully understand the attack avenues within the organization.

05:41

Now you can also do at isolated lab testing, And so the accuracy of vulnerability announces an exploitation is substantially greater when replicated environments are set up in an isolated lamp. So if you can replicate

05:54

the scenario, the service is the version of the application down to maybe some open source code that the clients using

06:01

then that could help you with your testing efforts. And so systems may be hard and with specific control sets or additional protection mechanism. So by designing a lab that mimics that's target organization, the consultant can ensure that the vulnerabilities identified

06:15

and exploits attempted against the desired target of reliable and less than the opportunity for inaccurate results or system

06:21

and operability. So it would be a horrible thing

06:26

to attempt an exploit against the system, and you crash or damage that client system. So if you can set up a lab environment to validate that information, it would be beneficial, and it would reduce the risk of client issues. And remember, we always want to protect our clients with respect to their systems, especially if they are critical

06:44

in nature and then visual confirmation. A manual connection with review While proper

06:48

correlation can help reduce false positive findings and increase overall accuracy, there is no substitute for visually inspecting a target system. No substitute for visually inspecting the target system. So assessment tools are designed to review the results of a protocol or service connection.

07:04

Um, and compare that to known signatures. However, tools are not always accurate with respect to

07:11

uncommon ports or accurate identification of service is or custom logic that may be built into an application so by manually looking at these systems and service is available,

07:21

and the applications that provide functionality for the service is weak and then ensure proper validation on vulnerability. Identification has been completed, and so we can do a lot of things with Google. Exploit d B other exploit databases That vulnerability system that's just going off of signature based checks

07:41

may not be able to do.

07:43

And so it's to our benefit to take the extra time to visually confirm information. Do samen map scans do some banner grabbing?

07:50

Do some additional research on Google and just make sure that we've covered all of our bases when we're doing our vulnerability analysis. Now, let's do a quick check on learning

08:03

true or false

08:05

vulnerability. Scanning tools are always accurate and rarely require additional validation,

08:13

so this shouldn't take you too long to figure out. But if you do need some additional time, please to pause the video to consider

08:20

so vulnerability. Skinning tools are not always accurate, and they usually require additional validation. So this is most definitely ah, false statement. If you are doing a heavy, heavy, heavy security engagement and the client is

08:39

perhaps engaging you for up to three months of time to do some testing and you just go off of automated test results. You are definitely hurting your chances of, um, potentially exploiting the system.

08:52

And you're definitely hurting the value that you bring to a client with respect to risk awareness, thread awareness

09:01

and the reduction of risk over. Also,

09:03

make sure that you do your due diligence and use multiple methods for validating vulnerabilities within systems. So

09:11

in summary, we discussed what validation is. So that's the act of going through and confirming that you don't have false positives from a scan. We let the correlation between tools we discuss manual testing and we discussed avenues with respect to attack avenues, mapping those keeping track of those testing

09:31

and validating everything and ensuring that it is in fact, a valid

09:35

avenue for further exploitation when we get to that phase.