Vulnerability in Older Versions of MODX Being Exploited

Quite often with hacked websites outdated software is pointed to as the source of the hack. That is usually a claim that is made without any knowledge if the claim is actually true. Many security companies that market themselves as having unique expertise in dealing with hacked websites don’t even attempt to determine how websites are hacked, despite that being one of the three key components of a proper cleanup, so they would have no idea what the cause might be. Often times these companies don’t seem to even have a cursory knowledge of what they are talking about either, as an example, one well known security company, Sucuri, once told people to update software despite it being well known that the vulnerability being exploited in the software was in the then current version of the software (that kind of thing somehow never stopped journalists from repeating misleading and false claims made by that company or people claiming that they are a reputable company).

From what we have seen those baseless claims are usually easy to spot as there usually isn’t even a specific vulnerability that is pointed to as being the cause of the hack, which should be something known if someone has actually done the work to determine the source of the hack and determined it was outdated software.

As example of finding out that outdated software was actually the cause of a hack, we were recently brought in to clean up a hacked MODX website. MODX websites have not been a common type of website needing cleanups from us recently, so the software in use on the website was of some note right away.

In trying to determine how a website was hacked the logging is probably the most important resource, but the files can often tell you a lot, and both of them can work together to speed up the process. In the case of this website there was an obviously malicious file named dbs.php in the root directory of the website. That file had also had a number of POST requests made to it, which are requests that contain additional data and of which most requests sent by hackers are of that type, sent to it shortly before we started the cleanup. Looking back at the logging to where that file was first requested we found it in a set of requests sent by an IP address from Ukraine:

134.249.50.5 – – [19/Jul/2018:19:55:23 -0400] “GET / HTTP/1.1” 403 134 “-” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.132 Safari/537.36”
134.249.50.5 – – [19/Jul/2018:19:55:23 -0400] “POST /connectors/system/phpthumb.php HTTP/1.1” 403 134 “-” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.132 Safari/537.36”
134.249.50.5 – – [19/Jul/2018:19:55:24 -0400] “GET /dbs.php HTTP/1.1” 403 134 “-” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.132 Safari/537.36”

The first request there is for the homepage of the website. The second one sends a POST request to a file /connectors/system/phpthumb.php. Finally there is a request for the dbs.php file. Based on that, it would appear that the file phpthumb.php would be the vector for adding the dbs.php file.

In reviewing the file phpthumb.php there wasn’t anything in the file itself that looked like a vulnerability that would permit uploading a file as that series of requests would indicate was what the hacker would be attempting to do. In fact the file only contained four lines of code that just called on code in other files:

define('MODX_CONNECTOR_INCLUDED', 1);
require_once dirname(dirname(__FILE__)).'/index.php';
$_SERVER['HTTP_MODAUTH'] = $modx->user->getUserToken($modx->context->get('key'));
$modx->request->handleRequest(array('location' => 'system','action' => 'phpthumb'));

Instead of digging through more code at that point we instead did a web search for “/connectors/system/phpthumb.php” and though that we got pointed to the issue. There was a post of the details of a vulnerability that matched what we had seen that was published on July 13 and what seems more important, code for exploiting the vulnerability that was released on July 18. On this website the first attempt to exploit it was one July 19, so it would seem the code to exploit it was quickly utilized by hackers.

That vulnerability had been fixed in version 2.6.5 of MODX, which was released on July 11, and the developers provided clear notice of the need to update due to security fixed in it. Writing in the release announcement

Today we released MODX Revolution 2.6.5. It contains fixes for two critical security vulnerabilities affecting all versions at or prior to 2.6.4. Upgrading to 2.6.5 should be considered mandatory.

and

Upgrading is Critical

Revolution 2.6.5 contains critical security enhancements, you should upgrade to 2.6.5 now. See below for more info.

