4 Oct
2015
4 Oct
'15
8:51 a.m.
Hi,
I haven't done a security incident posting in a while, but that is
down to me forgetting to do them rather than any lack of them!
On 2nd October a customer's compromised Wordpress install was used
to attempt brute-force logins on another remote site's Wordpress.
This drew an abuse report which is how the original compromise was
discovered.
It's not known at this stage how the customer's Wordpress was
compromised. The site has been disabled.
Cheers,
Andy
About this email:
https://tools.bitfolk.com/wiki/Security_incident_postings
--
http://bitfolk.com/ -- No-nonsense VPS hosting
4 Oct
4 Oct
4:28 p.m.
On 04/10/2015 09:51, Andy Smith wrote:
On 2nd October a customer's compromised Wordpress
install was used
to attempt brute-force logins on another remote site's Wordpress.
This drew an abuse report which is how the original compromise was
discovered.
It's not known at this stage how the customer's Wordpress was
compromised. The site has been disabled.
Was the Wordpress install up-to-date?
While it could have been a weak password or a plugin, it's worth knowing
whether it could just be because they had an old version with a security
vulnerability, or whether there might be a currently unknown security
bug in the latest version.
Thanks
Gavin
4:45 p.m.
Hi Gavin,
On Sun, Oct 04, 2015 at 05:28:59PM +0100, Gavin Westwood wrote:
I'm afraid I don't know as I only have the information that the
customer gives me and I have limited grounds to insist upon
research.
It's not
known at this stage how the customer's Wordpress was
compromised. The site has been disabled.
Was the Wordpress install up-to-date? While it could have been a weak password or a plugin,
it's worth knowing
whether it could just be because they had an old version with a security
vulnerability, or whether there might be a currently unknown security
bug in the latest version.
Probability would always side with a known flaw or simple brute
force attack. The fact that the first thing it seems to have done is
a brute force attack lends weight to itself being caused by brute
force attack, as this is a pattern which is common also to SSH brute
force compromise: first thing they do is get it attacking other
hosts.
Incidentally there is an article here with Wordpress setup tips:
https://tools.bitfolk.com/wiki/WordPress_setup
If anyone thinks it could be improved, please do so.
Cheers,
Andy
--
http://bitfolk.com/ -- No-nonsense VPS hosting
6:07 p.m.
On Sun, Oct 04, 2015 at 04:45:00PM +0000, Andy Smith wrote:
Hi Gavin,
On Sun, Oct 04, 2015 at 05:28:59PM +0100, Gavin Westwood wrote:
I'm afraid I don't know as I only have the information that the
customer gives me and I have limited grounds to insist upon
research.
wp-fail2ban can be used with IPv4, IPv6 and doesn't take into account the login
that worked ok. So, no need to the the trick described there with so many
disadvantages.
I don't have the time to update it now, but if someone tries it and want to
upgrade the wiki, it seems totally worth it IMHO.
Thanks a lot,
Rodrigo
It's
not known at this stage how the customer's Wordpress was
compromised. The site has been disabled.
Was the Wordpress install up-to-date? While it could have been a weak password or a
plugin, it's worth knowing
whether it could just be because they had an old version with a security
vulnerability, or whether there might be a currently unknown security
bug in the latest version.
Probability would always side with a known flaw or simple brute
force attack. The fact that the first thing it seems to have done is
a brute force attack lends weight to itself being caused by brute
force attack, as this is a pattern which is common also to SSH brute
force compromise: first thing they do is get it attacking other
hosts.
Incidentally there is an article here with Wordpress setup tips:
https://tools.bitfolk.com/wiki/WordPress_setup 
8:09 p.m.
Rodrigo Campos said:
wp-fail2ban can be used with IPv4, IPv6 and
doesn't take into account the login
that worked ok. So, no need to the the trick described there with so many
disadvantages.
Pointing fail2ban at any access of wp-login.php?
Apart from expecting that people can get their own password right within
a few tries, I am not sure what the 'so many disadvantages' are.
If you are in control of all of the WordPress setups, fine, remember to
install a plugin on them all and hope the author(s) keep it up to date.
If you're not, trying to keep track of who's (un)installed it and who
hasn't is a never-ending source of fun.
In practice, you can set the maxretry to something like 20 which will
still catch the bots without any risk of catching any even vaguely
clueful real user.
I'm not sure where my login details are, or I'd update it to say that WP
has /finally/
a) Turned off comments by default on pages... but not posts
b) Stopped suggesting 'admin' as a username
c) Started generating strong passwords for new users.
They /are/ still having user privilege escalation exploits.
Oh, you can stop anyone changing the highly dangerous WordPress Address
(URL) and Site Address (URL) settings by having
define('WP_SITEURL', 'http://example.com');
define('WP_HOME', 'http://example.com');
in wp-config.php (do I need to say replace example.com with the real URL?)
Oh2, and having
define('DISALLOW_FILE_EDIT', true);
there no longer affects Quick Cache (now called ZenCache and a much
better option than their own cache plugin, especially if you splash a
few dollars for the Pro version...)
Ian
11:05 p.m.
Hello Ian and all
On 04/10/15 21:09, Ian wrote:
Rodrigo Campos said:
I have tested the fail2ban idea as set out in the WIKI article[1], but
did not have any luck with it. What Rodrigo actually pointed out is that
there is a plugin for WP called "wp fail2ban", which actually works
rather well. The "many disadvantages" he refered to is also not
completely clear to me, but I can verify that I did *not* manage to make
the WIKI recipe work for me (it doesn't mean that it's broken advice,
just that I did not hack enough at it to make it work properly, so the
failure should be seen as mine).
I like the WP Fail2ban plugin[2] mentioned by Rodrigo (I use it on at
least 9 sites I administer), and it is actually a bit of a pity that the
logging facility that it provides isn't part of the standard Wordpress
framework. In short, what it does is to inject log entries via syslog
into the /var/log/auth.log that looks like the following:
|Oct 17 20:59:54 foobar wordpress(www.example.com)[1234]: Authentication
failure for admin from 192.168.0.1 Oct 17 21:00:00 foobar
wordpress(www.example.com)[2345]: Accepted password for admin from
192.168.0.1 |
Very simple, it does not do anything more than that. It leaves the
blocking maintenance features to fail2ban. Quite handily, it comes with
a ready-made filter file (a file called wordpress.conf, search for it in
the plugin folder under wp-content) that you can copy to your
"/etc/fail2ban/filter.d" folder, and refer to in your jail file with
something akin to this:
---start---
[wordpress]
enabled = true
port = http
filter = wordpress
logpath = /var/log/auth.log
maxretry = 10
---end---
There is one issue with this plug-in: last update was 11 months ago, and
the last confirmed WP version it was officially tested against was
4.0.8. Still, I can confirm that it still works absolutely fine with my
WP 4.3.1 installs, and at least two other people also reported that it
does so for them too. A plus about this plugin is its simplicity, which
thankfully makes the PHP code is quite clear to read and understand
(even by myself whom cannot claim any real PHP proficiency).
wp-fail2ban can be used with IPv4, IPv6 and
doesn't take into account
the login
that worked ok. So, no need to the the trick described there with so
many
disadvantages.
Pointing fail2ban at any access of wp-login.php?
Apart from expecting that people can get their own password right
within a few tries, I am not sure what the 'so many disadvantages' are.
If you are in control of all of the WordPress setups, fine, remember
to install a plugin on them all and hope the author(s) keep it up to
date.
Yes, this is always a concern with third-party plugins. In the not too
distant past I had to retire useful plugins for exactly this reason.
If you're not, trying to keep track of who's (un)installed it and who
hasn't is a never-ending source of fun.
Quite! :-)
[1] Wordpress WIKI article: https://tools.bitfolk.com/wiki/WordPress_setup
[2] WP Fail2ban: https://wordpress.org/plugins/wp-fail2ban/
--
Regards,
Jan Henkins
5 Oct
5 Oct
5:58 p.m.
On Mon, Oct 05, 2015 at 12:05:53AM +0100, Jan Henkins wrote:
Hello Ian and all
On 04/10/15 21:09, Ian wrote:
I mean that the plugin should work with IPv6 and, as regular fail2ban filter,
just takes into account the failed actions.
The wiki instructions says those instructions don't work with IPv6 and "catches
any login attempt, successful or otherwise". Those are the disadvantages I
meant, the ones that the wiki says :)
Thanks,
Rodrigo
Rodrigo Campos said:
I have tested the fail2ban idea as set out in the WIKI article[1], but did
not have any luck with it. What Rodrigo actually pointed out is that there
is a plugin for WP called "wp fail2ban", which actually works rather well.
The "many disadvantages" he refered to is also not completely clear to me,
wp-fail2ban can be used with IPv4, IPv6 and
doesn't take into account
the login
that worked ok. So, no need to the the trick described there with so
many
disadvantages.
Pointing fail2ban at any access of wp-login.php?
Apart from expecting that people can get their own password right within a
few tries, I am not sure what the 'so many disadvantages' are.
3365
days inactive
3366
days old
6 comments
5 participants
participants (5)
-
Andy Smith -
Gavin Westwood -
Ian -
Jan Henkins -
Rodrigo Campos