A lot of our business cleaning up hacked websites involves people hiring us to clean up their website after someone else had been hired to do that but failed to even attempt to do things properly, so we are not surprised at most of what we see done instead of doing that, but there is the occasional exception.
We were recently brought in to clean up a website after a web host was supposed to have handled that, but they didn’t seem to have made much attempt at that. What we found was that they had failed at doing some basic things that should have been easier parts of the cleanup. That included failing to remove the malicious JavaScript code that they knew a web based scanner had (correctly) identified was on the website, despite the being added to files on the website in a non-obfuscated way, so a simple search of the files would have found it. They also had failed to enable the archiving of logging of requests to the website, which would have been done through cPanel and would have made would have made it easier to spot the malicious file that was allowing a hacker to continue to access the website.
What stood out was something they claimed they had done:
Another thing I did to help prevent this from happening again in the future, I created a two-user system for your WordPress admin. What this does is it assigns a front-end user that has just enough permissions for the site to display, but not enough for people visiting the site to make changes, without logging in. It also has a back-end user that applies whenever someone logs in, that has all permissions.
Many of those that use WordPress that are not even familiar with security would probably find that odd sounding. You normally don’t have to be logged in to WordPress to view the website and when not logged in, not surprisingly, you can’t make changes to the website, normally. This website was a run of the mill WordPress website, so that was all true for it.
When we went to see what had actually been done we found that there was only one WordPress user, so either they were not referring to a WordPress user or they hadn’t done what they said. One possible explanation was that they were referring to another database user with only read access, which would not really match what they described and seem like a bad idea as WordPress isn’t designed for doing something like that.
In checking into this we found they were referring to a database user and they had created a bit of a mess.
While it looks like they created a database user that was only supposed to be read only as the two database user name were identical save for a “ro” added to the end of one, that wasn’t actually what they had created. The read only user has the following privileges DELETE, INSERT, SELECT, UPDATE. As you might be able to guess from some of those names, that user doesn’t just have the ability to read things, but make significant changes.
It turns out though they didn’t set up a dual user situation, so only that user was being used. That was a problem since privileges the user was missing were needed by WordPress in the course doing normal functioning. In the error logging we could see this had caused actions trying to be taken by a security plugin to not work.
That seems like a good reason to be wary of having a web host clean up a hacked website, but tomorrow we are going to be discussing another recent instance where a prominent security company failed to clean up a website the first time, then on the second go around managed to break the website and then break it some more.