hello and welcome to another penetration test in execution. Standard discussion Today we're going to be looking at specifying I P ranges and domains within the pre engagement interactions components of the Pee test standard. So before we get started, let's have a quick disclaimer.
Pee. Test videos do cover tools that could be used for system hacking. Any tools discussed or used during the demonstrations
should be researched and understood by the user. Please researcher laws and regulations regarding the use of such tools in your given area. While we want to learn and have fun, we also want to ensure that we protect ourselves from any repercussions that could be brought on by the law.
So let's go ahead and talk about the objectives for today's discussion.
So we're going to discuss what I p ranges are and domains are at a high level. How this information should be formatted, discuss and review. Ah, sample document with respect to, um, you know, getting permission and laying that out a cz faras the ranges and things of that nature and then a review of tools to assist invalidation.
Now keep in mind that our audience here may not all be sock managers or experienced I t. Professionals.
You know, we we may have some business managers and things of that nature that are partaking in this so that they could better understand security testing and things of that nature. And so we're going to touch on what I P ranges are the high level and give a very brief explanation of those. But we're not going to get into very meticulous details on the subject matter.
So let's go ahead
and get into what do do remains an I. P addresses look like. So there are two different types of I P addresses that you want to be aware of i. P v four and I p v six. Now, relevance to that is really that I. P v four still widely used. And what you see here are some examples of those addresses.
Now we talk about
different types of addresses, but primarily which you'd want to be concerned with is internal ranges and external ranges, internal ranges, meaning I P addresses that do not route to the Internet or outside of the network and then external addresses. Public addresses would be addresses that are out on the Internet. It is essentially like
your house has a street address. That street address would be the equivalent of a public I p address on Dhe. Then, if you had, let's say items within your home, those were private items. Those items should not be available publicly said. We're talking about two different things here.
So these ranges given at the top are the primary internal rangers that you'll see
for private networks. Now Class A, B, C, D and E is given below are essentially ranges of the I P addresses. Now
you will notice that the Class A, B and C ranges again do not have all of the private range is listed. So in this case, these particular addresses within the Class A range okay, within this range are what are considered private
addresses or internal addresses.
The same thing goes for the class B range, see range, etcetera. So, as you can see, they do not take up the entire range for each of these areas. So anything outside of those ranges, aside from what we call reserved addresses, would be considered public I p addresses, meaning
the address is that allowed traffic on the Internet to get to your business.
Whatever the case may be, There now we did add in the address is here at the bottom, which were considered
reserved as well. And these air typically not used outside of the given cases here. So if you don't know what multi casting is, don't worry about that. Essentially, these rangers would not be used for your business is for us an I. P you would give to a tester or something of that nature.
And so this is the standard format foreign I p addresses that you have four octet. It's so that means that there will be four
sets of numbers ranging from zero,
2 255 in each of those four. So that is what would make up an I P V for address. Now
let's go ahead and move to our next line and kind of continued the discussion. So then we have what are called I p V six addresses. Now,
for those of you that have been working in I t for some time and you've gone to school and done things of that nature, you may have had your professors at the time tell you that I pee before is going away and I p v six is the future and, you know, you better start learning it. Well, for me, that was almost a decade ago, and we're still using I pee before, but
as of this year 2019 we're finding that over 10% of the spaces now utilizing I P V six addresses exclusively. So it is coming for business owners.
Essentially, what you want to pay attention to is anything that is this long string of numbers and letters that is likely an I. P v six address. Now, in some cases, you can shorten or take out repeat characters in order to reduce the size of this.
But it is essentially made up of 108 28 bits
as opposed to 32 bits. Now, the reason that we're looking at this and need to understand this is that while it may not be as prevalent today as we continue to move towards 2020 2030 2040
on, then my retirement hopefully in 2050
we will start to see I p v six be more commonly utilized. And so we need to you know, remember how to recognize properly test and document these address ranges in our penetration testing efforts.
Now the other side of this that is very important to remember, is that if you're going to do any testing on a domain, you have to remember that sub domains may not be the ownership or under the ownership of the business. And so this could be something like store dot or mail dot or something of that nature that may redirect to 1/3 party.
So when we talk about domains and identifying what domains within scope,
we always want to consider that stub domains may not be going to servers or systems that belong to the client. So in those cases we want to be extremely careful and ensure if we're doing testing against u. R l's if we're doing any type of spider ring against the domain, the primary domain
that we understand whether or not sub domains are within scope.
when we go to document this information, there are some key things that we want to remember the format.
All right, we want to include the sub net mask
for the I P addresses. That will be tested, all right, regardless of whether those air, external or internal. And the reason for that is is that if the client gives us a slash 24 internal range
and we know that that particular range goes from 1 to 2 54 okay, and this is more for my I t folks in the business owners if they give us this range, and we know that this is it.
But this range also happens to be owned by two parties. Let's say that there's a mixed environment. They share that address space with 1/3 party, another business. Whatever the case may be, then we need to figure out of this range. What do we need to admit? What do we need to leave out? What should we not test? Or
we get permission from the other party to do testing as well? And that would be between the business owner and that third party as well as faras negotiations. And who's doing what? Who's paying for what
domains should include any sub domains is what we were discussing, so subbed in Maine should be included in some cases. Again, they may only own they be in the client of the business the primary domain. But a sudden domain may redirect with third party. So I've seen plenty of times where we look at mel dot
and that goes to something like Office 365 Well, the client may
own the mail, the mail, maybe the mail for their organization. But they don't own the equipment, the software, the service's that are providing them with that male. And so they're very specific directions and permissions that you have to get taken care of before you can do testing against that domain.
Otherwise, you could be in violation of some statutes or the law.
Same thing goes for user dot This is just a example. This could be stored dot block dot Whatever the case may be,
that may not belong to the business. And so we need to validate whether or not those servers or systems are actually hosted on prim and typically the business owners will be able to tell you. Yes, we have a service from 1/3 party that takes care of payment. They host that in X y C location.
You can start to, you know, ascertain whether or not that that is a non print application, or whether or not they own that.
Now the same thing goes for additional pages off of the primary domain. So there may be a limited scope. And where the client on Lee wants you to test certain domains. I'm sorry, certain pages within their domain. And in that case, you need to specify those so that if you plan to use a tool
that does some dynamic testing, you may want to. It omits Spider Ring. You may not want it to crawl the domain because that at that point you could be in violation of the limitations and restrictions put on the testing.
So all of these things thesis UB, that mask the I p ranges, the domains and sub domains need to be taken into consideration when we're looking at conducting any type of test in the way that it's formatted specificity here. Exactness
is key. If we leave anything open to interpretation, that could be detrimental to us in our organization.
Now, let's look at a quick sample document. So this is compliments of a wasp on dhe. They've got this language on their site,
something that I wanted to break down here, too, is that it's very similar to the other document that we looked at previously and that we identify the customer
and we identify the employees of company. Okay, so the employees to conduct verification activities of the applications and systems described below. So this is the thing that I like about this permission form is that we need to specify and they even go as far as to say, unambiguous, alright application and system names
and a brief description.
This is great because by the time you finish with this document, there should be no questions or concerns with regard to what items air within the scope of the test. And so that goes back to providing explicit external I. P address range is explicit
internal address ranges, explicit domain names and some domains, as well as maybe pages within the domain that should be tested. Now, the thing that you want to remember is if a client provides you with a primary domain and says it is wide open, test it anyway. You like
you should use a tool, which I'll show you some tools to tools here in a moment. But you should look at whether or not. There are potentially any sub domains attached to that domain because the client may not have the breadth of knowledge required to properly explain the scenarios. You have a responsibility as the tester.
Even once this information is provided
to do Cem Cem, due diligence and validate the information again. You're the one that's responsible for doing this. The client will hopefully do their best to provide accurate information. But you should be the one validating the data.
And then again, the last part of this that's always great is Theo effective dates the specific dates in which the authorization is provided.
And then there would be some additional language in this where you can insert permissions in or restrictions as appropriate. So in this case, we may define information here at the top level. But then below, we may say, you know what? I need you to exclude
the following i p. I need you to exclude the given domain or see no page within the domain.
So you could take this document and really be as detailed as possible to ensure that you're properly protected and that you don't do anything that would be out of scope. Don't be laxed in this particular area, or you'll end up being a use case for one of our later discussions to be careful with that stuff.
Now let's talk about two tools that we can use for some validation purpose. And again, the goal with validation here is not to do active testing. We do want to be careful that we don't use any D. N s tools. It would brute force. Some domains do things of that nature, because when we get into active testing,
we run the risk of getting into trouble or having some issues. So one of the tools that I like to use you can use any who is tool. But essentially, this is from domaine tools dot com, and what you conduce you
is if a client provides a domain, you could enter Cem, Cem domain, the domain name, and then what? That conduce. It can provide you some potential I pr arranges associated with that. It can provide you with domain information ownership, address things of that nature, so that can kind of give you some some additional details on
you know what I P addresses associated with that domain
as well as who owns it and whether or not it may be hosted by 1/3 party. If there's issues, they're one of my personal favorite tools is D. N s Dumpster,
which is a sight
where you can input a domain name and it maps that domain name to a T M X Indian s records.
And so the great thing about this is
that if the client says, Hey, I've got a mail server and here's the address and here's you know, my domain name. And here's the I P addresses and all of my software's hosted on premise and things of that nature. And there's absolutely nothing that is that is, off site that belongs to another party, et cetera. Well, you can take a domain name,
put it in the site, and then it will attempt to map a M, x and D. N s records back to that domain. And so the great thing about this is, is if it maps that MX record
and it doesn't come off of the I p address that they provided In fact, it goes to what looks like a night P address that they didn't provide by 1/3 party.
You could cross reference that I p address with something like the office. 365 public I p addresses Whatever the case may be and do some further validation. There are many times where I've been given public I p addresses in domain names, you know, by the organization,
and I've gone back and looked and found that there were some addresses that were excluded. But we're still associated with the primary location, and that led to additional questions are Waters were being excluded and things of that nature, and we found that, you know, they just want aware that those addresses were a part of their their, uh,
particular range. And so this is a great way to really start not so much doing again active reconnaissance, but validating that.
You can also use any any Google tool that would give you the eye. The current public I P address you can look in the far wall. That would definitely be great if you could get some validation there and have them provide firewall information about public. I P ranges that around and through the device
many different ways that you can do that again, though We want to avoid active reconnaissance in map scanning doing things of that nature in these instances because that could be considered active testing, which may be a violation of statutes if you don't have permission, So always be careful
in those cases.
So with that in mind, let's do a quick check on learning.
So which of the following is not a valid I p address?
So please take a moment to pause the video if need be
of these things
which I p or which example is not a valid I p address.
Well, let's talk about the ones that are valid. So a is a part of a private address range and it is valid d is a valid I P V six address be is the Google D. N s address and is a is a valid public. I P address, see is not
a valid address. The reason being is remember, this is what we call an I P V for address. And so in those cases there are four octet ce and so if we count the numbers here, we will see that we're missing an octet. So
in that particular case that is not a valid I p address,
so let's go ahead and wrap this up with our summary.
So in summary, we discussed what I, P ranges and domains are at a high level again, keeping in mind that this is also content for business owners. And we don't want to make any assumptions about knowledge levels with respect to what those addresses ranges or domain names are and how they're formatted. And so we looked at four man and as well,
we discussed in reviewed an additional high level document as faras how we could form at our permission memo and how we should lay out the information to ensure that there is no room for interpretation when we're looking at those documents.
And then we were reviewed tools to assist in validation. So again, all of this is important with respect to ensuring that our scope is well defined and ensuring that we get appropriate information from our questionnaires to ensure that we get the appropriate information into our contracts.
All of the previous discussions build on these concepts.
We also looked at tools again. Keep in mind the two tools that we looked at our at passive in nature and that you're not directly squaring the information from your systems you're not doing in maps canned. You're not brute forcing D N s. You're not doing things of that nature
when you cross that line and you do that type of validation prior to getting permission, you run the risk of legal ramifications or issues.
So with that in mind, I want to thank you for your time today, and I look forward to seeing you again soon.