Creating Credential Stuffing Resistant Applications

Recently, the amount of coverage on credential stuffing attacks in the news has grown. Organizations that haven’t yet been hit by this type of attack can sometimes overlook the potential risk and cite that it’s an end user’s responsibility to use more secure credentials. However, following a successful attack, many the same organizations find themselves scrambling to respond and reposition platforms as ‘secure and private.’

We want to help companies avoid this by sharing some best practices that development teams can use when creating applications to protect their organizations and make it difficult for attackers to exploit APIs in use.

One of the main ways that developers can improve security posture is by keeping in mind what the CQPrime Threat Intelligence Team calls the Four Pillars of Detection— credentials, tools, infrastructure, and behavior.

A Quick Primer

With data breaches happening almost weekly, it’s easier than ever for bad actors to acquire fresh lists of credentials. Additional sources they leverage are various web, social media presence, and simple dictionary type lists (i.e., bob.smith@gmail.com or bob.smith@me.com). With little effort, they can quickly gather a few hundred thousand accounts to use in an attack.

These attacks often make use of commercial toolkits readily available from ‘cracking’ marketplaces, in addition to the tools bad actors create. These will then be used to test and orchestrate their attack once they identify a target.

Behavior is two-fold. It’s how the attacker and the user interact with an application. Many organizations fail to think about the security ramifications of application and user interaction.

How APIs Simplify Credential Stuffing

Here’s a recent real-world example for you: a development team published an API login endpoint to authenticate mobile application users. However, that login endpoint was shared by multiple services outside of the mobile application, making it easy for attackers to discover, analyze, and abuse it.

Our researchers created legitimate accounts for the service mentioned above and then created a small list of fake accounts to test.

If the account username and password were correct, the service returned “accountId”:”<useraccount>.”

If the username was incorrect, the service returned “Account not found.”

If the password was incorrect, the service returned “Password incorrect.”

From this behavior, researchers concluded that a simple script that tested a list of emails would eventually end up confirming valid user accounts. From there, an attacker might employ straightforward dictionary attacks, password reuse attacks, or even try to exploit a password recovery routine to develop their list of usernames further to include those with valid passwords.

Finally, when the credentials list is complete, the behavior of the application understood, and tools configured, the attack can begin. This could be a simple smash and grab attack that allows for millions of attempts to compromise data all at once. Or, this could dribble in one at a time over weeks. The infrastructure available to the attacker can be as simple as just their PC or be as involved as BOTs running as rogue services on compromised IOT devices or parts of a Bulletproof Proxy network.

Credential Stuffing Resistant Development Processes

How can development teams use the Four Pillars of Detection to their advantage during the application development process? Here’s how the methodology can help organizations create applications that are less susceptible to automated attacks:

• Credentials: Emails are easy to use as a username; they are also easily guessed. Ideally, you should suggest that the user create a unique identity for your service. If you want to make it easier for your customers, you will probably want the username to be an email. However, you should not make it easy for an attacker to validate an account without supplying a password (as illustrated in the example above).
• Tools: There are plenty of commercial attack tools available on the market. Have your security team find them, evaluate how they work, and look for predefined attack configurations that target your organization. Go a step further and subscribe to the cracking forums (if you do not already). Ensure that, if you find a configuration targeting your organization, you understand how it works and modify the behavior of your application to invalidate the tool or trick it into a honeypot. Eventually, the tool will stop working, and the attacker will have to change to match, so it will be essential to remain vigilant. Security is never a one-and-done exercise.
• Infrastructure: Be aware of your users’ compute environment. Are you a small government office that takes fees online for a small town in the US? If so, then why are 70% of your users from Somalia? Why do half of your users use an old version of Chrome on Android? Understanding what is connecting to your application is a step toward not only securing yourself but also tooling the application performance for your constituents. Tuning for your legitimate users makes it more difficult for attackers to succeed. These types of attacks happen regularly and are only becoming more sophisticated.
• Behavior: Most importantly, application behavior should be built so that it helps inform the user but does not enable an attacker. Error messages should be overt but should not include or expose lookup times, page sizes, or message bodies, all of which can help an attacker. Give them nothing. It might cause legitimate users to become confused, so your support team may need to have a way to see what is going on, but the user should be notified that something didn’t work with a generic message, free of details.

Credential Stuffing attacks happen regularly and are only becoming more sophisticated. Following the recommendations above can help knock the foundation out from under the attacker and give you the upper hand in an uncertain world.