brute force attack WordPress, XMLRPC brute force, turning off XML-PRC

Case Studies: XML-RPC Brute Force Attack and Hacked Website


No website is 100% hack-proof. Nothing on the internet is 100% hack-proof. But that doesn’t mean you should give up and accept the inevitable. There are safety measures you can take to help prevent your site from becoming an unanticipated business expense. It’s much easier, and far less expensive, to keep your site maintained and as safe as possible than it is to clean up and/or replace a hacked website.

Unfortunately, a good block of my time this entire month has been spent on cleaning up hacked websites. In one case, the site owner had no idea his site had been hacked until he tried to log in. On another site, it was the hosting provider that notified their client by email that they were taking their site offline due to malware. Typically, when a hosting provider takes your site offline it means that your site has been infected long enough for the hackers to do serious damage to your site as well as to other sites on the same server, and also to the innocent bystanders visiting your site.

Two examples of a half dozen different types of hacked websites I’ve seen this month:

CASE 1:
PROBLEM: The hacker set up a username and password for himself (as the admin) and deleted the website owner’s username and password. The site owner had absolutely no idea his site had been completely taken over by the hacker. Everything looked fine when he looked at his site. It wasn’t until he tried to log into the site that he discovered he couldn’t even get to the login screen. Once I got into the site I saw something I’ve never seen before; the entire WordPress dashboard had been replaced by massive quantities of code, mostly directing visitors to the website to the hacker’s various websites.

RESOLVED: In this particular case the server needed to be wiped clean and the site restored.

This wouldn’t have been a huge problem if he had a clean backup copy of his website that was not stored on the server, and if he had any idea as to when the site was hacked. He had neither, and his hosting provider did not have a backup copy. He hadn’t logged into his site in about a year, which also told me that he had not been keeping up with any/all security upgrades. Even if his web host had a backup, there was no way he would know how far back in the archives he needed to go in order to restore a clean copy.

Not all hosting providers will have backup copies of their customer’s websites, especially those on a shared server. It’s not their responsibility to keep backup copies. When they do make backups, it’s for THEIR convenience; not yours. Furthermore, if they do have a backup copy, they do not guarantee that restoring the site from their backup will work properly and that your site will look and function the way it did before something went wrong.

TIP: Check your site frequently and do not depend on your hosting company to keep backup copies of your website.

CASE 2:
PROBLEM: Website was under heavy Brute Force attack; XML-RPC DDoS and also the garden variety type of hack attempt.

RESOLVED: In this case, I had to reach out to the web hosting company’s tech support as this site is usings VPS hosting, as opposed to shared hosting. I requested that they insert a RewriteRule in the .htaccess file and also temporarily turn off  the xmlrpc.php file. It took them a couple of days to get this task done, which isn’t bad considering that one (or more) of their servers was also under DDoS attack so it was All Hands on Deck at this hosting provider.

Is there a downside to turning off the XML-RPC? The only one that I’m aware of is that by doing so, you will not be able to use mobile apps or remote connections to publish content on your website. However, not everyone needs this ability enabled. If you do decide to turn this off and you notice that some of your plugins no longer work, you will need to turn it back on again.

Turning XML-RPC on and off like a water faucet can be done by using a plugin such as “Manage XML-RPC,” or “Disable XML-RPC,” but I prefer not to use any more plugins than absolutely necessary. If you would rather not add yet another plugin to your site, you can add the following order deny,allow rule to your .htaccess file. You can also harden this further by including a deny from all along with the allow from 111.111.111.111 (insert your IP address).


Order deny,allow or the order allow,deny rules can also be — and should also be — used to protect other files on your site, such as protecting the most important WordPress core file: wp-config.php.

Image

As an added measure of security, and while I waited for tech support to get back to me, I installed a plugin with a country blocking feature and proceeded to block every country on the planet!

As you see in the below snapshot of the activity screen, the above steps completely stopped the brute force attempts.

WordPress brute force attack, XML-RPC attack, protecting XMLRPC

Brief Explanation of Complex Attacks and Brute Force Attacks

A complex attack is when a visitor makes a request to your site that is specifically crafted to exploit your site or find a vulnerability they can later exploit. Not keeping up with the required upgrades makes it easy for hackers to find vulnerabilities.

Brute force attacks are username/password-guessing attempts. Oddly enough, I still see people using the default “admin” username that gets set up during the initial WordPress installation when you don’t change it as you’re doing the installation. If you forget to change the dealt username be sure to IMMEDIATELY after the install. Also remember to use strong passwords, and not include words that can be found in the dictionary.

TIP: Do Not use the same username and passwords for multiple accounts. A POSSIBLE explanation for this massive increase in brute force attacks may be linked to a database of hacked credentials. This database contained over 1.4 BILLION username/password pairs.

If I’m maintaining your website for you, I run frequent (depending on which maintenance plan you’re on) security and malware scans using two different sources. If I find a problem, I resolve it — often times without bothering you with details about how the sausage was made.

On the topic of cleaning up hacked sites and removing malware in general: Due to time constraints, paired with the huge spike in hack attempts, I’m now referring the more complicated hacks and malware removal to Sucuri. Personally speaking, I would much rather be designing and maintaining sites than cleaning up hacked sites. Sucuri does a great job removing malware from compromised sites if you do get attacked. They also sell an automated service that monitors your site. I’ll continue to clean up and/or restore sites that have been hacked by amateurs. In other words, the “your site has OBVIOUSLY been hacked!” problems that don’t require hours or days to resolve.