hello and welcome to another penetration test in execution. Standard discussion. Today we're going to talk about denial of service testing and the role it plays in the pre engagement interactions area of the Pee test standard. So with that, let's jump into our disclaimer.
So the pee test videos do cover tools that could be used for system hacking.
Any tools discussed or use during any demonstrations should be researched and understood by the user.
Please research your laws and regulations regarding the use of such tools or text techniques in your given area. While we wanna have fun and learn, we also want to ensure that we're safe and don't break any malls in the process. So let's jump into our objectives. So today we're going to discuss it. Ah, high level.
What denial of service is we're going to discuss when it is appropriate. So when it's okay to do denial of service testing or maybe recommend it, we're gonna discuss a few tools just, ah, high level list. And then we're going to take into account some legal considerations
with respect to denial of service testing.
what is a denial of service or D O s testing not to be confused with DOS. So the Nile of service is when the attacker works to make a machine or resource is
unavailable. Loren viable either temporarily or indefinitely. So these types of attacks can be categorized into distributed denial of service volume based such as UDP, fled Czar, other spooked packet floods, protocol attacks such as Ping of death and things of that nature
and then application layer type attacks
where it is get in post type floods or Apache specific attacks
I've even seen in cases where there are vulnerabilities that were found on systems that if a service were manipulated or something was executed in a certain way, it would cause a denial of service scenario on that system.
And so denial of service is just not a one for one. Or it's not just me pinging a system and, you know in excess or, you know, trying to max out the pipe on a network. Those air some cases where the denial of service is definitely a type of attack or that could be a method.
But it's much more complex and has a lot of other ways in which it can be met, or the term of that attack in the methodology for doing denial of service can be met.
Now, denial of service attacks are not always appropriate on. The reason for that is, is you've got to take into consideration client expectations
when you think about doing a denial of service attack and even more so than maybe social engineering. While we want to get permission to do any type of attack. We want to be explicit
in developed service, attack testing or system stress testing. And we want to ensure that the client
fully understands the implications of denial of service testing and what could happen.
And so it's appropriate when the client may seek to test the system's recover ability if they want to understand how well load balancing will offset the attack and keep them up and running,
and potentially if they want to validate
denial of service testing. Um, it may not be appropriate if the client is only concerned on confidentiality or integrity of data, so meaning they want to ensure that information that his secret is kept secret and that information is not altered as faras, it's ST
if the client is not too concerned about the availability of information in that they could be down for a period of time and that's okay, or they really don't want to test the, uh, you know, do stress testing of systems. Then you know that may not be inappropriate,
um, type of test to conduct. And then if they have no tolerance for downtime, you definitely don't want to conduct knowledge service testing. I can tell you that if you were to do an exploit, that when an act and denial of service type scenario where a system would then crash,
um, or be put off line, or it would impact the capability of their customers to get to data or for them to conduct business. If you're doing this type of testing without the client being aware that it could happen, that could put you in a lot of trouble. And, uh, we'll talk about at least circumstances for us based testers
here in a moment. Now again, denial of service testing can also be known a stress testing, and there are plenty of tools out there that we can use for denial of service testing.
And so these tools are really based on the particular need and type of system being tested. And so just a few examples here are like the low orbit ion cannon,
which will attempt to overwhelm the system you've got. The HC pig funk load lacks flood and bite Flood river hold. Each of these
is dependent upon the type of testing summer for Web application Summer You know, attacks on protocols. Some are just an attempt to overwhelm or flood. The system with requests
in the type of request will depend on the type of tool. So it is important
prior to running tools that you understand what you're doing and, you know, kind of go from there. I heard of a particular story. It's been years
since, um, I actually went back and referenced it. But there was a guy who and his teams ran into the low orbit ion cannon. And there was an organization
in which, you know, aboard a message board had indicated, Hey, you know, download this tool running against this organization. Help us in our cause, Yana Yana. Well, this guy goes out and kind of from his mom's computer downloads. The tool runs it
for maybe an hour. He doesn't think anything else of it.
He turns the tool offi goes about his business.
The next thing he knows, the FBI's at his door. He's been charged with felonies and long story short, he ends up in a position where he can't be around computers for a period of time and has a criminal record.
He explained that it was harmless in his mind that he was just kind of, you know, going with the flow with was on the message boards and with the groups of people that he was, you know, hanging out with.
I didn't think anything of it. But again, Amy type of perceived attempt to interrupt the system
or to do harm to a system is considered a felony in the United States. And so the legal consideration for this and the law surrounding this
is the given code here, and it comes down to the terms and conditions where the offense is. Any revenue loss, costs incurred or other consequences will damage incurred because of the interruption of service. We have looked at a previous case where a gentleman
was doing port scanning in looking at a county system
any performance degradation, anything even if it's minute, even if it's a kilobyte of difference in the ability of data to be downloaded or access could be perceived under the law is an attempt to cause issues, damage, interrupt or otherwise degrade
the capability of that service.
And so the reason we need explicit, well defined well, it out permissions for doing these types of tests is because if for any reason,
that service is thought to have been interrupted, damaged or that system damaged by our testing and we did not thoroughly document those permissions, we did not thoroughly document what it was that we would be doing.
We run a very high risk of legal action being taken against us, especially if the client were to become, for some reason, disgruntled and then chose to take action because we cost them money time clientele, whatever the case may be. And so
you have to take those things into consideration before you do any type of stress testing or denial of service testing.
let's do a quick check on learning.
So true or false denial of service testing should be conducted in any penetration test
and is best done without
the client's awareness so you can measure their response to the attack.
True or false?
Well, we just got done talking about legislation in the United States and how that looks. And so the answer here is false. We do not want to conduct any
denial of service testing
that does not involve client consent and transparency and full awareness. In addition,
denial of service testing is not always applicable in any penetration testing scenario. We discuss that if a client is more concerned with confidentiality and integrity of data sets, and they're not so much worried about availability or they
cannot have any downtown whatsoever and it could, you know, cause issues for them. If that were to occur,
then it is not always applicable or best done in the penetration test.
So with that, let's go ahead and wrap everything up. So we discussed what denial of service testing is. We talked about some different ways that develops service. Testing could be done as faras against protocols or applications or, you know, just brute, forcing a system essentially to try and overwhelm it.
We discussed when that testing was appropriate as well as when it was not. We looked at some tools at a high level a list essentially of denial of service tools that could be used for stress testing. If you are familiar with Kelly Lennox, those would be on the tools dot callie that orc site as stress testing, not denial of service.
And then we discussed some legal considerations looking at United States statutes with regard
to denial of service testing. Now
a rule of thumb for me and this is just opinion and summary. Here is I generally would not offer denial of service type testing because my opinion is is that if the client is not interested in it,
we can almost always find a way in a means to overwhelm the system. And so, unless it's for a specific reason, they're trying to test a scenario out there trying to test an application and trying to test something, and they want that done. I would almost approach stress testing separate from penetration testing so that the engagement is well defined, laid out
understood, and the client has a specific mean.
But if you choose to include that as a part of your penetration, testing engagement always take the time to be very thorough and how you lay that out and that everyone understands the risk involved.
So with that in mind, I want to thank you for your time today, and I look forward to seeing you again soon.