Posted April 30, 2014. Look at the replies to see if it was fixed.
Using the Bruteforce options on iThemes security 4.1.5 to lockout people trying to use the same username from multiple hosts can result in attackers discovering if a username exists on the website. This is because iThemes security only blocks overused usernames if they exist, otherwise it just goes by ip address in blocking.
Here’s how it works. Let’s say an attacker has multiple locations they can login from (proxy, botnet, hacked websites, etc) and are planning to test for the username “admin”. And we’ll say that the bruteforce options are enabled on the target and:
“Max Login Attempts Per Host”=5
“Max Login Attempts Per User”=10
If “admin” does *not* exist: The attacker attempts to login with “admin” from the first, second, and third hosts, and so on, and is continuously blocked *after* 5 login attempts from each.
If “admin” exists: The attacker tries to login with “admin” from the first and second locations and are blocked after 5 login attempts from each. However, from the third host, they are immediately blocked instead of being blocked after the “usual” 5 attempts. The same immediate thing happens on the fourth and fifth locations. After one login attempt they are blocked.
So, with the user existing, the username is blocked after 10 total tries, as desired. But if the user doesn’t exist, it is not blocked even after several dozen tries.
Thus, if an attacker can verify that iThemes security is installed (by trying to access it’s plugin folder on a website), and considering the default setting of 10 for “Max Login Attempts Per User” (at least it was last I checked), then they can use the above method to easily determine if a user account exists or doesn’t.
I have done the above on my own site(s) from various proxy sites, and have found it to disclose the existance of users. Real usernames get treated differently than nonexistant ones.
Possible Solution: iThemes Security, with regard to bruteforce blocking of user names, needs to treat all usernames given as if they actually existed, regardless of whether they actually do. Otherwise, it will disclose the existance of real usernames, which obviously goes against the purpose of it not letting the login screen show whether a specific username was right or wrong. We all know the many reasons why this is a good practice (and not just because they can try to guess your password).
Also, to avoid timing attacks, iThemes Security needs to treat usernames exactly like ip addresses: keep a separate list and check how many times during the set period they have been tried *before* seeing if the username and password are correct. If it has been used past it’s allowed number of times during a set period, block them. Don’t even see if they are right (it’s possible that legit users could be blocked, but this is how this subsystem is suppose to work). Thus there will be no difference in the delay of responses using correct user names and incorrect ones. Even a fraction of a second can disclose info. (Perhaps it already does this, I just wanted to state my opinion on it).
Remember, it may have been fixed so check the replies!
As a temporary fix, users may want to set “Max Login Attempts Per User” to 0 (even though it’s not recommended) or a really big number. This will disable this part of the check, but still allow for host blocking by would be attackers doing too many logins.
ie, in Bruteforce settings:
“Max Login Attempts Per *User*”=0
Also, I tried looking for a safer location to share this, but iThemes directs all questions to this location. Would be nice for an email to send security issues, or a link to a form, that shows up on the Help tab of the interface.
- The topic ‘Security: Disclosure of usernames via "Max Login Attempts Per User" option’ is closed to new replies.