Ah yes, credential stuffing! Almost as common as thanksgiving stuffing, yet as distasteful as black Friday shopping. Credential stuffing is especially effective when it’s coupled with user enumeration. The likelihood of user enumeration attacks occurring on typical web applications is high, and the impact is often hard to define, making this a moderate risk severity finding in most findings report. But that doesn’t mean user enumeration should be ignored! In this blog post I am going to briefly talk about user enumeration and credential stuffing, and then expand on all the different vectors of attack that can be borne if a malicious attacker stuffs your application!

By definition credential stuffing is “the automated injection of breached username and password pairs in order to fraudulently gain access to user accounts” (OWASP). In contrast, user enumeration occurs when applications reveal directly, or indirectly the existence of their users.  In practice, attackers will often use automation to guess valid usernames. Let me set the stage for you:

We all know and love the “reset password” functionality of websites you frequent. Now let’s pretend we’re an attacker trying to gain access to a user’s account that doesn’t belong to us. Typically, the reset password function will require us to enter an email address or username associated with an account. Now, we will use an automated tool to enter an email address or username from a previous data breach into the field hundreds of thousands of times in lighting fast succession. If we guess one correctly, the application might respond with a different error message than the ones we had been receiving; indicating that we probably guessed one right. Some applications may even disclose the email address associated with the account and ask you to check it to reset your password.

Well, as an attacker, not only do I now know that the username exists in the application, I may also even know what that user’s email address is that’s associated with the account.

Now, let’s unpack what this means and what this can lead too. A determined attacker with all the time in the world could abuse this functionality to generate a huge list of usernames for the target application. They could then sell that list to other hackers who might be even more inclined to focus on that specific target. They then might start trying to guess passwords to gain access, or even worse; they might leverage a data dump from a previous breach to lookup passwords for their victim accounts. Once they have a hit, they can then abuse that authentic account to pillage at will.

Assume that website is a banking portal, and the compromised account is a bank teller with access to users’ account information. That attacker can now sell all that juicy information and privileged access to the next bad guy.

Alright, enough with the “what if” scenarios, you get the point. If your application allows automated, unthrottled requests to your backend, your application is vulnerable and so are your tenants. Here are some things that block this sort of attack:

  • Time restrict the number of password reset requests to come from that session.
  • Enforce captchas for sensitive requests.
  • Limiting the number of login attempts before enforcing progressively longer lockouts.
  • Enable multi-factor authentication (MFA).

These are just a few recommendations to mitigate the risk of automated attacks. Additional guidance can be found by visiting the following links:

https://owasp.org/www-community/attacks/Credential_stuffing

https://cheatsheetseries.owasp.org/cheatsheets/Credential_Stuffing_Prevention_Cheat_Sheet.html

https://www.cloudflare.com/learning/bots/what-is-credential-stuffing/