more wordpress brute forcing…

(originally written april 9th.)

OK. so the wordpress password guessing game changed this morning. We started getting hit fast and hard. I’ve seen everything from 180 guesses in 23 seconds to 2000 in 120 seconds. And then there are (still?) the stealth scanners… 43 guesses in 10 hours.

I don’t see any easy fixes. I’m not even sure how many IPs we are seeing in different log files, which would give us an idea of the total attacking population. TODO: Guess I better produce those numbers. Not much point in blocking IPs if they never come back, nor if they aren’t seen on other servers.

Anyhow, having a cron job periodically scan the access logs for bad behaviour isn’t really going to cut it. Looks like I may need to modify weblogger to log some subset of requests to a single file that another tool(s) can monitor. fail2ban is well placed/designed to handle the immediate block… e.g. truncate that run of 200 guesses that was only in flight for 23 seconds. But we currently don’t have any method of sustaining a block on port 80. Perhaps we need to roll that out… If we added an element of persistent blocking to fail2ban that would do the trick nicely… but of course we need to figure out a way to share the info (dns zone transfer?) and speed up the updates.

Not like I have the time or desire to write such a system just now. But it would solve some headaches for us. I wonder how hard it would be to setup something like this as a sniffer… That would be more functional, as you could see bad stuff in input requests that way… instead of just the log of pages accessed.

What would we need? Seems to me the “agents” on the webservers would need to both receive and send updates to the central node. The central node would need to keep a list of all the agents listening (subscriptions). The agents need to be able to start up, send in reports of suspicious activity and get a list of blocked IP/service pairs back. They need to be able to install that list of blocks… hhmm, that implies short-term (local) blocks, and persistent (shared) blocks. I like it. Of course, I need to spend lots more time on fail2ban looking for things like that stealth threat. I _know_ those are out there in the pop world.

hhmm, I’m wondering if it is time for another syslog channel, log all the suspicious stuff there? Food for thought, time for a run.

 

wordpress brute forcing :(

Looks like a fair number of wordpress installations are being brute-forced… SUCCESSFULLY 🙁

I guess the fix is going to have to be to automate the installation of something like the Limit Login Attempts plugin … but I believe we also need a script to reset admin passwords, certainly for compromised accounts both things need to be done.

Breaking in is no big deal for system administrators with database access, but to be able to change the admin password we need to know what format wordpress stores it as… looks like wordpress can use more than one format, and a straight md5 hash is acceptable… let’s test it!

yes, it does work… but you have to be careful not to include the \n in your hash… e.g. use the -n parameter to echo (no newline).

[root@eleven /var/lib/mysql/tbrowndb]# echo -n 5fHGZX | md5sum
1a5225f15301983e3b962e76a5c2163b  –

mysql -e “update wp_users set user_pass=’1a5225f15301983e3b962e76a5c2163b’ where user_login=’admin'” tbrowndb

That works (sets the admin password to 5fHGZX) … not sure what the default $P$ prefix indicates for a format, should read the code but too busy/lazy. OK, I have written a script to encapsulate this… wp.set.adminpw

So, that leaves figuring out what changes are required to install the limit login attempts plugin… but I don’t _have_ to have that for now… just to scale things, and to fix the installer…