Category: Bad Security

GoDaddy Still Using phpMyAdmin Version That Hasn’t Been Supported for Over Five and Half Years

Earlier this week we revisited a security issue with a web host that had yet to be resolved nearly two years after we first brought it up, but things can be worse than that.

Back in January of 2014 we pointed out that GoDaddy was still using a version of the database administration tool phpMyAdmin for which support ended in July of 2011. While dealing with an issue on a website hosted with them we noticed that they still are running that version, 2.11.11.3. It is incredible that such a big company would be running outdated and unsupported for over five and half years. You have to wonder what less visible security issues also exist in their systems.

While GoDaddy has a number of different types of accounts, according to their listing of what software is running on them all of the account types that include phpMyAdmin provide outdated versions of it. The newest version they are providing with an account type is 4.0.10.14, which is over a year out of date. They also are using 4.0.8, which is over three years out of date. Finally they are using 3.5.8.2, for which supports ended over three years ago.

When looking at this situation we can’t help but think of the GoDaddy’s partnership of with the security company SiteLock. If we were not already aware of what SiteLock actual does, it would seem very odd that they would not have required GoDaddy to deal with this issue long or ended their partnership, as it would highly irresponsible, at the very least, to be involved with a company that you know is leaving their customers insecure in this way.

CloudAccess.net Still Storing Non-Hashed FTP/SFTP/SSH Passwords

Back in May of 2015 we had put out a post discussing the fact that the web host CloudAccess.net was storing FTP/SFTP/SSH passwords in non-hashed form. Here is how we explained why storing them in hashed form was important, at that time:

One of the measures that needs to be taken is to store passwords as securely as possible, which means storing them in hashed form. You can think of a password hashing as one-way encryption. That is, the data is encrypted, but it cannot be decrypted, so the underlying password is not retrievable in normal circumstances. With this type of password storage when someone tries to log in the password they input is hashed and then compared with the stored password hash to see if they are the same. With hashed passwords even if someone gets access to the stored passwords it would be difficult for them to do anything with them, since they would first have to crack the hashes.

Then back in January we received a comment on the post apparently from the CEO of CloudAccess.net:

I represent CloudAccess.net, the company that you are writing about. To clarify, we do not store ANY passwords or sensitive information in clear text. Your assumptions are incorrect here. In the future if you have any questions or concerns you may ask us directly and we will explain further to alleviate your concerns. Thank you.

We didn’t really know what to make of that since it didn’t address the issue of the passwords not being stored in hashed form, instead only claiming that they were not stored in clear text, which isn’t the only way non-hashed passwords could be stored. So either the person didn’t really understand the issue at hand or they were trying to divert from the real issue.

Whatever was the case there, the issue hasn’t been resolved as we were just working on a website hosted with CloudAccess.net and found that they are still storing the FTP/SFTP/SSH passwords in non-hashed form. You can see below that on the relevant page in their control panel there is still the option to  view the password by clicking on “View hidden password”, which would not be possible if they were hashed:

 

Positive SiteLock Review Praises Them for Leaving Website Insecure

When it comes to finding a web security company to help deal with a hack or other security issue with a website you have a lot of bad options, as from what we have seen most security companies don’t know and or care about security. One of the results of that is that often these companies don’t even try to properly clean up hacked websites.

We are often brought in to re-clean hacked websites after another company did a cleanup and the website was then re-hacked. In that situation the first question we always ask is if the previous company determined how the website was hacked, since if the source isn’t found and fixed it could be exploited again. The answer is almost always that doing that never even came up. Considering that doing that is one of three basic components of a proper cleanup, either the company doesn’t understand what the service they are offering should even include or they are intentionally cutting corners.

One company that doesn’t do things properly is SiteLock and more troubling they use their corner cutting to try to get people locked in to long term contracts. You would think that a website getting repeatedly hacked due to that would only lead to only negative reviews, but one recent review for them on the BBB page for the company actually praised them for this:

Sitelock has been there for me in the middle of the night when my blog was compromised several times this year. I am a one woman team and it is great to know that I have Sitelock always there for me making sure I am all safe and secure. It is so wonderful to have a live person to talk to when you need it 24/7. Now on to my gluten-free baking and blogging!