We cannot stress the importance of diligently upgrading to the latest version of MODX enough. While no software is 100% secure, powering your site with the most current version usually helps protect you from hackers that rely on exploiting outdated software. If you’re not sure what version of MODX Revolution you’re running, log into your website Manager. If the version number doesn’t appear in the top left-hand corner of the Manager, go to Manage>Reports>System Info.

The two vulnerabilities refer to the ability to upload files and to remove files/directories. From the post with the details of the vulnerability it sounds like in version 2.5.1 to 2.6.4 the ability to exploit the file upload vulnerability would be more restricted than was the case with the website were dealing, which was running 2.4.1.

Cleaning Up After This Hack

On this website the hacker had done quite a number on it. The .htaccess file in the root directory had been removed, leading to all the pages other than the homepage to no longer being functional. That seems to have been done to remove any restriction in the .htaccess file that would have blocked the hacker from sending requests to the malicious files they were uploading.  When trying to go to the admin area you would be redirected to another website due to the content of all of the JavaScript files on the website being replaced with malicious code.

The best option to clean up after this would be restore a clean back up from before the hack (making sure that all of the existing files are removed during the restoration). Seeing as the vulnerability wasn’t disclosed until July 13, a backup from before then would be a good option. You might be able to get way with one from before July 18 as well. A review of the logging by someone familiar with all of this would likely be able to confirm when the hacker hacked the website.

From what we could see from that website, it would appear that there are likely multiple hackers exploiting this vulnerability and doing different things, so it wouldn’t be possible to provide general instruction on what to remove from the website to clean up if there isn’t a backup available (though based on past experience that won’t necessarily stop someone from claiming to provide that and unintentionally or intentionally leading people astray).

If you are looking for a professional cleanup from this or any other hack of a MODX website we provide a service for that. We can also upgrade MODX for you.

Data on Previous Logins Stored in Database Can Help Determine How WordPress Websites Were Hacked

While trying to determine how websites are hacked is one of the three important components of a proper hack cleanup, what have seen is that many security companies fail to even attempt to do that. There are a number of possible reasons why that is, including people doing work they don’t have the necessary skills to handle (which seems to be a general issue when it comes to web development) and security companies realizing they can get away with cutting corners even if produces a bad result of their customers. Another possibility, though one that would assume that these companies had ever attempted to try to actually do things properly, is that often important evidence is no longer available once you are bought in to clean things up and therefore your ability to say with certainty what happened will be limited.

One of the most important items to have access to determine how the website was hacked is logging of requests for the website. In some cases though there is only logging available for requests made to the website from within the last 24 hours, while the hacker may have first gained access days, weeks, months, or even years before that.

Depending on the software being used on a website there may be separate logging made by it that is still available even if the other logging is no longer available. For example, Drupal logs recent events including logins and provides the username and IP address that was used to log in. That is stored in its database and then viewable through the admin interface of the software.

For WordPress websites there are plugins that provide similar capability to Drupal’s built in logging, but one of those isn’t likely to have been installed on a hacked website before it was hacked. But it turns out there is a more limited logging of logins that is stored in the database. That has been helpful to us as it has allowed us to be able to provide better information on what has happened with hacked WordPress websites we have been hired to clean up, so we thought it would be worthwhile sharing information on that, using a website were recently cleaning up as an example.

With WordPress, data on user accounts is stored in two tables in the database. The first _users includes the basic details on the accounts, like the username and when the account was created. That info looks like this when viewed in the phpMyAdmin database administration tool:

Additional user data created by WordPress and plugins is stored in the _usermeta table. One of those is the session_tokens, which is data to keep track of logins. An entry of that looks like this in phpMyAdmin:

The user_id value in that is the equivalent of the ID value in the _users table. So that entry would relate to the user “admin” shown before.

The full value of meta_value entry there is:

a:1:{s:64:"[redacted]";a:4:{s:10:"expiration";i:1528715599;s:2:"ip";s:14:"139.228.121.62";s:2:"ua";s:77:"Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:50.0) Gecko/20100101 Firefox/D47D";s:5:"login";i:1528542799;}}

For the purposes of trying to get better understanding of a hack, two pieces of that are usually of importance.

