Aggressive password policy: When your security turns against you.

Say you have an application on a pentesting gig. Say that application has a special “Recover your account” routine, which includes authenticating with your personal information, such as your Social Security Number (Or at least the last 4 digits), your account number and your date of birth, instead of the usual “We’ll send a link to your email account”. Now, say that because of the application’s password policy, it prevents you from using that information as part of your password. Now, say we use this against them…

This type of authentication, which is done by humans instead of an automated system, is usually left for cases in which the application being accessed has the following characteristics:

  • Is part of a big entity (One that can afford having human verification)
  • Has highly sensitive data or allows accessing resources which can critically affect people in real life.
  • In case of any data or resources being breached, the entity’s reputation could be at great peril, or even suffer heavy financial loss up to and including bankruptcy.
Okay, maybe not that severe…

The reasoning behind this, which could be questionable, is that email addresses are easily hacked every day via phishing, malware and/or data leaks.

Now, of course behind all of this, lies a heavy and seemingly secure infrastructure, which includes limited attempts and preventive account lockouts, rate limiting, various layers of hacking attempt protections and of course a strong password policy.

For obvious reasons, the application on this gig, prevented the user from using data which could then be used to authenticate it, as part of the account password. This means that you could not use your SSN, your account number or your date of birth. None of that information could be used as part of the application’s user name as well (Although who would use their SSN as part of their username).

The application also had a check against the last 5 passwords used, including the current one. This would mean that if that the user were to change its password, either because it was requested by the user or because it was requested the application, the application would not allow the user to set the same password it currently has.

Since it would be insane to make this check as a client side script because it would kinda look like this:

No, it’s not a real example. It’s not 1995 anymore 😦

So, this application had to send a request each time you pressed a key, using XMLHTTPRequest, to a special endpoint which responded with the strength of the password sent, and if it was a valid password at all.

Now, of course I cannot show the actual requests to the application, but I’ve roughly replicated them on a local application so that it could be seen more clearly:

That’s not my actually real password. Or is it?

After seeing this, some of you may have noticed the same thing I noticed, and got hacker’s goosebumps. It seems that our developer friends, instead of taking the current logged in user from the session context, sent it as a user-controlledparameter. This was easily checked by trying with my old password and then trying with my old password and a different username:

This is the response we expected from the server.

Changing the user name to one different than my own:

Needless to say, that should not happen. The server should take the username against which the test is being done from the session context, not from a user-controlled parameter.

What can we do with this? The first thing that comes to mind is that we can brute-force a user’s password with unlimited tries, on an endpoint that is surely not being monitored and expects lots of traffic (each time a user types a letter on the password box, a request is sent). But we can also go another way…

We said that in order to authenticate us against a human, thus getting access to an account we need:

  • The last 4 digits of the user’s SSN.
  • The user’s date of birth.
  • The user’s account number.

We can brute force these values from the endpoint, which would take a lot less time and would have a 100% success rate. For this, we can use Burp’s intruder:

We are running the fuzz against the user ANOTHERUSER
Important to set the payload options correctly (0000 to 9999)

And we let it run. After a few minutes:

Bingo 🙂

Rinse and repeat for DOB, and account number and you’re done. Of course, you would need to put your best poker face, and go the social engineering way to gain actual access to a target’s account, but that’s another story…

Conclusion: I guess the classic recommendations stand here as well as anywhere. Never trust user-controlled data and always extract the user against which a check or a change is made from the session context. And for the pentesters: Never underestimate application’s endpoints and don’t just rely on Burp’s active scan 😀

Happy hacking!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s