ffleming
Question regarding `Got too many possibilities to continue brute force` error.
When attempting to use the --brute-force option, an error will occur after finding an initial input:
$ timing_attack -p -u 'https://example.com/login' --body '{"email":"[email protected]","password":"INPUT"}' --brute-force --number 75
/ 'R'
Got too many possibilities to continue brute force:
RA R8 R* R+
I assume what is happening is that the results of these inputs are too similar to each other that the program cannot determine which to proceed with. Is there a particular combination of options that will reduce the probability of this issue occurring?
You're correct! This is generally what you'll see if you're trying to exploit real-life insecure string comparisons. That is, the actual delta small enough that we can't really figure out the next character. You can hedge against this by specifying a higher value for -n/--number, but in general brute force mode is more of a PoC than something I whip out on when doing a web app pentest.
With -n of 500, I've been able to detect deltas of 1 millisecond. With -n of 10,000, I could drop that to 0.1 millisecond/100 microseconds. This was against localhost - it gets harder over the LAN, and much harder over the WAN. With a concurrency of 5, the last test (with -n of 10,000) took about 2.5 hours to get one byte
That said, a variance of even 100 µs isn't something you'll generally see for insecure string comparison if that's the issue you're looking to exploit - generally the early return from that is on the order of single-digit microseconds (if I'm remembering my tests correctly - at this point it's been awhile :) )
If I remember correctly, reducing concurrency also helped a bit, but not a ton so long as you keep it under the threshold that the attacking machine and the target server can support.
Also, do note that that error will pop up after you find the correct password (since all further inputs are incorrect). It'll also happen if it gets the character wrong. In your example, it could be that the R is wrong (so all subsequent guesses are also wrong), or that the password is R (so all subsequent guesses are wrong). Of course, the most likely scenario is that the delta between good and bad inputs isn't detectable with an -n of 75