The first is the listing of the IP address that the login came from. Which looks like this  ‘”ip”;s:14:”139.228.121.62″‘ in our example. The IP address there is from Indonesia, which isn’t where anyone should have been logging in to this website should be coming from.

The second is the listing of when the login occurred.  Which looks like this  ‘”login”;i:1528542799’ in our example. The time value there is in Unix time, which can be converted to normal date and time format using a tool this one.

With those two things you can gather more information on what accounts where recently logged in to and from where. That is particularly useful in confirming that a hacker had access to admin area of WordPress and then you can use data from the _user to get a better idea of how they might have gained access.

With that website we could see that a hacker was able to log in to a legitimate WordPress admin account and also had logged in to another account that was created after the hacking had started.

Just Because SiteLock Is Trying To Con You Doesn’t Mean Your Website Hasn’t Been Hacked

In interacting with people about hacked websites one of the things that comes up frequently is people conflating security companies trying to take advantage of them with a belief that their websites haven’t really been hacked. A lot of the blame for this resides with the security companies that are trying to take advantage of people (and look to be very successful at it) and others that help enable that, which includes their business partners and government entities that don’t take any action against them. But some of the blame has to be placed on customers of these services that seem to take a completely uncritical view of these services, as among other things, their funding of these companies allows the companies to expand and take advantage of more people.

As an example of that, we had someone contact us recently after they ran across a post we had written how the web host Bluehost was continuing to try to sell SiteLock services based on claims that were made in phishing emails meant to look like they came Bluehost support. The situation this person had was very different than that.

They had been contacted by a company informing them that their website was being used for phishing. Their web host, Bluehost, which is a SiteLock partner, had suspended their account for the same issue. They said they were “shocked” because they had SiteLock on the account and they thought that with that the website wouldn’t have been able to be hacked.

As company that deals in the field we obviously have a very different view of things, but it still is hard to understand a view like that when you consider that SiteLock and every other similar company we have run across don’t provide evidence that their services are effective at protecting websites. To us that seems like a baseline before purchasing any service like that, but clearly it isn’t.

The next part of the story is something that we have heard plenty of times before, but it still doesn’t make much sense to us. That being that they were then told they would need a higher level of SiteLock service to protect against the issue from happening again. To us that raises what seem to be some obvious questions, like why would SiteLock by their own admission be selling security services that don’t actually provide security. Another one would be why would at that point people still not expect some evidence to presented as to the effectiveness of the services considering SiteLock have just admitted that they are selling services that don’t actually work.

When we had responded explaining about that lack of evidence that SiteLock services are effective (along with plenty of evidence to the contrary that we have run across) and that SiteLock’s own marketing indicates that they are not even attempting to provide real security the response from the person was not concern with SiteLock’s practices, but that the whole situation seemed suspicious. We asked about the evidence presented that the website had been using for phishing, but the person seemed uninterested in actually checking over things. Based on past experience our guess is that the website was actually hacked in this case.

Dealing With a Possibly Hacked Website

While in this case we guess the website had actually been hacked, we have run into plenty of instances where SiteLock and their web hosting partners are falsely claiming that websites have been hacked. So what we recommend you do in that situation is get a second opinion on their claim. We are always happy to provide that for free and would hope that other reputable security companies (to the extent that there are any) would do the same.

If the website is hacked what you want done is to have it properly cleaned up, which involves cleaning up the hack, securing the website (which usually mainly involves getting the software up to date), and trying to determine how the website was hacked and fix that. If a service doesn’t do those things (as is true of SiteLock’s main services) then you stand a decent chance of having continuing issues. After things have been cleaned, instead of paying for a security service that won’t protect your website, you should make sure to do the basics to keep your website secure from most issues.

That SquareSpace Websites Can Be Hacked Seems Like It Should Have Been the Focus of This Story

We don’t think too highly of the current state of security journalism, so we were not surprised to see a journalist covering a situation where what seems to be the significant and newsworthy element was not the focus of their article.

