Brute Force Attempted This Morning

Hey there, there was a brute force attempt on my site this morning, which shouldn’t have been possible with the S2member brute force settings in place. The hosting company took the account offline and the hacker didn’t get in, but I’m still looking into why it was even possible to attempt it that way when they should have had a 30 minute punishment after the 5th attempt.

As a temporary, and perhaps permanent addition, to my site security I’ve added a captcha math question to the login form so if trying to login you would have to answer math questions with each attempt. However, I’m wondering if the S2member pro login widget is perhaps leaving a small window of opportunity with this type of attack. I’ve tried logging in with the incorrect user name and password and I’m automatically redirected to the login form and the captcha question. However, there isn’t a way to implement that on the login widget itself. So, you get at least one attempt without regard to the captcha question through the widget. That might be something they can exploit if their script is capable of opening windows and seeking out the login widget as a means of gaining access to the site.

I’m wondering if that has anything to do with why S2member didn’t auto punish the attacker after his 5th attempt? Could attacking through the widget somehow bypass the brute force settings? It was an attack on the wp-admin part of the site. I’d be happy to set up an account for somebody to poke around the S2member settings if that would help.

Rich

Thank you for reporting this important issue.

I’m wondering if that has anything to do with why S2member didn’t auto punish the attacker after his 5th attempt? Could attacking through the widget somehow bypass the brute force settings?

What do you have set up in your Brute Force settings?

See: Dashboard -› s2Member® -› Restriction Options -› Brute Force IP/Login Restrictions

And no, the Login Widget hooks into /wp-login.php, and all restrictions apply there.

It is currently set to punish after 3 login attempts, it was set to defaults prior to the attack, punishing for 30 minutes after 5 failed login attempts. I verified this while on the phone with tech support right after they restored the account to active service.

I tested this myself this afternoon with a mobile hotspot. I deliberately gave the wrong password 3 times and it locked me out, I verified I was locked out by ensuring I used the correct password and username and I still couldn’t gain access to the admin area due to the 30 minute punishment window.

So new question, is it possible that S2member was working perfectly, and locked the hacker out, but his continued attempts to submit password and username combos was putting stress on the server? The login form is still available, you can still submit a user/pw combo even when locked out, might that have been what was bogging down the server?

They took my whole site offline when their server CPU usage spiked from the brute force attack. The tech on the phone verified that the hacker was trying multiple combos per second. That stressed the server, and it either took my account offline automatically or one of the techs was alerted to the attack and did it manually. Either way, the server was apparently still taking a pretty heavy resources hit.

Is that normal even if they are locked out? Or should the strain on the server have been averted when the hacker was locked out after hitting the limit for failed login attempts?

So new question, is it possible that S2member was working perfectly, and locked the hacker out, but his continued attempts to submit password and username combos was putting stress on the server? The login form is still available, you can still submit a user/pw combo even when locked out, might that have been what was bogging down the server?

Yes, that sounds like what the problem was. Many servers will provide a firewall to keep that from happening. I believe the term you’re looking for her is Denial of Service (DoS, also sometimes called DDoS). They were doing a DoS in conjunction with trying to hack in through Brute Force. s2Member stopped the hacker from hacking your installation, but your server still maxed out memory/CPU.

See: http://en.wikipedia.org/wiki/Denial-of-service_attack

If this happens again I’d strongly recommend talking to your hosting company about setting up a firewall (or if they have one, a better one). If they do not have that available, you may think about switching hosting companies. We recommend FireHost.

That may explain it then. Brute force was their term, not mine. So I assumed it was repeated login attempts and perhaps an issue with my settings. Having tested it myself though, the lockout seems to be functioning. That seems to make the DOS component likely and also explains the server maxing its memory/cpu resources.

I’m not super savvy on what protections they have in place. I may not be explaining this the best. When I say they took my account offline, I believe it was my hosting company that did it, because the site was being attacked. I do not believe the hacker took the whole server down in the DOS attack, they saw it happening and either the server deactivated the account or they did it manually to prevent continued attempts at gaining access.

When I spoke to the tech they said it seems to be a trending thing lately on wordpress installations. They were recommending another login limiting plugin. That’s where my confusion started, having had S2member already set up to block brute force attacks. I almost wonder if because S2member doesn’t deny access to the wp-login as part of the lockout that the hackers brute force attack may have turned into a DOS as a side effect. He started his brute force script, and was locked out immediately, but since the form is still available for user/pw combos and the script was still running, it became a DOS by default. Then my hosting company took the site offline as some sort of safeguard.

I’ve added a captcha math question to the login form which should prevent both from occurring in the future, but I may call support up again tomorrow to get more details. What questions do you recommend I ask? Should I be asking about the safeguards they have in place for brute force as well as denial of service?

Thanks for the help, by the way,

Rich

What questions do you recommend I ask? Should I be asking about the safeguards they have in place for brute force as well as denial of service?

I’m not very experienced in this aspect of site security, it seems like the only way to keep this from happening would be for your hosting company to be able to track when multiple connections are going on from one source very fast and stop that from happening from the server level. As far as Brute Force hacking goes, s2Member has you covered here. There’s no way someone could try more than 5 (or in your case, 3) passwords and not get locked out from trying more for awhile.

I’d recommend asking if there are any options you have with firewalls protecting your site from multiple fast connections like the hackers were attempting today. That’s the only thing I know of that could stop this.

Thanks, I will chat with them a bit and see what they have to say about it and maybe I can get more information about the type of attack and how to prevent it. I think you are correct, there is some terminology confusion going on here.

It may have started as brute force, but I think S2member locked it out, and the repeated attempts during the lockout bogged the server down and that’s when they took whatever action they did. I’m reading between the lines but I think they took my site offline during the attack, honestly I don’t have a huge problem with that. Best way to thwart an attack is to remove the target. It was only down for a few hours and they restored it immediately after talking with me.

I know they have since banned the IP the attack came from so hopefully the hacker will move on to a softer target. I appreciate the help and thanks for doing your best to answer my questions even if they did stray a bit from the S2member side of the equation. I do believe we have this resolved now and I’m glad I invested in S2member because it’s already protected my installation once! Hopefully it won’t be a regular occurrence. Thanks again.

Rich

Actually, just one more thing to add…

As a possible suggestion for future releases of S2member, might there be a way to lock an IP address from even accessing the wp-login form during the lockout period? If you fail the login and reach the limit, have S2member block that IP from accessing the wp-login area of the site. That would prevent not only brute force attacks, but any resulting server resource consumption that would cause issues on the server end by attempting logins even when already locked out.

As a possible suggestion for future releases of S2member, might there be a way to lock an IP address from even accessing the wp-login form during the lockout period? If you fail the login and reach the limit, have S2member block that IP from accessing the wp-login area of the site. That would prevent not only brute force attacks, but any resulting server resource consumption that would cause issues on the server end by attempting logins even when already locked out.

I’m sure this is possible. However this really would not help because the idea here is that the connections are still going through and PHP is still running causing s2Member to load, so really this wouldn’t help very much at all.

This needs to be dealt with at the server level.