How to conduct brute force tests for directory traversal or other operations that require trial and error without accidentally turning it into DOS attack? It comes to how much bandwidth a site is capable of (and other things like memory) and it's different as to every site. How to measure this bandwidth? How to determine, or calculate and set the right speed of test?
1
-
The bottle neck will probably be the server's max requests/second handling, not the bandwidth as path traversal are simple GET requests with no significant data payload. There are many tools to conduct stress tests which will give you a number. Something like Siege might be useful.– Hummus_FulFeb 8, 2021 at 14:15
Add a comment
|
2 Answers
If you write your own tool, than you can do it with with growing mechanism of requesting. For example:
- Start with 100 threads -> All is ok
- Add 50 threads -> 50* errors in 10%
- Add 50 threads -> 50* errors in 40%
- Remove 70 threads and set 130 for current server. Periodically you can retest this phase.
Manually you can do it with wfuzz, patator or ffuf empirically brute number of threads.
If you run an enumeration attack and the server is overloaded, then that is a problem the server administrator needs to fix.
What makes a Resource Exhaustion attack work?
Denial-of-Service is a broad term, so let's focus down on resource exhaustion attacks. In most simple terms, resource exhaustion attacks work by you using up most of the available resources, so that the application becomes de facto unusable by normal users.
Generally, a server is expected to serve a lot of people, and even small servers for small companies should have the capabilities to serve a handful of people at the same time.
Most primitively, a resource exhaustion attack is just a measuring contest of who has more resources available. If you have a 10 Gb/s connection and the server has a 100 Gb/s connection, then you won't be able to fully exhaust the server's bandwidth - at least, for primitive attacks.
More advanced would be "amplification attacks", in which you do only very little work, and you get the server to do a lot of work in return. To make an analogy, saying "I want to buy one burger" is about as difficult for you as saying "I want two hundred burgers", but it causes the restaurant a lot more work.
What about brute forcing?
There are many instances in which you may want to run a brute-force attack. Directory enumeration, user enumeration through username oracles, etc...
In general, these attacks do not aim at using up the server's resources, but instead to get a specific answer from the server. Using resources is merely a side effect - one that may be undesirable.
In the best possible case, the server won't limit your requests, and you can just send requests as fast as you can, and get answers as fast as you can. This is usually the case if no server-side rate limiting is implemented and if the server has proper bandwidth compared to you.
However, should you notice that responses are sluggish and delayed, it is time to reduce the load you put on the server. Every brute force tool worth it's salt - no pun intended - will include some kind of delay or rate limiting switch. Start by introducing a small delay, then ever greater delay, until you feel that the packets come in steadily.
Since most tools also run several threads in parallel, it may be worth trying to reduce the amount of parallelism and decrease the delay, or increase the parallelism and increase the delay. It is a trial-and-error process.