Today, Ars Technica has a story headlined “Thousands of hacked websites are infecting visitors with malware“. That doesn’t seem all that newsworthy. The sub-headline hints at something possibly newsworthy, “Unusually advanced campaign infects people visiting a variety of poorly secured sites.” Nothing in the article though seems to back that up; here is part of what that seems to refer to:

To escape detection, the attackers fingerprint potential targets to ensure, among other things, that the fake update notifications are served to a single IP address no more than once. Another testament to the attackers’ resourcefulness: the update templates are hosted on hacked websites, while the carefully selected targets who fall for the scam download a malicious JavaScript file from DropBox. The JavaScript further checks potential marks for virtual machines and sandboxes before delivering its final payload. The resulting executable file is signed by an operating-system-trusted digital certificate that further gives the fake notifications the appearance of legitimacy.

To us that sounds like some rather common stuff.

One of These is Not Like the Others

Another part of the story did stand out to us though:

The campaign, which has been running for at least four months, is able to compromise websites running a variety of content management systems, including WordPress, Joomla, and SquareSpace.

Lumping SquareSpace in with WordPress and Joomla seems rather odd since SquareSpace is hosted solution and the other two are software that people can install on any hosting. There is certainly a belief that SquareSpace is secure in a way that those solutions are not. For example, when doing a search on Twitter for “squarespace hacked” here are some of the top results:

https://twitter.com/mechaghost/status/979373780458876930

https://twitter.com/DesertDwellerD/status/950095157411500032

https://twitter.com/HeshamMegid/status/941650745606230016

https://twitter.com/pepironalds/status/889314095152807936

How Would a SquareSpace Website Get Hacked?

Considering how often we have seen false information being reported by security journalists, the claim that SquareSpace websites were hacked wasn’t necessarily true, so we went to look closer into that. An explanation from a SquareSpace customer as how their website was hacked, apparently as part of the campaign discussed in the Ars Technica article, is as follows:

Customer notified us that our site may be hacked. Sure enough I went to it and noticed it basically redirected me to a full page “your version of chrome needs updating” which looked super fake, and then Norton caught a download saying Chrome_67.9.17.js will harm your computer, do you want it keep it anyways.

So i login to the admin panel and in the GIT HISTORY it shows that one of my users which has never even logged in before, has sent an upload: site-bundle.js last week, along with some other big list of files

How do I go about doing anything about this? I’m not used to squarespace. In the old days I’d just login to my FTP and start navigating to the files in question. But I have no clue with this stuff.

It sounds like someone’s login credentials were compromised. That is something that is platform independent, which seems like a good reminder that the focus on the software used on hacked websites can be misplaced since websites can be hacked for a variety of reason outside the control of the software. That makes journalists usual lack of concern on how websites were hacked so problematic, as a lot of people come away with a belief that certain software is insecure in a way it isn’t. That can lead to people being less secure as they can come away with a belief that software that is actually more secure than other software is less secure, due to poor security coverage.

As to whether SquareSpace is better able to handle this situation as hosted solution, one thing we ran across while looking into this seemed less than reassuring. In a help article titled, ‘Google says “This site may be hacked”‘ they write the following:

Google applies this message to sites when they notice something that seems suspicious, which can include normal content, especially if it has external text formatting.

This means that the message was most likely triggered by content you added to your site, not by hackers. You can use Google Search Console to figure out what’s causing the message and remove it.

Squarespace offers free SSL certificates to provide a secure connection for visitors. We use many other methods to protect our customers, including regular security scans  and industry-developed and proprietary tools to guard against potential intruders, DDoS attacks, and other vulnerabilities.

We really can’t figure what the relevance of them providing secured connections (which involved more than just SSL certificates) to visitors of websites would have to do with the issue they are discussing there.

Cleaning Up a Hacked Website May Not Impact Email Spam Blacklisting