We don’t understand how having a website compromised several times only two months in year could be paired with a claim that the company that dealt with the issue is keeping it “safe and secure”, but it happened here.

That is good reminder that you can’t rely on reviews of web security companies to point to a security company that can actual provide with a good result, because they are often praised despite providing a bad outcomes. We have even had clients that come to us to re-clean websites saying the previous company did a good job, despite needing us to re-do the work. In some cases like this one you might notice the inconsistency, but in others the details needed to spot that the praise is misplaced are missing.

Is SiteLock Providing Their Customers Access to All Accounts on GoDaddy Servers?

In looking over complaints about the web security company SiteLock a lot of things come up over and over, take for instance the end of a review of them from earlier this month at the website ConsumerAffairs:

Worst case scenario: a site will become infected with malware. Again, I get the auto-email with no clue to which site is infected. You have to upgrade your account to get it cleaned and then it never stays clean. It continues to get infected every few months and they do nothing to help you prevent or fix it. The one site that I’ve had this happen to, I ended up upgraded to the manual clean & monitoring service. Instead of them cleaning it when it happens, they send that email (you know the one, without any clue as to which domain it is referring) and then I have to call them to request it to be manually cleaned. AGAIN. They don’t just automatically do it, like the service implies. I cannot tell you what a frustrating phone call it is. They have no email or chat support and you are stuck to a phone call with someone who is trying to earn commission and has no interest in supporting you. DON’T USE THEM.

A lot of that isn’t surprising if you follow our blog, as we have discussed that usually when you get in contact with SiteLock you are dealing with a commissioned sales person (and how that looks to lead to untrue information being told to potential customers), the fact they cut corners when doing cleanups and leave websites insecure. It could actually have been worse as this review involved websites hosted at GoDaddy and we have previously discussed instances where websites cleaned through their partnership with SiteLock have left the websites broken.

What was new in this review was the claim of the prior paragraph of the review:

Once I find the account with the issue to reconnect, it is an absolute nightmare to do so. You have to enter the FTP info, then sift through EVERY SINGLE Godaddy site on the server to find yours (I’m not kidding, and I’m sure you can imagine there are a lot of sites on Godaddy’s server – why I have access to every single one of them via SiteLock seems like a security issue in itself). It’s an extremely tedious, SLOW and frustrating process.

It isn’t clear what level of access they are referring to there and what could be done with it, but there shouldn’t be any access to unrelated accounts at all (especially through a security service).

If you have more information on what access they are providing through that please leave a comment on this post or get in touch with us.

SiteLock and Bluehost Falsely Claimed a Website Contained Malware Due to SiteLock’s Poor Scanner

When it comes to the web security company SiteLock, one of the frequent complaints is that they and their web hosting partners falsely claim that websites have malware on them. After that happens the web hosting company frequently suspends access to the website and pushes the customer to hire SiteLock to clean up not existent malware. We thought it would be useful to look at an example of this we were recently consulted on, as those dealing with the possibility of a false claim should know a number of things when dealing with it.

This situation involved the web host Bluehost. Bluehost is one of many brands the company Endurance International Group (EIG) does business under. Some other major ones are A Small Orange, FatCow, HostGator, iPage,  IPOWER, and JustHost. The company’s web hosting brands are very open about having a partnership with SiteLock, what they have, at least in the past, refused to acknowledge publicly is that partnership involves EIG getting 55 percent of revenue for SiteLock services sold through that partnership (that information was disclosed to investors). That obviously raises some serious questions and it probably explains in large part a lot of the problems that arise from that partnership. What they also don’t disclose to their customers is that the majority owners of SiteLock are also a member of the board and the CEO of EIG, so they are well aware of SiteLock’s practices.

What we have repeatedly said is that if you get contacted by SiteLock or one of their web hosting partners claiming that the website is infected or otherwise is hacked, is that should not ignore it. While there are plenty of situations like the one discussed here where there is a false claim, the claim is also often true. For a hacked website, the longer you wait to do properly clean it up, the bigger the problem can be. Instead we recommend that you first get any information that SiteLock and or the web host will provide and then get a second opinion as to whether the website is hacked. We are always happy to provide that and we would hope that other security companies would as well (when someone contacts us about a hacked website we always make sure it is actually hacked before taking on a cleanup).

