Usually, I don’t need to deal with the hacked WordPress sites. However, I’m not using hosted WordPress blog – instead, my blog is running on a hosting account where I have installed WordPress… to some extent, that gives me quite a bit of flexibility. But, on the other hand, when things go wrong, it may easily turn into a disaster, and that’s exactly what happened a few days ago.
My blog was hacked.
I have no idea how that happened, I just know that I had to spend 7 hours to fix it. Although, I guess if I knew enough about WordPress “internals” when I started looking into it, it would not have taken that long.
The good thing is that everything seems to be fine now (unless I missed some of the corrupted files, which is quite possible). The bad thing is that, well, it may probably happen again. And the moral of the story is that I can’t help but notice that, even though “cloud offerings” might be somewhat more expensive… it’s almost like paying for the insurance. You might be thinking it’s not worth it until one day the problem hits, and, unlike in the old days, you don’t have to tackle it personally – it’s the cloud service provider who will be dealing with it.
So, yep, this latest experience with self-hosted WordPress reminds me of how the world of on-premise Dynamics 365 is different from the Power Platform world. But, maybe, it’s a topic for another post. or, more likely, just a good analogy to mention when someone brings up the topic of relatively expensive licensing in the cloud?
Right here and right now, I just wanted to summarize what the “hackers” did.
Basically, it was extremely simple.
There is .htaccess and index.php files in the WordPress root directory.
I have no idea how the attackers managed to update “index.php” – that’s a really good question, but that seems to be how they eventually got control of the site.
Normally, index.php is less than 1 KB in size, and it just tells WordPress to load a theme.
In my case, it ended up being over 25KB, and there was some long encoded base64 string in it which would be passed to the “eval” function.
Then there is .htaccess which, among other things, is meant to define rewrite rules. It’s, actually, used by WordPress to support permalinks, for example.
Anyways, what was happening is that:
- On each page load, index.php would replace .htaccess and set .htaccess permissions so that WordPress itself would not be changing it (444). From what I understand, internally WordPress is looking at whether “write” operation is allowed, and, if not, it’s not trying to replace .htaccess
- Modified .htaccess would redirect all requests to where they are not supposed to go at all, but it would still allow direct access to a few other files in the root folder which were added by that malicious person
- One of those files was probably used as a backdoor to secure “future access”, since it seemed to allow file uploads. And you would probably have to look twice to see that the name does not make sense – it looks very similar to the normal file name, though:
There were some other unexpected files, all of them were given direct access to through the modified .htaccess.
And the funniest thing is that, most of the times, my blog was still working. Except that there was a bug in the .htaccess which locked me out of the WordPress area, and, that way, it got my attention.
But, of course, other problems had already been brewing there – now that the issue is gone, Google analytics is complaining that it can’t find some links:
That’s the result of having that hacked .htaccess / index.php – I wonder how many other non-existing links have been added to my blog this way, and how many of the real ones got lost (temporarily, I guess)
So how did it get fixed?
- What you need is to replace “index.php” with the original index.php from the same version of WordPress. In my case, I took a copy of that file from another WordPress site
- And you may want to replace .htaccess with the default WordPress .htaccess. After that, make sure to apply permalinks structure from the admin panel
- With that done, just get rid of the remaining malicious files – not sure I can name them all, but, if you save a copy of the hacked .htaccess, you would actually see a regex there from which you can reconstruct file names:
Anyways, the problem seems to be gone now, and, hopefully, it’s not coming back any time soon. And I’m thinking of the advantages of “cloud offerings”… so, going back to Power Platform