We recently had a couple of people come to us looking for a hack cleanup done for their websites due to the website or its domain name being blacklisted. The term blacklisted is sometimes used by website security companies to refer to situation where a website has been flagged by some entity as being hacked, calling that blacklisting looks to us like one of the many ways they try to turn up the fear factor around the security of websites. The more common usage and where it is more accurately used is with email spam blacklists. In both cases what was being referred to by the people contacting us was the latter and in both cases cleaning up a hack wouldn’t have taken care of the blacklisting.

When anyone contacts us about a hacked website we first want to access the situation to among other things, make sure the website is truly hacked, as we are often contacted about situations where the website isn’t actually hacked. In the case of these two websites, only the first appears to have been hacked, but when inquiring about who was blacklisting we found out that even with that one what was of more concern than fixing the website (it was broken in addition to being hacked) was that emails sent from the domain associated with the website were not reaching the recipients.

In both cases when we went to look into the details of the blacklisting what we found was that neither their websites nor their domain names were being blacklisted. Instead what was being blacklisted was the IP address associated with the websites/domain names. That sounds like a minor difference, but it was very important in these situations because when went to look at the details of why the IP addresses were blacklisted we found that this was due to other websites sharing the same IP address, which would likely be on the same server as well. So nothing done with the websites we were being contacted about would have resolved that, instead action related to the other websites would need to be taken and that would be best handled by contacting the web hosts for the websites.

There was another important possible implication of the blacklisting being caused by other websites when it came to the first website, as it seems possible that there was some security issue at the server level or the web host level that caused the website to be hacked. We say that because you had three websites that seems to be sharing the same server that had been hacked in the same time frame and both others had been hacked to be used in way that caused the IP address to be blacklisted. At least in our experience, hacked websites causing email spam blacking listing isn’t a common issue so to have two websites on the same server cause that in the same time frame would lead us to believe there might be a connection between the hack of the two.

With the first website the web host quickly took action with the other websites and got the blacklisting removed, but as far as we are aware there wasn’t anything done about the possibility of breach of the web host’s systems. With the second we can see the blacklisting was quickly resolved, but we don’t what caused that, as we didn’t hear back from the person who contacted after informing them about what was actually at issue and what would need to be done to resolve it.

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.

Sitelinks in Google’s Search Results Missing “This site may be hacked.” Warnings

Last week we discussed a US government contractor that offers several security services, including “Cyber Security” a service, while having hacked website, which we had run across after they were in the news for their involvement with questionable practices at US Housing and Urban Development (HUD) department. That incongruity between offering security services and not being able to secure their own website, makes it seem not all that surprising to us that in follow up reporting on the situation with the HUD department it was reported that the company was possibly engaged in fraudulent billing as well.

There is another thing we noticed in relation to the hack, though, which is that Google is currently incompletely warning that they are aware that websites are hacked.

In our previous post we mentioned that, for example, when you visited the website’s Careers page you would be redirected to a casino website. When showing up in Google’s search results that page is flagged with the message “This site may be hacked.”:

But when that same page is shown as a sitelink there is no warning:

Being a sitelink versus as standalone result should have no impact on whether this type of issue is occurring (and that is the case with this website), so Google should warn there as well.

Hacker Targeting Websites Hosted With SiteLock Partnered HostGator and Other Endurance International Group (EIG) Brands

Recently we have been thinking that a way to help people to better understand why security is in such bad shape despite the amount of money spent on it, is to say to think of the security industry not as that, but as the “insecurity industry”. As security companies are not focused on improving security, but instead of making people believe that insecurity is inevitable and that they can provide protection, but not to the extent that people actually expect those companies to keep them things secure. A prime example of a company that would fit that description is SiteLock, which is a company that comes up often on our blog when it comes to bad practices of the security industry. The other day we had someone forward several messages they had received recently from them and part of one of those stood out:

Malware is a real problem that affects a lot of websites. It’s as prevalent as the common cold and can do some real damage if you don’t catch and treat it early.

So how will you know if your website gets infected with malware?