One of the reasons for getting a second opinion is that someone familiar with hacked websites should understand how to easily check the validity of the claims made. While someone not familiar with the situation might try doing checks that won’t necessarily be very useful. In this situation one the things the website’s owner did was to download a copy of the website’s files and run them through a malware scanner. That likely is going to fail to identify many files that contain malicious code because a malware scanner for a computer isn’t designed to detect those files (our experience is that scanners designed to scan website files don’t produce great results either).

When we were provided the information that the website’s owner had received, the first element that caught our eye was this result of SiteLock’s malware scanner:

What was shown was rather odd as the malware scanner claimed to have detected a defacement hack (labeled as “SiteLock-PHP-HACKEDBY-klw”), which isn’t malware. So at best the scanner was incorrectly labeling a hacked website as containing malware, when it had a different issue.

More problematic is that it looks like they might are flagging websites as being defaced just because they have text that says “hacked by” something. That could produce some rather bad false positives, since this post itself could be claimed to contain malware simply by using that phrase. They also mark that detection as having a severity of “Urgent”, despite that.

So was the website defaced as that scan seemed to indicate? The website was taken down by the point we were contacted, which wouldn’t need to be done just because there was a defacement and makes it harder for someone else to check over things (whether intentional or not, it seems like something that makes it easier to push someone to hire SiteLock to resolve the issue). Looking at the Google cache of the website’s homepage though, we were able to see what happened.

The website’s page contains a section that shows RSS feeds items from other websites. One of those websites had been impacted by a vulnerability in outdated versions of WordPress that allowed defacing posts and the results of that defacement was showing on this website:

That “hacked by” text on showing there didn’t mean this website was infected with malware or otherwise hacked and the website didn’t pose any threat. That is something that anyone from Bluehost or SiteLock familiar with hacked websites should have spotted by looking over the website for a few seconds, but clearly that didn’t happen, even when they suspended access to the website. Both of them have an incentive to not check to make sure the website is hacked, since they have monetary interest in selling security services in this situation even though they are not needed. As we mentioned recently it appears that when you are in contact with SiteLock you are dealing with a commissioned sales person, not a technical person, so they might not even understand what is actually going on either (one situation we looked at recently would strongly seem to indicate that as a possibility).

Looking at the files that Bluehost had listed as being infected, they were just cached copies of the content from the website that had the RSS feed section in them. So there wasn’t any malware in them.

It also seems that no one from Bluehost or SiteLock bothered to contact the other website to let them know that there website was actually hacked, seeing as it was quickly fixed after we notified them of the issue they had.

At this point the website’s owner is planning to move to a new web host, which doesn’t seem like a bad idea (we think that people should avoid web hosts that have partnered with SiteLock even if they have yet to run into this type of situation).

Trend Micro Thinks Their Continued Failure to Take a Basic Security Measure Shouldn’t Define Them

Back in May of last year we noted that cyber security company Trend Micro was failing to keep the installation of WordPress on their blog up to date. What stuck out about this was that this shouldn’t have happened, as WordPress has an automatic background update feature that would normally have done the updates without requiring any interaction by someone at Trend Micro. So either there was some incompatibility between their hosting environment and that feature or they unwisely disabled the feature without making sure to promptly do the updates manually instead. If it was the former, then they could have probably helped not only themselves, but others by working with WordPress to fix the cause of those updates not occurring.

Fast forward to last week where it was reported that another one of their blogs was attacked due to a vulnerability in WordPress that would have not been possible to exploit on the website if they either had gotten automatic background updates working or if they had started promptly updating manually.

The response from the company’s “Global head of security research” makes it sound like the company has no idea what they are doing:

“We got reports from many researchers, regarding attacks using this vector and we deployed a custom policy to block the attacks,” he explained.

“Unfortunately there are many different URLs attackers can use to carry out the same attack, so a couple of fake ‘articles’ ended up posted on CounterMeasures. We have responded and shut down the vulnerability completely to resolve the issue

“Just serves to demonstrate something that I have often repeated in presentations, we are all a potential victim of digital attacks and we can’t afford to take our eyes off the ball at any time. The best way to respond to any attack of this nature is with honesty and alacrity, and that’s what we have endeavoured to do.

“Of course technology and best practice can mitigate the vast majority of intrusion attempts, but when one is successful, even one as low-level as this, you are more defined by how you respond than you are by the fact that it happened.”

