Tag: html404

This Looks Like It Might Be Another Instance of SiteLock Partnered EIG’s Apparent Security Issue

A week and half ago we discussed a situation where there looked to be at least a hacker specifically targeting websites hosted with web hosting company EIG, which does business under the brands including A Small Orange, Bluehost, FatCow, HostGator, iPage, IPOWER, JustHost and quite a few others. The more concerning possibility is that the hacker wasn’t just targeting websites hosted with EIG but taking advantage of some security issue within their systems to breach the websites. Due to their relationship with a web security company, SiteLock, they don’t seem to have an interested in investigating this type of situation (and neither does SiteLock).

That wasn’t the first time we had run across the possibility of such a situation occurring with EIG, back in July of last year we discussed another instance, but in that case we were not brought in to clean up any websites targeted, so we had a very limited ability to assess what was going on.

We have now run across yet another instance that lines up with the others.

We were contacted about a hacked website after the person handling a replacement of that website was in contact with SiteLock (due to the website being hosted with HostGator) and then they found our blog posts about SiteLock.

What they had been told by SiteLock was the same kind of stuff we hear a lot. That included that they were told that if the website was cleaned up of the “malware”, but not protected by SiteLock going forward, it would just get infected again. Because the website was for a church, the SiteLock representative said they could provide a discounted rate of $400-600 a year (which doesn’t seem to actually be a discounted rate). Instead they hired us to clean it up for a lot less than that.

What we knew before we started working on the cleanup was that the main website in the account was serving up Japanese language spam when crawled by Google and other search engines, which lead to the search results for the website to also show that. That website was running Joomla 1.5, which was EOL’d in September 2012. There was a recently set up WordPress installation, which was being prepared to replace that website, and that website was not serving that spam content to search engines.

What would seem to be the obvious security concern there would be the Joomla installation, since it is using software that hasn’t been supported in 5 and half years. We haven’t seen evidence that Joomla installations of that vintage are currently exploitable in some mass fashion, so that seemed less likely to us. There was also the possibility of an extension installed in the Joomla installation being a security concern since those would be equally out of date.

The code causing the Japanese language spam wasn’t hard to find, it was obfuscated code added to the top of the index.php file in the root directory of the Joomla installation, which is also the root directory of the website. The last modified date for that file was years ago, which probably meant the hacker had changed it to hide that they had modified the file (which is very common).

As we started more thoroughly reviewing the files to look for any other malicious code on the website, the only place we found them was in multiple files that were located in a directory for a plugin, /wp-content/plugins/html404/, in another WordPress installation on the website. That additional WordPress installation hadn’t been mentioned to us.

That plugin contained files from version 2.5.6 of the plugin Akismet as well as files with malicious code in them. Those files were named:

  • 404.php
  • idx.php
  • jembud.php
  • wso25.php
  • xccc.php

That WordPress installation was running WordPress 4.7.9, which is an outdated major version, but should be secure due to WordPress releasing security updates for older major versions. The website was using a customized version of a popular theme and only one other plugin installed, neither of those things look like a likely source of a security issue.

In looking over the WordPress accounts for that website we found that the first account, which normally be the one created when WordPress was installed was named “html404”, which considering it matched the name of plugin’s directory, seemed like it was probably changed by a hacker (likely with the password also being changed).

In the looking at the session_tokens for that user in the wp_usermeta table of the database for that WordPress installation we could see that at nearly the same time that plugin’s files were listed as last being modified on January 25 someone had logged in to that account from an IP address in Indonesia (which isn’t where the website is located).

A non malicious file in the root directory of the website connected with the code added to the index.php file was also listed as last being modified at the same time, so it looks like the breach of the WordPress installation lead to the Joomla website being modified.

Because the web host for the website, HostGator, did not have any log archiving enabled we could only see the HTTP logging from the day we were cleaning up the hack limiting what we could gleam from that. The FTP logging didn’t show any access that shouldn’t have happened.

