13 hours 9 minutes
Hello and welcome to another penetration testing execution Standard discussion. Today we're going to be looking at research within the vulnerability analysis section of the Pee test standard.
Now is a quick disclaimer. Please remember that pee test videos do cover system hacking techniques and tools. And so any tools or techniques discussed or used
should be researched and understood by the user. Please researcher laws and regulations regarding the use of such tools in your given area to ensure that you do not violate the long
Now, let's jump into our objectives.
We're going to discuss public research.
We're going to look at exploit databases and framework modules is a form of research
hardening gods and their benefits. Private research, identifying potential avenues in vectors for attack and disassembly and code analysis. And again, we're looking at high level standard information from the Pee test US
execution standards of the PIN test execution standards. And so we're not going to get in detail on how to do private research and public research and per se give you a procedure step by step checklist to do each of these things.
This is kind of some thinking information that you can then take an apply where applicable, so
public research can include vulnerability databases. Vulnerability databases can be used to verify an issue reported by an automated tool. Or, if you're doing manual review, you can go and potentially find those informations as well. In the database. C V E identifiers are commonly used in given the vulnerabilities
and can be used to access summary information or other resource is in the database. You can also use him to search for and through databases in L S V D B Bug track exploit databases and frameworks, typically allowing you to use C V E's as well. So I know that the Medicis played framework as well as, um
export D B will let you search for a particular CV,
and then you can see an exploit code is associated with that
now. Vendor advisories air another component of this so vendor issued security advisories and change logs can provide pointers to vulnerability information that may not be reported by a tool.
When Microsoft releases patches and they talk about what bugs they fixed,
that could be an indicator of a vulnerability that was addressed that may still be present if the system's not updated.
Many software vendors also report details on internally discovered issues where an independent researcher coordinates the disclosure.
However, if a researcher chooses to remain silent on the details of a vulnerability than the vendor, advisory is frequently the only data that is available in these cases. Other researchers may discover more details and add them. Thio databases
searching for Stevie, used in a bender advisory, may turn up more details on potentially exploitable issue, so vendor advisories are a great way to do that. So if there's
a particular software or some version of the software or ah, device, it's being used,
you may be able to look at vendor advisories and find further details and information.
exploit databases and framework modules are great as well. So many databases are actively maintained and publicly accessible on the Internet. Security researchers and exploit writers don't always submit their code to multiple sites,
and so you need to become familiar with and check several sites for exploit code for potential vulnerable applications.
While some vulnerability databases track exploit availability, their coverage is usually incomplete and should not be considered exhaustive. So just a few examples of how this looks so you can use sites like exploit D B. Okay, you've got von D B or vole, D B, C X Security and CV details.
You can search for CV information, exploit information, and these sites contain codes and proof of concept
techniques for exploiting systems, so these could be invaluable in your penetration testing efforts When you get into the exploitation phase.
Now, folks may not think
that hardening God's, um, are, you know, a good source for vulnerabilities,
but we're trying to act like an actual attacker. And so, while automated scanning can reduce the window for testing as far as the amount of time we take,
no scandal acts like a human right and so heartening Gods can be invaluable references for testers because not only do they highlight the weakest parts of the system, but you can get a sense of how the administrators doing
in their role for reducing risk for the organization. And so if there's some best practices in the hardening got none of those were applied in the environment.
The administrator may not be doing the best of war to reduce risk Now.
There may also be some information in the hardening God. That may not be common knowledge that the administrator may not have.
And from that standpoint, you could then use that to see if the system is exploitable from that point.
Now, private research areas are where we get into doing things like setting up a replica environments, and so we can use virtualization technology to essentially mimic and quickly deploy ah, system that we see in the target environment. And then we could use that Veum to explore configuration parameters, behaviors of applications
without directly connecting to the system. So this is good if we're trying to act like an attacker and that we want to avoid detection.
But it also helps us to reduce risk to the climb environment and ensure that our tests don't cause any damage or downtime to their infrastructure.
Now we can also test configurations based on different images, and so for us as testers, we want to start to build a repositories of different operating systems and things that nature so that we can load up a certain service packed level. This will help us to streamline the recreation process of the environment,
VM library, library and combination of beings within the environment that support cloning to allow you to, you know, bring stuff up quickly
is going to be beneficial and helping you tomb or efficiently reproduce bugs and information.
Now this is all dependent on the scope and scale again of the environment, what the clients hoping to achieve and what your capabilities are as far as an organization. Now, over time,
you should look to, you know, a mass images and things of that nature to help you in your testing efforts, so that again
you can give the client the best return on their investment, as well as potentially exploit a system
now identifying potential avenues in vectors. So log in or connect to, ah Target network application to identify commands and other areas of input. So if you can get into a system, you can start to look through the network. If the target is a desktop application that Reid's files and our Web pages
aniline is the accepted file formats for avenues and data input.
Some simple tests involve submitting invalid characters are verifying long strings of characters cause crashes and things of that nature, and you can also attach the bugger and analyze program states in the event of a successful crash. Now
this is getting into attack vectors like buffer overflow testing to see if those types of attacks against memory would be successful with applications
that may not be to scope. Or you may not have the skill set for that. Remember, you want to do testing, Um,
but you want to do it right, and you want to make sure that you don't do anything that's outside your wheelhouse.
Now we can also look at disassembly and code analysis, disassembly of code and code analysis So some programming languages do allow you to d compile the code and some specific applications air. Consider compound with symbols for debugging,
so a tester can take advantage of these features to analyze program flow and identifying potential vulnerabilities
so source code for open source applications could be analysed for flaws. Have applications written in PHP share many of the same vulnerabilities, and their source code could be examined as part of any test.
So again, depending on the scope and scale, they're different avenues we can take for researching vulnerabilities and figure it out if his client system could be vulnerable
So let's do a quick check on learning.
Hardening gods are a way to determine potential vulnerabilities in the system and the diligence of a system administrator.
So if you need additional time, please take it.
So this statement hardening guides are a way to determine potential vulnerabilities we could look for common. Miss Configurations are things that are left undone, and they're also a way to test the diligence of the administrator. So this is a true statement.
So with that in mind, let's go ahead and step into our summary. So we looked at and discussed what public research wasn't some methods for doing that. We looked at exploit databases and framework modules and how those can help us to identify vulnerabilities on systems with potential exploits available.
We looked at hardening guides and common miss configurations that are essentially listed in those and
how we could see if the administrator is doing their due diligence.
We looked at private research primarily through the setup of virtual environments and the use of those environments to do additional testing. We discussed identifying potential avenues in vectors through code testing, as well as disassembly and code analysis or the disassembly of code and the analysis of code
again. Each of these areas is case by case basis, thes air, just Cem Cem primary areas within P tests that they point out with respect to doing research and how you could go about doing that if you already have a methodology or checklist in place for doing that and continue to follow it. But these are definitely some great starting points.
If you're trying to build your rep, retire for penetration, testing or find a way to develop your processes and procedures for your organization.
So with that in mind, I want to thank you for your time today, and I look forward to seeing you again soon.