The really simple solution to prevent this vulnerability from being exploited is to make sure you updated from WordPress 4.7.0 or 4.7.1 to 4.7.2, but there is no mention of that. Instead they make some mention of a “custom policy to block the attacks”, which is not necessary if you just updated to 4.7.2.

Amazingly as of this morning the blog is still running WordPress 4.7.1, as can easily be seen by viewing the source code any page on it:

The main Trend Micro blog doesn’t contain a meta generator tag, which makes it easy to spot what version is in use, but if you look at the CSS and JavaScript files being loaded on it you can see repeated use of “4.7.1” in the URLs, which tells you it is also on WordPress 4.7.1:

Defining Trend Micro by their response to getting attacked rather than their failure to take best practices doesn’t seem to make things better here, since they still have failed to properly respond to the situation by updating WordPress. Since they can’t handle the basics, you really would have to wonder about their handling of more serious things. Or you would if the wasn’t already evidence they can’t.

 

SiteLock Review Shows the Problem of Relying on Customer Reviews To Determine Quality of Security Companies

We have frequently mentioned the fact that many security companies don’t know and or care much about security. That not surprisingly leaves the public with a lot of bad options when they are looking for someone with security expertise to help them deal with a hacked website or other security issues. So how can they find one of the few companies that don’t fall in to one of those categories? We don’t know of an easy way, but we do know that looking at customer reviews of security companies isn’t a good way to do that.

We frequently are brought in to re-clean hacked websites after another company had been brought in to do that. While that isn’t always the company’s fault, we have found that in almost every instance the company doing the cleanup either didn’t know what they were doing or intentionally cut corners. We know that because we always ask in these instances if the previous company had determined how the website was hacked (since if the vulnerability hasn’t been determined and fixed it would leave the website open to being hacked again), and the response is almost always that trying to determine how the website never even came up. Considering that is one of three main components of a proper hack cleanup, that shouldn’t be the case. In more than a few cases even at that point the person we are dealing with said that the previous company did a good job, which doesn’t seem accurate considering they didn’t do things properly and the website was hacked again. If people think they did a good job at that point, we would assume that even more would have said that right after the original work was completed.

To give you another example of this we thought something we ran across involving web security SiteLock is worth highlighting. Here is a review of SiteLock from August of last year that comes from the BBB page for them:

Sitelock has been a great and affordable toll to achieve… security challenges, and enabled idbasolutions.com to offer our visitors peace of mind. In one and only incident in 2012, Sitelock emailed us as soon as they detected that some malicious software had infiltrated our comment pages…they quickly deleted all malicious code.

The problem with that review is that the website isn’t actually secure and hasn’t been secure for some time. The website is running Joomla 1.5, for which supported ended in September of 2012, over four years ago.

You wouldn’t know that if you were to believe SiteLock, as of today they are claiming it is secure:

It would be easy for SiteLock to determine that the website was running outdated software and isn’t secure, as the source code of each page on the website contains the following line:

<meta name=”generator” content=”Joomla! 1.5 – Open Source Content Management” />

So the review’s claim that SiteLock services “offer our visitors peace of mind” is true, but it is because SiteLock is not telling the website’s visitors the truth.

Considering that SiteLock missed such an easy to spot issue, it isn’t hard to believe they might also miss more serious issues, and in fact our past experience shows that it isn’t a theoretical issue. So while the review is positive, the underlying reality is the opposite.

Considering that customers of security services are hiring them in the first place, it isn’t likely that many reviews come from someone who would actually be aware of a failure like SiteLock’s here, so many other reviews of them are probably unintentionally misleading others as well.

Unreliable Claim That 1.5 Million WordPress Pages Defaced Is Reminder of the Terribleness of Security Companies/Journalists

In the last day there have been quite a few security journalists writing articles claiming that 1.5 million pages on WordPress websites have been defaced due to a vulnerability that existed in WordPress 4.7.0 and 4.7.1. In looking over those articles we have found that in some cases the claim isn’t actually sourced at all and what appears be the original source for the figure in the others, which came from a security company, isn’t reliable at all and that the journalists ignored a huge red flag that should have warned them that the claimed figure and the source of should not have been relied on.