To help protect your website, your hosting provider has partnered with SiteLock to provide your website with a complimentary malware scanner. Every day this nifty little tool checks the first five pages of your website for malware, and sends you an alert if any is found.

Their idea of protecting websites isn’t making sure that websites are actually secure, which would prevent them from being infected with malware or otherwise hacked, but instead trying to detect the website is infected after being hacked and then offering services that still don’t secure the website. That is great way for them to make money, but it isn’t great for everyone else since websites can continually be hacked.

As that email indicates they are not alone in that, web hosts have partnered with them. Why would a web host partner with a company that isn’t focused on making sure their customers’ websites are secure? Well when it comes to what seems to be SiteLock’s biggest hosting partner, the Endurance International Group (EIG), a partial explanation is that the majority owners of SiteLock also run EIG. EIG also disclosed to investors at one time that they receive 55% of the revenue of services sold through their partnership. That creates a strong incentive for EIG to not provide the best security possible as that would mean less money for them and less money being made by another company owned by the people running EIG. It might explain, for example, why in the past we found that EIG was distributing known insecure versions of web software to their customers through one of the companies they own, MOJO Marketplace.

Over the years EIG has brought together numerous web hosting brands including A Small Orange, Bluehost, FatCow, HostGator, iPage, IPOWER, JustHost and quite a few others. The situation with a website hosted with HostGator that we cleaned up a hack on yesterday seems to be an example of where those incentives might have created a situation that doesn’t serve their customers well.

The website was hacked in way that it would serve spam pages with Japanese text to Google’s search crawler.

While you wouldn’t know it from many companies that cut corners when doing hack cleanups, one of the three basic steps in properly cleaning up a hacked website is to try to determine how it was hacked. With this website the files involved in the hack didn’t really seem to shed any light on that. The main piece of this hack involved code added to the index.php file of a WordPress installation that caused the code in a file at wp-confing.php to run, which would cause that code to run whenever the frontend of the website is accessed. That filename is similar to a legitimate WordPress file in the same directory, wp-config.php, which could indicate that the hacker has some knowledge of WordPress, but considering how popular it is, it doesn’t seem to be a good indication that the hack was anything WordPress related (we also didn’t find anything that was known to be insecure in the WordPress installation).

The hacker had also added the website to a Google Search Console account with the email address “xueqilve@gmail.com” and submitted a sitemap to get the spam pages added to Google’s index.

It looked like the malicious code causing the issue had been added a few days ago (though another file might have been there since November), so there still should have been logging available from when that occurred that would shed more light on the source of that. Unfortunately HostGator hadn’t had log archiving enabled by default in the website’s cPanel control panel, so we only had access to logging for the current day. That fact alone probably should tell you that the company doesn’t have much concern about security and it would be strange to not have that on if they had a legitimate partnership with a security company since that would be an obvious thing to do because of its importance for dealing with hacked websites.

As we have found though, SiteLock usually doesn’t attempt to determine how a website was hacked, so they wouldn’t have a need for that logging. Considering that they don’t usually do that, it makes it not all that surprising that services they offer to protect website don’t work well, since they don’t know how websites are actually being hacked.

We did have one last lead to follow in trying to get some idea of how the website was hacked. In the root directory of the website there was a file named bray.php that contained the following message:

Hacked By Isal Dot ID

Through the website Zone-H, which catalogs defaced websites, we could see that same file had been placed on numerous websites recently. In looking over a number of those websites what stood out was that they all were hosted with HostGator or other EIG brands. Here are examples of websites hit at several nearly sequential IP address registered to HostGator:

If a hacker was hacking websites through a vulnerability in a WordPress plugin for example, that isn’t what you would expect to see, instead you should see websites hosted with numerous different web hosts.

At best you have a situation where a hacker looks to be specifically targeting numerous websites at EIG brands. There is also the possibility they are taking advantage of some security issue on EIG’s end to hack the websites.

