Like probably the vast majority of people who are running WordPress for more than a few months, my site is frequently being hit with automated attacks. I’ve only recently noticed this in my logs so I thought it would be interesting to have a closer look.<\/p>\n
Around the turn of the year, for reasons I can’t recall, I happened to look at the raw access logs and noticed a lot of references to ‘xmlrpc.php’, which look like this:<\/p>\n
142.4.4.190 - - [31\/Jan\/2016:18:13:42 +0000] \"POST \/blog\/xmlrpc.php HTTP\/1.0\" 200 58043 \"-\" \"-\"\r\n<\/pre>\nThis is a real log file entry, and is a classic example of an XMLRPC bruteforce amplification attack: someone has posted 58k at this page, to try and bruteforce the admin password. I disabled the mechanism – and just verified that it’s working this morning [two months later :)], as the 200 server response is a bit more polite than I would have expected.<\/p>\n
At the same time I installed [yet another] plugin, which rate limits failed admin password authentication attempts. It started triggering last week with repeated admin authentication failures from a machine\u00a0in Hanoi. In my latest access log file [31st January to about half an hour ago], I have 1500 POST attempts which look like this:<\/p>\n
123.30.140.199 - - [26\/Feb\/2016:13:37:47 +0000] \"POST \/blog\/wp-login.php HTTP\/1.0\" 200 3766 \"-\" \"-\"\r\n<\/pre>\nI’ve not paid much attention to log formats in a long time so I had to google what those final two hyphens are:\u00a0a blank referer [note<\/a> to my wife on the spelling :)] and user agent<\/a> field respectively. The blank user agent is indicative of some sort of automated attack and, by virtue of the fact that the person who’s running it hasn’t even bothered to make it look like a real browser, one that isn’t particularly sophisticated.<\/p>\n
The logging pattern suggests what you’d expect: someone has harvested a set of servers that are running WordPress [how? by virtue of having the common pages that WordPress hosts. So a 200 in response to a GET for a ~\/wp-login.php page, for instance], and is stepping through them.<\/p>\n
This is another indicator of the lack of sophistication:<\/p>\n
123.30.140.199 - - [26\/Feb\/2016:16:41:35 +0000] \"POST \/blog\/wp-login.php HTTP\/1.0\" 200 1643 \"-\" \"-\"\r\n123.30.140.199 - - [26\/Feb\/2016:16:41:37 +0000] \"POST \/blog\/wp-login.php HTTP\/1.0\" 200 1643 \"-\" \"-\"\r\n123.30.140.199 - - [26\/Feb\/2016:16:41:38 +0000] \"POST \/blog\/wp-login.php HTTP\/1.0\" 200 1643 \"-\" \"-\"\r\n123.30.140.199 - - [26\/Feb\/2016:16:41:44 +0000] \"POST \/blog\/wp-login.php HTTP\/1.0\" 200 1643 \"-\" \"-\"\r\n123.30.140.199 - - [26\/Feb\/2016:16:41:46 +0000] \"POST \/blog\/wp-login.php HTTP\/1.0\" 200 1643 \"-\" \"-\"\r\n123.30.140.199 - - [26\/Feb\/2016:16:41:58 +0000] \"POST \/blog\/wp-login.php HTTP\/1.0\" 200 1643 \"-\" \"-\"\r\n123.30.140.199 - - [26\/Feb\/2016:16:41:59 +0000] \"POST \/blog\/wp-login.php HTTP\/1.0\" 200 1643 \"-\" \"-\"\r\n123.30.140.199 - - [26\/Feb\/2016:16:42:05 +0000] \"POST \/blog\/wp-login.php HTTP\/1.0\" 200 1643 \"-\" \"-\"\r\n123.30.140.199 - - [26\/Feb\/2016:16:42:06 +0000] \"POST \/blog\/wp-login.php HTTP\/1.0\" 200 1643 \"-\" \"-\"\r\n123.30.140.199 - - [26\/Feb\/2016:16:42:13 +0000] \"POST \/blog\/wp-login.php HTTP\/1.0\" 200 1643 \"-\" \"-\"\r\n123.30.140.199 - - [26\/Feb\/2016:16:42:14 +0000] \"POST \/blog\/wp-login.php HTTP\/1.0\" 403 9 \"-\" \"-\"\r\n123.30.140.199 - - [26\/Feb\/2016:16:42:20 +0000] \"POST \/blog\/wp-login.php HTTP\/1.0\" 403 9 \"-\" \"-\"\r\n123.30.140.199 - - [26\/Feb\/2016:16:42:21 +0000] \"POST \/blog\/wp-login.php HTTP\/1.0\" 403 9 \"-\" \"-\"\r\n123.30.140.199 - - [26\/Feb\/2016:16:42:22 +0000] \"POST \/blog\/wp-login.php HTTP\/1.0\" 403 9 \"-\" \"-\"\r\n123.30.140.199 - - [26\/Feb\/2016:16:42:23 +0000] \"POST \/blog\/wp-login.php HTTP\/1.0\" 403 9 \"-\" \"-\"\r\n<\/pre>\nWhat’s happening here is that some software I’m running is blocking the user’s IP address after 10 authentication failures, shown by the 403, which is the server returning a ‘Forbidden’. What I’ve deleted from the log extract above is \u00a0that there are a total of 25 Forbidden responses by the server in a row: the attack software isn’t checking the server response codes, which is a waste of resource on their part.<\/p>\n
I’ve had a bit of a trawl through my logs and am seeing similar, albeit less determined attacks like this, coming from all sorts of far flung\u00a0places:<\/p>\n
62.109.19.98 - - [13\/Feb\/2016:07:46:48 +0000] \"POST \/blog\/xmlrpc.php HTTP\/1.0\" 200 58043 \"-\" \"-\"\r\n<\/pre>\nThat’s another XMLRPC bruteforce amplification attack, from Russia. A geolocation site reckons this one…<\/p>\n
204.232.224.64 - - [12\/Feb\/2016:07:12:33 +0000] \"POST \/blog\/xmlrpc.php HTTP\/1.0\" 200 58043 \"-\" \"-\"\r\n<\/pre>\n…is in San Antonio, Texas. Interesting that the byte sizes being posted through are identical: 58,043. Again, that’s indicative of the same off the shelf attack software running with a pre-canned payload. Let’s do one more of these:<\/p>\n
1.83.251.239 - - [11\/Feb\/2016:02:19:14 +0000] \"POST \/blog\/xmlrpc.php HTTP\/1.1\" 200 45387 \"-\" \"Mozilla\/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident\/5.0)\"\r\n<\/pre>\nI can honestly say that since I first started messing around on\u00a0the internet in 1992, I’ve never seen an IP address that starts with 1. The geolocation service dutifully informs me that the machine that sent this parcel of good intention is located in Xi’an in China. At least they’ve spiced things up a bit with a different sized payload.<\/p>\n
So here’s a thing: I have a couple of blog posts on this site about a holiday we had in Vietnam. I blogged about a holiday to China that included a trip to Xi’an. I’ve also got a posting about a work trip to Russia. So… Russia and China are massive, populous countries. But Xi’an, in China? That looks like a pattern to me. I wonder if the bundle of joy – malware, whatever it is – that would be deposited on my site if it were to be compromised is tailored or localised in some way or other, based on the occurrences of those locations.<\/p>\n
<\/p>\n
As per the title, and the obvious lack of finesse, I know that my server is just one on what’s probably a very long list of candidates that these automated attacks are hitting.\u00a0WordPress has had something of a chequered history from a security point of view: it’s a natural target. While I’ve done the easy stuff to shore it up – like blocking a blank user agent – the options are relatively limited. That’s fine, given the fairly low-rent nature of the stuff being thrown at it, but I’d really prefer not to be distributing malware to people. Migrating off WordPress looks like it would be a pain so if the ancillary approaches start to look like they’re too much trouble I’ll just delete the site.<\/p>\n","protected":false},"excerpt":{"rendered":"
Like probably the vast majority of people who are running WordPress for more than a few months, my site is frequently being hit with automated attacks. I’ve only recently noticed this in my logs so I thought it would be … Continue reading