SCARY! Limit Login Attempts lockout bypassed?

Hi,

As far as I know there is no way to get around the enforcement, so I would be really interested in investigating this further.

Do you have any kind of access log for the time period to show what access the IP in question was doing?

Do you otherwise get working lockouts?

Would you be willing to run a version of the plugin with some extra checks to help us understand what is happening here?

Please contact me at [email protected] to investigate this further.

Hi Johan,

THANK YOU very much for your quick answer/concern.
Yes I could not believe that too especially I tried to lockout myself a week ago and everything worked perfect.

I am currently investigating to see if I can get more elements…
I keep your email and will inform you about that.

Thanks again!
Jamy

As there has been no further development for a week I’ll mark this topic as resolved for now.

If you have any further information please send me an e-mail.

Hi Johan,

I tried to get more elements about what happened but unfortunately could not get much more…
In the meanwhile I had banned a full range of IP from Russia which I guess hosts a certain number of non protected servers used by bots, etc…
I also increased my lockout time to 120 minutes (after 3 wrong passw)

I was waiting to see if this situation would occur again but did not see anything coming until now.
So right now I’m in standby. If anything happens again I should have more elements and I will install the plugin with some extra checks.

I keep you informed and will drop you an email if anything similar happens again.
THANK YOU very much for your quick answer/concern!

J.

I’ve finally found an explanation for this.

There was a bug that allowed an attacker to keep trying “auth cookies” even during lockout.

See changelog of new release for more details.

And thank you for the report which started this.

Hi Johan,

Thanks for getting onto this issue quickly. I think I’ve found a minor misunderstanding in the fix code relating to action priorities. WordPress handles actions on a single hook in ascending order of priority index; so functions which hook an action at a priority of 1 get run before functions which hook an action at a priority of 10.

Here’s some code to test that assertion:

function test_plugins_loaded_99999(  ) {
	error_log( "Priority was 99999" );
}
function test_plugins_loaded_0(  ) {
	error_log( "Priority was 0" );
}
add_action( 'plugins_loaded', 'test_plugins_loaded_99999', 99999 );
add_action( 'plugins_loaded', 'test_plugins_loaded_0', 0 );

Here’s a snippet from my error log in running WordPress with those actions in a plugin:

[06-Jun-2012 11:45:52 UTC] Priority was 0
[06-Jun-2012 11:45:52 UTC] Priority was 99999

In the code comment on limit_login_handle_cookies you explain “Must be called in plugin_loaded (really early) to make sure we do not allow auth cookies while locked out.” However this function is hooked on the plugins_loaded action with a priority of 99999, which means it’s actually running really late. As I understand it, this would only cause an issue if other plugins were doing things with cookies/auth on the plugins_loaded hook…?

Hope this all makes sense, and thanks again.

Best regards,

Simon

Hi,

You are right, somewhat. I’ll fix up the priority, but as you say it does not really matter. The important thing is that it runs during the plugins_loaded action instead of the init action. The later is after WP core first parse the auth cookie. That was the bug introduced in 1.6.2.

The comment is supposed to describe the fact that the plugins_loaded action is the earliest standard action available.

I’ll continue looking as this. We might still have teoretical trouble if a plugin or theme uses certain functions on their file load.

It seems resolved after version 1.7.1 released.

But Still multiple try could happen, maybe just bypassing auth cookie.

How about keeping IP and username in table? and block IP in the first place after lockout?

And about site behind proxy?

Using 1.7.1 of the plugin and I too have experienced a similar issue to the original poster, in that last night I received almost 60 attempts from the same IP address to login to my site.

This despite only allowing 3 retries…

The plugin seems to do its fundamental job, but something is clearly not working as intended when it comes to locking users/bots out after a certain number of tries?

Can you check what urls was attempted from the access log?

Do you still get attempts? Would you be willing to run some testcode to figure out what is going on?

It looks like my /wp-login.php page took a hammering.

I’ve had it happen again this afternoon at 16:49 BST. Twelve attempts from the same IP address at the same time.

Yes, I would be willing to run some testcode.

Hello Johan,

Like dankrosso, I also had another Brute Force Attack last night while using plugin’s latest version (v1.7.1)
I did email you all the elements I have right now in order to help finding out.

Thank you.
R.

I’ll be working on this tomorrow afternoon CET (no computer access right now).

Thanks for looking into this. I manage several WordPress websites across different hosts, and I’ve noticed a huge increase of brute force attacks in the last week against all of my sites.

I use the Limit Login Attempts plugin on each of them, and I’ve noticed that some IPs continually circumvent the lockout period.

They’re always targeting the “admin” account, which I never leave as “admin”. I know they’re using proxy servers, and it’s probably one or two people behind 99% the attacks we’re seeing, but we should at least force them to exhaust their allocated IPs.

A cool “opt-in” feature for Limit Login Attempts would be a master log that keeps track of all the locked-out IPs from all of the participating websites. If we could boil it down to a specific set of distinct addresses in a given period of time, we would know which IPs to block, even before they attack. Plus, we’d have a better chance of reporting these guys to the authorities.

Yes, they could always get another block of IP addresses or change proxy providers, but at least they’d have to work harder.

Hi everyone!

Maybe not the exact place to discuss about options etc but subject and plugin are so interesting we might have one day to open a forum somewhere ??

Just to say that exclusion of IP can slow down annoyances but I didn’t find this solution very efficient after working on this…
I have several VBulletin forums and it is unfortunately the most attacked forum script on the market especially as one must pay a consequent amount of money to remove their famous “Powered by VBulletin” line ??
Displaying their brand acts like a strong call message saying “Try hacking/spamming me!” ??
Now some VB forums ask users to fill up to 4 different types of Captcha to avoid bots (write what you see, answer a question, calculate this, give the time on the clock)…Woow when shall we need to fill a form with our mobile number then answer to an SMS? Bots really succeeded in bothering others so much…

So during almost 1 year I regularly worked on tracking bots and spams in order to establish an accurate IP ban list for my HTaccess.
I used many tools including the convenient “Who’s online” inside VBulletin which shows like a live stats script who is trying to see/do what and when. I could see (in live!) bots trying to bypass the captcha and trying to login, etc…

Well my conclusion is that although there are of course some regions (Russia, Ukraine, etc) that can be totally banned as too many servers over there are used for hack/spam etc, it is also a tough job to block ips as bad guys are constantly moving trying to use any weakness in a server and launched their attack from there.
Moreover I don’t see how/where we can report these guys or IPs…I mean already multi-dollar companies with a bunch of lawyers can hardly stop anyone harming them online. So yes it can slow down but…

I do believe the strongest protection right now would be to correct the (recent) failure of “limit login” plugin to be bypassed by some bots.
But yes a Master log would be a cool option and bcwp is right. Who is using admin as username today? Totally unsafe! So what about an “Exclude Admin user” option? (banning immediately any IP using “Admin” in username)…Just an idea! ??

A big THANKS to Johan for the precious time spent on this GREAT and USEFUL plugin!