Even if they are just targeting website hosted with EIG brands that seems like something that the hosting company would want to investigate and try to prevent as much as possible. That doesn’t seem to be the case here because later yesterday we were contacted by someone else with the exact same hack. They said HostGator has only been interested in pushing SiteLock. When you understand the incentives involved, it really isn’t surprising that is happening.

Update March 19, 2018: We have now come across a article from year ago in which the hacker behind this, claimed to have had full access to a server that contained another website they had hacked. That website was hosted with HostGator at the time (and Bluehost now). While the claim of a hacker isn’t necessarily reliable, it does raise further suspicion that there may be a security issue on EIG’s end

Hacker(s) Using File Manager Plugin to Assist in Taking Malicious Actions with Hacked WordPress Websites

Recently we have done cleanups of a number of hacked WordPress websites where part of what the hacker did after they have gained access to the website involved something we think would be useful to share with others in case they have even less information to go in trying to figure out how the website got hacked (attempting to determine how they were hacked is one of three basic steps in a proper hack cleanup).

In looking at the logging and other data, we have seen that the hackers were logging in to WordPress using existing WordPress accounts on the websites. From there they would install the plugin File Manager (WP File Manager). Here are the set of log entries where that occurred on one of the websites:

121.118.203.38 – – [15/Jan/2018:14:41:04 -0700] “GET /wp-login.php HTTP/1.1” 200 1693 “-” “Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:50.0) Gecko/20100101 Firefox/ECAC”
121.118.203.38 – – [15/Jan/2018:14:41:07 -0700] “POST /wp-login.php HTTP/1.1” 302 1258 “-” “Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:50.0) Gecko/20100101 Firefox/ECAC”
121.118.203.38 – – [15/Jan/2018:14:41:09 -0700] “GET /wp-admin/ HTTP/1.1” 200 22557 “-” “Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:50.0) Gecko/20100101 Firefox/ECAC”
121.118.203.38 – – [15/Jan/2018:14:41:24 -0700] “POST /wp-admin/admin-ajax.php HTTP/1.1” 200 553 “-” “Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:50.0) Gecko/20100101 Firefox/ECAC”
121.118.203.38 – – [15/Jan/2018:14:41:26 -0700] “GET /wp-admin/plugin-install.php?tab=plugin-information&plugin=wp-file-manager& HTTP/1.1” 200 9499 “-” “Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:50.0) Gecko/20100101 Firefox/ECAC”
121.118.203.38 – – [15/Jan/2018:14:41:31 -0700] “GET /wp-admin/update.php?action=install-plugin&plugin=wp-file-manager&_wpnonce=c0ba6299b7 HTTP/1.1” 200 10849 “-” “Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:50.0) Gecko/20100101 Firefox/ECAC”
121.118.203.38 – – [15/Jan/2018:14:41:37 -0700] “GET /wp-admin/plugins.php?action=activate&plugin=wp-file-manager%2Ffile_folder_manager.php&_wpnonce=67fdf3eee0 HTTP/1.1” 302 480 “-” “Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:50.0) Gecko/20100101 Firefox/ECAC”

As you can guess from the name that plugin is a file manager. The hackers then use the legitimate capabilities of that to modify existing files or add new files with malicious code. Here are the log entries from the same website where the same hacker looks to have logged in from another IP address and accessed the plugins functionality:

189.72.69.203 – – [15/Jan/2018:15:11:14 -0700] “GET /wp-login.php HTTP/1.0” 200 1731 “-” “Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:50.0) Gecko/20100101 Firefox/62F5”
189.72.69.203 – – [15/Jan/2018:15:11:18 -0700] “POST /wp-login.php HTTP/1.0” 302 1296 “-” “Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:50.0) Gecko/20100101 Firefox/62F5”
189.72.69.203 – – [15/Jan/2018:15:11:21 -0700] “GET /wp-admin/ HTTP/1.1” 200 22745 “-” “Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:50.0) Gecko/20100101 Firefox/62F5”
189.72.69.203 – – [15/Jan/2018:15:11:26 -0700] “GET /wp-admin/admin.php?page=wp_file_manager HTTP/1.1” 200 12922 “-” “Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:50.0) Gecko/20100101 Firefox/62F5”
189.72.69.203 – – [15/Jan/2018:15:11:31 -0700] “GET /wp-admin/admin-ajax.php?action=mk_file_folder_manager&_wpnonce=4028a67f1f&cmd=open&target=&init=1&tree=1 HTTP/1.1” 200 3150 “-” “Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:50.0) Gecko/20100101 Firefox/62F5”
189.72.69.203 – – [15/Jan/2018:15:11:35 -0700] “POST /wp-admin/admin-ajax.php HTTP/1.1” 200 2068 “-” “Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:50.0) Gecko/20100101 Firefox/62F5”

