[wp-hackers] Detecting the present botnet attacks

[Nikola Nikolov]

Hi David,

When the attacks began I started blocking users on the second incorrect
login attempt for the longest time possible via the Wordfence plugin. That
was sort of ok - but as you stated - it's a waste of server resources.

The following solution is at the WordPress end - I know that this is not
what you're really looking for, but you can take a look at it(and it might
help someone else as well).

At the end I got really annoyed with the attacks and I did a simple thing(
I'm warning you that it's probably not suitable for most of the people out
there, although it might be plausible with a filter that would automate one
part of the solution ) - I manually changed the wp-login.php file.

I know - modifying core files is not a good thing. But hey - I don't want
someone to poke at my site/server.

So my solution was to check at the top of the file for the presence of a
$_GET variable and check it's value. Basically if you go straight to
/wp-login.php you would see "Unauthorized access!" and that's it. You have
nowhere else to go and you can't do anything. If you go to
/wp-login.php?myspecialkeyword=series_of_alphanumeric_and_special_characters
you would actually see the form. From then(that's the harder part) I had to
manually change the "action" attribute of the login form to include the
above $_GET parameter. After that the login form would work.

I'm not sure how well that's working - but I believe that this solution
works better than not using anything...

Okay - I played a bit and made this really quick and dirty mu-plugin. You
can find it here - http://pastebin.com/pTyCMd1z . Put it in your
wp-content's "mu-plugins" directory to make it run automatically. It should
have no impact on your site's performance since it's code only works on the
wp-login.php page. Once you upload the file, change the "define( ..." lines
to something that is actually more secret than the defaults.

This plugin will wp_die() (you can probably switch to just die() ) with
status 500 displaying just the "Unauthorized login" message unless you're
visiting the proper URL - with the defaults it would be "
http://mysite.com/wp-login.php?mysecretkey=myv3ry53cr37n0nc3". Some
JavaScript will then run and fix all of the login-related links and the
login form's action attribute, so that you don't have to.

Once you have that in place, just save the URL as a bookmark and that
should make things a bit easier.

I'm not sure whether the return code 500 has any effect on the attacks
intensity(like discouraging them) - I've had 93 POST and GET requests to
wp-login.php for the last 10 days - I remember that the attacks were very
intensive at some point, so it might have some minor effect.

Hope that helps,
Nikola


On Wed, Jul 10, 2013 at 3:14 PM, David Anderson <david at wordshell.net> wrote:

> Hi,
>
> As most of us know, there are ongoing brute-force password attacks going
> on worldwide, that are distributed and hence can't be prevented with
> single-site "deny after X failed logins" heuristics. The individual IPs
> only connect to each site once or twice. We are protecting some of our
> websites with BruteProtect, but unfortunately not enough people are using
> that solution yet to make it effective - in our analysis of our logs, it
> catches about 10% of bad hosts. That's better than none, especially if a
> site gets broken into, so we'll persevere with it - and mention it so that
> others may perhaps take a look at it and help boost that figure for all the
> users!
>
> But regardless of that, the multiple attacks on various websites on the
> same box are causing significant resource usage - perhaps around 25% of all
> resource usage on the server in question. We'd like to kill the attacks at
> an earlier stage - before the full WordPress load completes. We're thinking
> of adding a single line of code using PHP's auto_prepend_file feature (in
> php.ini) that will immediately die if an attack pattern is detected. This
> solution has the beauty of being something we can centrally manage fairly
> easily (our webserver's configuration file is written on-the-fly by a shell
> script, including per-site PHP-options). (Adding plugins to every site
> would be much more cumbersome).
>
> This line would detect that the URL being visited is wp-login.php, and
> then apply some other tests. Looking at the logs we've collected from the
> attackers, we see these two patterns:
> 1) The POST payload does not include [wp-submit] => 'Log In', which you
> would have if logging in from the normal wp-login.php page.
> 2) The usernames are all one of:
> * admin
> * administrator
> * the domain name of teh website being attacked
> * {domain} (literally - presumably a bug in an earlier of the attacker's
> code)
>
> So, we're considering banning all those usernames from the hosted sites.
> But, it looks like we could get a quicker result by blocking based on 1)
> instead. Question: Does anyone know if that's reliable? i.e. are there
> scenarios in which a likely user POST to /wp-login.php does not include
> that field? (Note that the popular Theme My Login plugin doesn't POST to
> /wp-login.php, so differences on its login form aren't important). (Of
> course too, if someone's built some legitimate automated WP tools that
> don't include that field, then this'll break them too - but we can deal
> with that if it ever happens. I'm just interested in normal Joe User WP
> usage).
>
> Of course we could also combine 1) and 2) to reduce the risk. But I'm
> still interested in the answer to the question.
>
> Many thanks,
> David
>
> --
> WordShell - WordPress fast from the CLI - www.wordshell.net
>
> ______________________________**_________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.**com <wp-hackers at lists.automattic.com>
> http://lists.automattic.com/**mailman/listinfo/wp-hackers<http://lists.automattic.com/mailman/listinfo/wp-hackers>
>