First let’s look at a couple of the articles with unsourced claims. The Inquirer’s article is titled “WordPress hacking spree sees 1.5 million web pages defaced“; nowhere in the article is a citation for that claim provided. The closest the article gets is this:

According to a report on the BBC, there are millions of pages that have already been defaced thanks to the vulnerability.

In that BBC article the claim is not sourced either:

One estimate suggests more than 1.5 million pages on blogs have been defaced.

In ITworld’s article “Recent WordPress vulnerability used to deface 1.5 million pages” you get a source, but no explanation as to how the number was calculated, which seems like important information to provide:

Since then the number of defaced pages has grown to over 1.5 million and there are 20 different attack signatures, according to statistics from Feedjit, the company behind the Wordfence security plug-in for WordPress. The number of unique affected websites is estimated at around 40,000, as a site can have multiple defaced pages.

Also worth noting here is that there is an estimate of the number of websites impacted, which seems to be the more relevant number to be the headline number, assuming either was accurate. We don’t think there is much question as to why they went with the pages number, with the current state of security journalism click-baitness is more important than providing high quality reporting.

The Bleeping Computer’s article, “Attacks on WordPress Sites Intensify as Hackers Deface Over 1.5 Million Pages” cites nearly identical numbers as to the number of pages and websites:

Attacks on WordPress sites using a vulnerability in the REST API, patched in WordPress version 4.7.2, have intensified over the past two days, as attackers have now defaced over 1.5 million pages, spread across 39,000 unique domains.

It also looks like they are citing Wordfence for their number of web pages defaced as well:

The number grew to over 100,000 pages the next day, but according to a report from fellow web security firm WordFence, these numbers have skyrocketed today to over 1.5 million pages, as there are now 20 hacking groups involved in a defacement turf war.

When you look at Wordfence’s post the claim of 1.5 million pages is based on Google’s estimate of how many pages contain certain “hacked by” phrases:

On the far right we also include the number of defaced pages for each campaign, according to this morning’s Google results.

Are those reliable? The answer seems to be no. Here is how a BBC article from 2012, “Are search engine result figures accurate?“, starts out:

Enter the name Tim Harford into Google and you get 835,000 results.

Or 325,000, or 285,000… I got these widely differing results on computers within metres of each other in the same office at the same time.

So using those as headline number and not disclosing that it is the source (along with a disclaimer as to the questionable accuracy) seems quite inappropriate. It gets worse though, because in Wordfence’s post they take this misleading number and stretch in even further. In their chart they labeled the 1.5 million page estimate as being the number of “Hacked Sites”, not web pages:

That seems like the sort of thing that should have warned journalists away from that, but security journalists don’t seem to care much for accuracy.

The 39,000 unique domains or around 40,000 websites figure also looks to come from the same chart. The problem that appears to be a measure of websites where Wordfence saw an attempt to exploit this on, not the number of websites hacked:

Considering that any WordPress websites running 4.7.1 when 4.7.2 was released would have been automatically updated to 4.7.2 and protected against the exploit long before the attacks started, unless the automatic updates feature wasn’t working on the website (which we don’t see being the case with many websites) or it was disabled (which people sometimes foolishly do), the number of attacks that could have been successful was probably a small portion of the 39,000 attacked.

Unfortunately what has happened here with these inaccurate claims of the size of exploitation are all too common these days due to the poor state of security companies and security journalists.

Google Sending Out False Alerts That Websites Are Running Outdated WordPress Versions

Back in 2009 Google started notifying webmasters through their Webmasters Tools (later renamed Google Search Console) that they were running outdated software in some instances. That is good idea, but it clearly needs some work as of 2017, seeing as last night we got the following email:

Recommended WordPress update available for http://www.whitefirdesign.com/

To: Webmaster of http://www.whitefirdesign.com/,

Google has detected that your site is currently running WordPress 4.7.0 or 4.7.1, an older version of WordPress. Outdated or unpatched software can be vulnerable to hacking and malware exploits that harm potential visitors to your site. Therefore, we suggest you update the software on your site as soon as possible.

Following are one or more example URLs where we found pages that have outdated software. The list is not exhaustive.

https://www.whitefirdesign.com/blog/2011/03/02/hiding-the-wordpress-version-number-will-not-make-your-website-more-secure/

