Distributed Account Lockout Attack

Over the past few days I’ve been pondering an older threat against applications – lockout attacks. The old attack would involve a single user who wanted to lockout another individual or group of individuals by entering multiple unsuccessful passwords. The goal isn’t to guess the password, but to lock the account by sending multiple unsuccessful login attempts. Now, if this user was particularly malicious he could try to enumerate all of the usernames for an online system and then use a script to lock out all of the users. This is a real threat for current online systems. However, once the system owners detected this attack they could respond and block incoming requests from the IP address and likely track down previous activity from that user.

Lets take this idea and add make it a distributed attack originating from a botnet. Instead of a single user attacking multiple user accounts, we now have thousands of individual machines scattered throughout the world attacking a small number of accounts. How would we defend against this sort of attack? Previously a single machine was launching the attack and action could easily be taken against the offending IP address. But now the number of malicious machines increases to the thousands – all locking 10-20 accounts each.

How does this attack compare to a distributed network based denial of service? One key item is the attacker does not have to actually exhaust network resources. A network based denial of service requires a large number of machines for it to be successful. Each machine sends legitimate requests to the site in an attempt to use up all the available bandwidth on the server side. Once the bandwidth from the botnet attack stops clogging the pipe, the attack is over. However, an account lockout attack would cause damage with any number of attacking machines. 1000 machines wouldn’t cause a DDOS against a major online site, but it could lock out 50,000 users without difficulty. Another issue with this attack is simply unlocking the affected accounts won’t solve anything. The attacked site must quickly identify the attacking machines or eliminate their ability to lock out accounts. Otherwise any accounts which are unlocked, will just be locked by the next wave of attacks.

I can see this type of attack being a real threat to the massive social networking sites and possibly financial sites which have not added multi-factor authentication. Given the large botnets that have been forming, I’m almost surprised we haven’t seen this type of attack yet (please correct me if I’m missing some).

Here are some solutions I came up with:

• A captcha of some sort may be a good option. We are seeing this in more financial sites. But for those sites that don’t want a captcha for every login, consider requiring the captcha after 3 failed logins. At this point we should get suspicious and want to confirm that we are dealing with a person and not a bot.
• Incident response should be prepared for this type of attack. Be able to quickly pull metrics showing IP addresses which have a large number of failed logins or have locked out more than 1 account in a small amount of time.
• Along that line, it may be worthwhile to generate an IDS alert whenever a single IP locks more than 1 account in a small window of time. Generating alerts on this behavior could provide information on the beginnings of an attack (instead of hearing from the helpdesk that you just received thousands of password reset phone calls)

-Michael Coates