The most important question in all this is how the hackers got access to the logins for the websites, since without access they couldn’t have installed the plugin or done anything else. Unfortunately the cause is something we haven’t been able to say for sure since the evidence we have is somewhat limited when it comes to determining that part of these hacks.

In at least some of the cases the website were using extremely weak passwords (on one website the password was “admin1234”), so it is possible that a previous dictionary attack had determined the password. A dictionary attack involves try to log in using common passwords. Those types of attacks are fairly common, unlike brute force attacks, which despite inaccurate claims frequently made by security companies, are, based on those companies own evidence, not happening. The logging available so far hasn’t shown that occurring though, but it could have occurred outside the time period that there was logging available (the longer websites store logging the easier it would be to trace the original source of hacks).

In some instances the password being used was also used as the password for other services as well, so it possible that it was compromised somewhere else and the hackers tried it on the websites.

That all leads to the first take away from this, which is to make sure to use strong passwords (something WordPress does a good of making sure you can do) and to use separate password for each login connected to a website.

The second is that if you are dealing with a hacked website where the plugin File Manager was recently installed and it wasn’t installed by someone involved with the website, a compromise of a WordPress account with the Administrator role should be considered a possible source of the hack and further investigated. In one of the websites the plugin was later removed by the hacker, so you if see logging showing it being used, but it isn’t currently installed, that could have occurred on the website you are dealing with as well.

The third is that is that trying limit hackers once they have high level access is not necessarily very useful. In the past we have seen it suggested disabling the plugin and theme editors, since hackers could use those to modify files with malicious code. But as what happened here shows, hackers can easily get around that possible limitation.

SiteLock’s SMART Scan Failed To Deal with Issue Causing Cross-Site Browser Warning

One of the problems we have seen with the web security company SiteLock is that they label all sorts of things as being malware, making it hard for anyone else to determine what they might be referring to and therefore if the claim is valid. Sometimes their claims seem absurd, like the time they claimed a link to a non-existent domain name in a comment on a blog post was “critical” severity malware.

That type of issue could be an indication that their tools are overly sensitive or that they produce poor results. Something we just helped someone deal with reiterates what we have seen in the past,which is that it looks like the issue is the later.

We were contacted by someone for whom their website was being reported by the Chrome web browser as being dangerous and SiteLock’s  SMART (Secure Malware Automatic Removal Tool) Scan had been unable to fix the issue for them. They were looking for  quote from us to clean up the website.

When visiting the website in the Chrome web browser the following warning was being shown:

 

We have blacked out the domain listed, but the domain was the most important thing in the message because it wasn’t the domain of the website we were contacted about. Instead Google was warning about content from another website that was being served on this website, which is referred to as a cross-site warning.

In looking at the homepage’s content we found that the only content being loaded from that domain name was an image. When that image was removed the warning also went away.

That was easy for us to spot, but it was something that SiteLock’s tool wasn’t able to detect, while at the same time the tool flagged other things it seems like it shouldn’t.

This situation also shows why it is a good idea to come to us if you think you have a hacked website, because the first thing we do is to make sure the website is actually hacked and then we provide a free consultation on how best to deal with the issue. In this case that meant it didn’t cost this person anything more than whatever they had already paid SiteLock, to get this resolved. As once we saw what the issue was, we could tell them they simply needed to remove the image being loaded from that other website to resolve this.