Looking around for any other mentions of this that might allow us to give the client better information on what could allowed what had occurred to happen, we came across a thread on the website for WordPress with other people that had been impacted. That provided further confirmation of what we had been piecing together, but nothing that shed any light on the cause.

At that point the possibility that this could be another example of whatever security issue might be going on at EIG was at top of mind. Since a hacker with either direct access to the databases on the server or access to files on it, which would give access to the configuration files with database credentials in them need to access the databases, could change a WordPress username/password like this. There was no direct mention of what web hosts the websites mentioned in that thread were using, but one of the participants username pointed to the website impacted and the website was hosted with Bluehost, another EIG brand.

In the previous instances where we found an EIG connection there was a defacement involved that had showed up on the website Zone-H. That allowed us to easily check over numerous websites to see what the host were. That isn’t the case with this hack, but we did check over a number of websites we could find that were involved and what we found was they all were hosted with EIG brands. Here are the IP addresses along with the EIG brands of websites we found reference to being impacted:

While the sample set we have is smaller in the previous instances the chances that all of the website we checked would all happen to be at one hosting company is not what you would expect if the hacking was caused by something unrelated to the web host. At best it looks like we have now run across multiple hackers that look like they are only targeting this one company, but what seems to be a reasonable possibility is that there is a security issue in EIG systems that is allow hackers to exploit them.

Several of those are from the same IP address, which would likely mean they are on the same server.

SiteLock’s Idea of Protection Doesn’t Seem to Involve Real Protection

Considering that EIG brands heavily push people to hire SiteLock to clean up websites, it seem incredibly hard to believe that SiteLock could have missed what we have picked by just dealing with a couple of websites, if they were properly dealing with hacked websites. But from what we know they don’t usually properly clean up hacked websites. Instead of doing proper cleanups they sell people on services that claim to protect websites, as what was attempted to be sold in this instance, that don’t even attempt to do that.

If you are not determining how websites are being hacked, it would be difficult to be able to protect them. If there is an issue with EIG’s system, it would unlikely that such a service could protect against it, so spotting that type of situation would be really important.

SiteLock’s lack of interest in true protection is even worse in the light of the fact that SiteLock has “partnered” with a web host that seems at best uninterested that hackers are specifically targeting their customers or worse, their customers are getting hacked due to a security issue in the web host’s systems. But it gets even worse, when you know that while the relationship between EIG and SiteLock is promoted as partnership, the reality is that the two companies are very closely connected then they let on publicly. The majority owners of SiteLock also are the CEO and board member of EIG, which neither side mentions publicly. So you have the owners of a security company that seems to be uninterested in security of websites it is supposed to be protecting also looking to be leaving websites they host insecure. On top of that both sides would profit from this insecurity as EIG disclosed that they get 55% of revenue for SiteLock services sold through their partnership, so both companies have a financial incentive to not find and fix something like this as long as their customers doesn’t become aware of what is going on and leave in mass. That seems like a good argument for keeping security companies and web hosts at arm’s length (maybe not surprisingly with the other instance of a security company closely tied with a web host the security company doesn’t seem to be interested in security either).

Wordfence Has Missed This As Well

SiteLock isn’t the only security company that seems to not be on the ball here. In the previously mentioned thread on the WordPress website one of the participants mentioned they were going to have the security company Wordfence “perform a comprehensive security review and if necessary, final clean-up” after being impacted by this. In the follow up there is no mention at all of Wordfence having made any attempt to determine how this occurred, just that “I am happy to report that the Wordfence security analyst found no evidence of malware on the website.”. Considering that trying to determine how a website was hacked is one of three basic parts of a cleanup, it seems a bit odd that there wouldn’t be a mention of Wordfence not figuring out the source if Wordfence had done things right and mentioned that they were unable to determine the source of the hack

The follow up response to that was from a Wordfence employee, who instead of being concerned about the source of hack being a mystery, just promotes a post on the Wordfence website that wouldn’t have any impact on resolving the underlying cause of these hacks. So it would seem they are unconcerned about this as well.