https://www.whitefirdesign.com/blog/category/outdated-server-software/

https://www.whitefirdesign.com/blog/category/sucuri-security/

Recommended Actions:

1 Update to the latest release of WordPress

Visit the WordPress site for instructions on how to download and install the latest release.
2 Check your site for hacked content

Because there was a vulnerability on your site, it’s possible that your site might have been compromised. We recommend you check your site for any suspicious activity. You can see if Google has detected any hacked content on your site in the Security Issues section of Search Console.
3 Stay up to date on new releases

Remember that older or unpatched software might be vulnerable to hacking or malware, so it’s important to install new software releases when they come out.

Need more help?

• Read more about outdated software and vulnerabilities in our Help Center.
• Check your site for hacked content using the Hacked Sites Troubleshooter.
• If your site was compromised, read our guide for hacked sites.
• Ask questions in our forum for more help – mention message type [WNC-641200].

Because this blog, like hopefully almost all WordPress installations, hasn’t had the automatic background updates feature disabled, it already was updated. In fact the update to 4.7.2 happened as of midday on January 26, the day the update was released. That was 11 days before the email was sent out. Seeing as we haven’t removed the meta generator tag from the blog, the version is included on every page’s source like this:

<meta name="generator" content="WordPress 4.7.2" />

Our guess would be that they are still processing pages crawled from before the update happened, which include the previous version number, and they are basing the claim of outdated software on that, which is obviously problematic.

It also worth noting that they are failing to capitalize the “p” in WordPress, instead referring to it as “WordPress”.

Minor WordPress Updates Are The Ones You Want To Make Sure Are Applied Right Away

When it comes to the security of websites one of the major problems we see is that often the basics are not being done (even by security companies), one of the most important is keeping software up to date, which prevents known vulnerabilities that have been fixed in a newer version of the software from being exploited.

Back in 2013 the developers of WordPress took a step to protect websites running WordPress from this by introducing a new updates system in WordPress 3.7 that automatically applies minor WordPress updates (the ability to have major WordPress, plugin, and theme updates also exist in that functionality). Alongside that they started releasing security updates for older major releases that have that update functionality, in the form of minor updates. So unless something causes that feature to not work or it has been intentionally disabled, any websites still running WordPress 3.7 or above would still be being protected against vulnerabilities discovered in WordPress.

As far as we are aware only the most recent major version of WordPress is officially supported, so you should be making sure you are on the latest version, but those running older major versions should still be relatively secure as long as they are on the latest minor release of that.

Disabling those automatic updates cannot be done in the settings of WordPress, so it isn’t something that could be accidentally done. Instead someone has to make an active decision to do that (by using a plugin or making a change to a file) and it would generally be a bad one. The reasons for doing that usually seem rather bad, take for example the website of WordPress security plugin where that looked to have happened, the company behind later told us that had been done because they had modified core files, which you shouldn’t be doing (that the developer of security plugin would be modifying core files like that would be concerning on its own and it probably isn’t surprising then that we later found a couple of vulnerabilities in the plugin).

That brings us to fairly widespread reports of websites that have been hacked due to not having applied the latest WordPress update (without having looked at the websites’ data and logging we can’t say how many of those claims are true and how many of those websites were hacked due to other issues). One message that showed up about this in the monitoring of the WordPress support forum we do, to keep track of vulnerabilities in plugins for our Plugin Vulnerabilities service, had a troubling explanation for not being on the latest version:

WordPress 4.7.2 was patched at some rest-api vulnerability and some other stuff according to change log. I usually checkout the change log every time whenever an update is available. This was the first time I didn’t check that and only imagined the 0.1 version difference to be a slight upgrade. But I was wrong.

While some minor updates just include bug fixes (the last one being in April of last year), most are security updates. By comparison, a major update is not likely to introduce a security fix. So the updates you want to apply right away are the minor ones or better yet don’t disabled the automatic updates, so you don’t have to worry about making this decisions. Major updates, not minor updates are the ones that have more of a chance of causing a problem (say if a plugin hasn’t been updated to be compatible with the new version).

If you are still using a very old version of WordPress on your website, you may want to have a test of the upgrade done before upgrading the production website to the latest major version so that any issues can be resolved first. Doing a test of the upgrade is included in our upgrade service for WordPress.