Got brute force?
Everyone knows what brute force is so I'll keep this bit brief. In the context of credential brute forcing, the basic idea is to find valid username/password combinations by sending multiple requests to a login page and examining the responses. This is easy enough to perform by loading the login POST request into Burp Intruder, choosing variables, selecting your word lists and pressing start.
But what about mitigations? These days most web developers are wise to this type of attack and implement measures such as lock-outs, captchas and rate limiting to prevent brute force.
Getting around mitigations
There's always a way around mitigations and brute force is no exception. Spreading the attack across multiple accounts, using multiple ip addresses or rate limiting your requests can avoid lock outs and captcha's can be solved in an automated way with something like Tesseract.
And for all of the above subtle differences in responses from the server can sometimes offer important clues. Things like:
- Size of reponse
- HTTP response codes
- How long it takes to receive response
- Content of response
A Case Study: Etsy.com
Etsy uses two mitigations to stop automated brute force. First up a throttling mechanism that kicks in after 20 incorrect logins. This is performed on a per ip basis and starts off using a 10 second delay (maybe increasing later). Although not as secure as a lock out/captcha, it still does a good job of slowing our brute force attack significantly.
As we hit 20 requests we see the 10 second delay start.
The second mitigation is the use of a captcha after 20 failed logins.
As blocking is performed on a per ip basis, we could try a distributed attack. For example by using a hundred different addresses we could increase our maximum 20 requests to 2000 requests before being throttled/captcha-ed.
Realistically though 2000 requests isn't enough and although possible, getting hold of a hundred addresses (or a botnet) wouldn't be easy, not to mention having to deal with the captcha! Perhaps we can find another technique?
Breaking the lockout
Something I haven't mentioned is what happens when you login successfully.
To test the effect of a successful login I sent a series of incorrect logins (which triggered the throttling) followed by a correct login request and then more incorrect logins. Looking over the results I was surprised to see that as soon as the legitimate request was received by the server my requests were no longer being throttled and I wasn't required to enter captcha!
Below is the output from Burp:
Sending 20 incorrect logins causes the throttling to kick in (first red circle). I sent a legit request in my browser and the throttling was removed (second red circle). Also 2-3 second delays were caused by the free version of Burp Intruder :)
So it turns out Etsy used a server-side failed login counter that was reset any time you logged in successfully. All an attacker would need to do is send 19 bad requests followed by one good request and they would never have to deal with the throttling or captcha. Job done.
Final Thoughts
Brute force is an age old attack vector that often works just as well today as it did 20 years ago simply because authentication techniques have not moved with the times.
In this instance we've seen how just one logic flaw allowed us to side step all of the mitigations. A lack of defense in depth meant that once we had bypassed the failed login counter we were free to brute force to our hearts content.
Thanks again to Etsy for their swift response and fix!
PwnDizzle over and out.
P.S. I've got a new twitter account! Add me as a friend, follow me, tweet me, etc. @pwndizzle