In the complaints about the web security company SiteLock we have seen, one of the things that comes up frequently is the widely variable and often times excessive prices for their services. In some cases the pricing would be within reason if you were getting a high quality service, but as we found while helping to fix a website after SiteLock did a malware removal on it few days ago, you get the opposite of that from them.
This incident involved one of SiteLock’s partner web host, though not one the ones run by the owners of SiteLock. Instead it is GoDaddy, for which we found a couple of security issues on their end while looking into this as well.
What happened in this cases is that SiteLock through GoDaddy was hired to clean up malware on the website. Afterwards though the website was screwed up, with the styling gone and shortcodes showing up on the pages (instead of being processed). GoDaddy told the website’s owner that they would need to have someone update WordPress and re-install the theme they used.
None of this made a whole lot of sense. After removing malware or doing some other cleanup the website should appear as it did before. The theme shouldn’t be missing, unless it had been completely replaced with malicious code (which we have never seen happen). Also a part of a proper cleanup is making the website secure as possible, which would, in part ,involve updating the software on the website.
When we got in to the WordPress admin area to look over things we found that theme actually was still there, but wasn’t activated. The only reason we could think for changing to another theme would be to check if the theme being used was causing the malware to be served up, but after that checking was finished it should be reactivated.
We also found that all of the plugins were deactivated, the same explanation as the theme might explain them being deactivated. But again they should have been reactivated if that was the case. This was more problematic to deal with since we didn’t know which, if any, of the plugins were not active before the cleanup and did not need to be re-activated.
Not only did WordPress still need to be updated, but so did the plugins and themes.
Once we got a handle of those things we were able to bring the website back to working order, but further looking showed that items added by the hacker still existed (and would have allowed them continued wide access to the website) and the vulnerability that could have allowed the hacker access to begin with still existed on the website, so the hacker could have easily gotten back in.
Malicious Administrators and a Vulnerable Plugin
When cleaning up a hacked WordPress website one of thing you want to check for is the existence of users that should not exists, with an emphasis on users with Administrator role, since they have wide ranging access. Sometimes those added accounts are rather obvious, in the case of this website a couple had the email adress “backup@wordpress.org”. While seemly intended to look innocuous, there shouldn’t be any account with email addresses from wordpress.org on a website. Either SiteLock did not spot those or didn’t even do any check for that.
Looking at the details of the users in the database would tell you something more about this. In the following screenshot you can see that for the two account with the “backup@wordpress.org” and one other have the user_registered field not filled in (the others listed there have dates from before the website existed and before the original account on the website was created):
That indicates that the accounts were not created through the normal process in WordPress. One other way to do that is with direct access to the database.
That brings us to another thing that SiteLock missed, one the installed plugins, Revolution Slider, had an arbitrary file viewing vulnerability in the version of the plugin installed (you can check if a website is using a vulnerable version of that and if other plugins have vulnerabilities hackers are targeting using our Plugin Vulnerabilities plugin). Hackers frequently target that type of vulnerability to try to view the contents of WordPress configuration file, wp-config.php. That file contains database credentials for the website, so accessing that could allow a hacker access to the database, which they could then use to add new users.
GoDaddy’s Security Failings
We then went to check to see if the vulnerability was in fact exploitable on the website and we found that connection was dropping when we made the request to exploit it, which looked to be GoDaddy blocking the request. Unfortunately their protection is incredibly easy to evade.
The original request we made was the following, which was stopped:
/wp-admin/admin-ajax.php?action=revslider_show_image&img=../wp-config.php
This request was not stopped:
/wp-admin/admin-ajax.php?action=revslider_show_image&img=..%2Fwp-config.php
The only change was that the “/” right before “wp-config.php” has been encoded, changing it to “%2”.
The fragility of such protection seems to pretty common, as earlier this week we found that two WordPress security plugins protection against another vulnerability could bypassed by simply adding and “\” in the right location (the 9 other WordPress security plugins we tested provided no protection).
Remote Database Access
Even if a hacker gets the database credentials by exploiting an arbitrary file viewing vulnerability they still need some method to access the database. In the case of the database for the website remote access is permitted, which allows someone to connect to the database from outside of GoDaddy’s systems. That type of access makes it really easy for a hacker, so it should be disabled by default.
In looking how we could disable remote access to the database, we found that based on their documentation it shouldn’t have even been enabled. The documentation says that you need to enable direct access when creating a database for to connect remotely:
Connecting remotely to a database lets you manage it using tools like MySQL Query Browser,MySQL Workbench, or Microsoft SQL Server Management Studio Express.
If you want to connect remotely to a database, you must enable Direct Database Access when setting it up1 — you cannot enable it later.
But the database in question is listed as not allowing direct access:
So something isn’t right.
If we didn’t know what SiteLock was up to at this point we would be asking why they had not noticed those problems with the partner GoDaddy’s security and gotten them to fix them, but knowing what they are doing it isn’t surprising they wouldn’t have done that. If anything getting their partners to improve their security would mean less money for them and less money for the partners as well.
If you want a hacked WordPress website cleaned up properly, we are always available to help.
A Better Alternative to SiteLock For Cleaning Up a Hacked Website
If your web host is pushing you to hire SiteLock to clean up a hacked website, we provide a better alternative, where we actually properly clean up the website.
Could you explain the remote database section of your article.
You say remote database access should not be enabled.
Then you show godaddy also says that on documentation.
Then on the picture you show the database direct access is not enabled.
There is not contradiction on these statements.
So may you point the issue here
The issue is that despite direct access not being enabled, you still actually could connect directly.
Godaddy sucks. I already activated sitelock in all cpanel and they told me my vps server was stuck because of malware. Really Bad Service.
SiteLock deleted all accounts not in use. It’s a newspaper site. All content from reporters no longer on staff was deleted from our site. Fortunately we had backed up the site; however, some content has never been recovered. We are no longer with GoDaddy and Sitelock.