My Favorite Password: '123456'You could be a victim of Credential Stuffing
Data leakage is a daily occurrence phenomenon, or at least that’s what I’ve read about. Lists of user/password pairs are stolen from various places on the Internet. Those mountains of information are then offered and sold in the 'dark web.' They are the required resources to be used in Credential Stuffing, the kind of attack we’re going to discuss in this post.
This form of attack consists of the large-scale automation of login attempts on chosen websites, hoping that any of them will be successful in gaining access to a user account and then violate their privacy, act on their behalf, or steal from them. In addition to the lists of usually thousands of user/password pairs to be tested, also called Combo lists or just Combos, it is necessary to possess software that works for the cybercriminal in an automated way.
Thus, contrary to what the attackers have to do in Password Cracking, in this case, they don’t have to guess passwords. They already have at their disposal the credentials to be tested. It seems to be a piece of cake, as well as something effective, especially when people have the naive habit of using the same passwords on different websites or applications. So, the attacker doesn’t have to be a hacker; they could be just script kiddies to perform credential stuffing.
The skilled hackers are those that, exploiting vulnerabilities, can steal and decrypt the databases of credentials. They then decide if they give them away to the world or offer and sell them in closed communities. The more recent the leaked combo, the more valuable it can be for anyone interested in this kind of crime.
So, once the script kiddies have access to a usually big list of credentials, they need a program that works for them. It will check every user and its corresponding password against a previously selected web application (without knowing if they will achieve anything there) to identify those that successfully log in. If there’s a match with an existing account, we can say that this one has been cracked. The tool would save that user/password pair along with the others that were also successful in the combo. From there, the attackers would proceed according to their purposes.
What about tools?
Figure 1. Photo by Cookie the Pom on Unsplash
Nowadays, although some experienced crackers use their scripts, there are tools (seemingly not free) exclusively designed for credential stuffing. We can easily find tips and tutorials on how to use them on the Internet. Some of the most popular programs are Sentry MBA and STORM. However, more recently, SNIPR has emerged with similar functionalities, but apparently with greater stability and a more intuitive interface.
The tools to employ in this kind of attack should have the ability to bypass diverse security mechanisms. For example, some websites have protection against massive login attempts from the same IP address. This behavior tends to be suspicious and associated with cracking by the web application’s owners. That’s why in these cases, the credential stuffing tool usually incorporates lists of proxies that simulate requests from several sites on the Internet, thus ensuring anonymity and non-stop automation.
Even with proxies, large numbers of login requests in short periods can draw attention (though not always). Here’s when the mature and patient attackers (not desperate teenagers) can perform slow credential stuffing with few requests for a day. However, it could take months for them to test thousands of pairs of the combo list. That gives time for users to change their passwords and make those leaked databases lose value.
Having a combo list, a tool, and proxies, the attackers commonly need to find and buy configurations or plugins to attack particular web applications or websites. The programs have some of them for free, but skilled hackers cleverly have built an additional market where they offer and sell other plugins to those attackers who have no idea how to make them. That’s another way for them to make a profit.
Any recommendation for prevention?
Do not reuse passwords. Try to make sure that there are marked differences between the passwords you use. Modify them continuously and in a creative way. You can create patterns for helping your memory, but I don’t mean just adding intuitive prefixes or suffixes. It’d be something like passphrases with words you easily remember, with peculiar variations for each account, not forgetting the use of any symbols, numbers, and capital letters. Of course, you can use password managers like 1Password or LastPass when you think there are many passwords to remember and keep safe.
For web application managers
First of all, give the previous paragraph’s advice to your users (do you know them? You should). Additionally, check their passwords against those that have appeared in known breaches. You can use HaveIBeenPwned and lists like the top 1000 leaked to identify publicly exposed credentials, and although they are not the most recent data, they can serve as a warning to your users.
Regarding login requests, it is foolish not to pay attention to the user traffic and login trends on your website, and especially if they are out of regular preliminary patterns — which can be more substantial through the fingerprinting technique. Those times when you see multiple IP addresses in action as something unusual (perhaps due to proxies in credential stuffing), you can also use geolocation and find out if the countries or regions to which those IPs belong correspond to those places from which your application is typically accessed. You could send emails to those users to guarantee that they were the ones who tried to gain access.
It is important that you establish countermeasures to potential attacks and thus let attackers know that they may waste time and effort with your web application. You could start by considering even simple solutions such as Fail2ban for blocking IP addresses when many failed requests are generated from a single one. CAPTCHA may be an additional countermeasure, and reCAPTCHA v3, which is easy to integrate into the applications, is usually more recommended these days to differentiate between bots and humans.
A slightly more advanced and recommended strategy to prevent credential stuffing is the Multi-Factor Authentication. This security solution could indeed affect, to some extent, your 'users' journey' in your application while they respond with every evidence (factor) required for information access. For this reason, you should be very careful, and preferably choose to use this method in cases of suspected attack or in circumstances where the user requires sensitive data.
Finally, and after considering the prior low-cost options to hinder the attackers' efforts, you can also call on commercial services against credential stuffing such as Cloudflare Bot Management and F5 Bot Management. Always keeping in mind that "No silver bullet exists so be wary of any company who tries to sell you one" (Overson).
Ready to try Continuous Hacking?
Discover the benefits of our comprehensive Continuous Hacking solution, which hundreds of organizations are already enjoying.