GoDaddy Distributing Software With Known Security Vulnerabilities

Oftentimes when a website is hacked the web host will blame the hack on outdated software running on the website. From our experience they often do this without any evidence to back that up and in some cases they obviously haven’t even checked if the website is running outdated software since the website in question was using up to date software at the time of the hack. Based on that you would think that web hosts would be very careful when distributing software to their clients that they make sure that it is up to date, but as we keep seeing that isn’t the case. The latest example this came up while we were looking into GoDaddy’s bad response to the Drupal 7 vulnerability. We noticed in their Hosting Connection, which they say has been used to install 6.9 million apps, that they were still installing Drupal 7.32:

GoDaddy's Hosting Connectin is installing Drupal 7.32

Drupal 7.33 was released last Friday and includes “numerous bug fixes”. Since the new version didn’t include any security fixes it wasn’t a huge issue that they hadn’t updated the version they installed yet. But then we started looking at the version of other software they were offering and things got much worse.

They are still installing Joomla 2.5.14:

GoDaddy's Hosting Connectin is installing Joomla 2.5.14

 

That version is now a year out of date, the next version was released on November 6, 2013, and GoDaddy hasn’t updated their Joomla version despite there having been four subsequent releases with security fixes (2.5.1.5, 2.5.19, 2.5.25, and 2.5.26).

Joomla is among the software GoDaddy lists as being the five most popular in the Hosting Connection and unfortunately isn’t the only one where they have failed to keep up with security updates. They are currently installing Simple Machines Forum version 2.0.6:

GoDaddy's Hosting Connectin is installing Simple Machine Forum 2.0.6

Version 2.0.9, which was released over a month ago, addressed “several security issues” and the developers recommended “that you update your forums immediately to ensure that your community is safe”.

Looking at other software we work with frequently we found more problems. GoDaddy is still offering MediaWiki 1.21.1:

GoDaddy's Hosting Connectin is installing MediaWiki 1.2.1.1

Support for the MediaWiki 1.21.x series ended back in June, so GoDaddy should have switch to a newer series by that point. Before that though they failed to update for any of the nine security updates (1.21.2, 1.21.3, 1.21.4, 1.21.5, 1.21.6, 1.21.8, 1.21.9, 1.21.10, and 1.2.11) released for the 1.21.x series.

Next up, GoDaddy is still offering OpenX despite it being re-branded as Revive Adserver over a year ago:

GoDaddy's Hosting Connectin is installing OpenX 2.8.3

The version they are offering is nearly five years out of date, the next version was released in January of 2010, and they fail to update for the last eight security updates (2.8.6, 2.8.7, 2.8.8, 2.8.9, 2.8.10, 3.0.0, 3.0.2, and 3.0.5).

For Moodle they are still providing Moodle 1.9.19:

GoDaddy's Hosting Connectin is installing Moodle 1.9.19

That was the last release of the Moodle 1.9.x series, for which support for security fixes ended entirely last December. Anyone unlucky enough to install this version and start using it now would discover they will have a lot of work to get it to a supported version as the upgrade from Moodle 1.9.x to 2.x is a major one and they will have to do at least two upgrades as you have to an intermediate upgrade 2.2.x before getting to a supported version.

GoDaddy’s Partnership with SiteLock

It gets worse from there, while GoDaddy is putting their client’s websites at risk they then want to sell them additional service to “Defend your website against hackers.”, which is done in partnership with SiteLock. We would ask how it is that SiteLock hasn’t informed them about the issue with outdated software but our past experience is the SiteLock doesn’t do the basic security check of making sure the software on a website is up to date, which would expect from a company that GoDaddy says provides the “most advanced and complete security solution available”, or make sure that software gets updated when they clean up a hacked website.

Posted in Bad Security, Outdated Web Software | Leave a comment

GoDaddy’s Bad Response to the Drupal 7 Vulnerability

Back on October 15, Drupal released Drupal 7.32, which resolved a highly critical security vulnerability that existed in prior Drupal 7 versions. Unlike security vulnerabilities that have been fixed in recent years in Drupal and other major software, this vulnerability was easily exploitable. By the next day we were seeing attempts to exploit the vulnerability and we have been seeing a steady pickup of people contacting us about cleaning up their hacked Drupal websites, which were hit due to this. The speed and scope of the exploitation points to the need to improve how security vulnerabilities are handled in Drupal and more broadly.

Since making software that is completely free of vulnerabilities is next to impossible the best solution for this type of situation is to introduce an improved upgrade mechanism, like the one in WordPress. Starting with WordPress 3.7, security updates are automatically applied without requiring any user intervention. Checks for new versions are normally done every 12 hours and the WordPress server can instruct them to happen more frequently ahead of a planed update, so within a day most websites will have the security update applied. Not only does this protect those websites, but it makes the remaining vulnerable websites a less attractive target since the success rate of trying to exploit the vulnerability is much smaller (that doesn’t mean that they won’t get hacked though).

In the meantime, getting the word out on the need to update or take remedial as soon as possible is important to lessening the severity of security vulnerabilities. In this case Drupal recommend restoring a backup from before October 15 if you didn’t upgrade right away and every day that passes makes it harder to do that. Web hosts could play an important role in getting the word out. At least some of the largest web hosts already have the capability to detect what software and in some cases what version is in use, so they can inform impacted customer of the situation. GoDaddy has attempted to do this for the Drupal 7 vulnerability, though their implementation leaves a lot to be desired.

Today we have had a number of people contacting us saying that they had just been informed of they needed to upgrade Drupal due to a security issue. Considering that the last security update for Drupal 7 was 7.32 and that was released in the middle of October we were wondering what was causing this. It turns out that GoDaddy has just been letting people know of the vulnerability. While rather late, what was more problematic was what they said in the email.

The first big problem is that based on their email you would think that that is just occurred:

A few days ago Drupal announced a “Highly Critical Public Service announcement” that affects all Drupal users. In short, there’s a major security vulnerability that attackers can leverage against your visitors.

The Highly Critical – Public Service announcement was released back on October 29, not a few days ago. Even before that was released it was widely known that there was urgent need to update as the details of the vulnerability were disclosed with the release of the update on October 15.

The email gets more problematic from there. The beginning of the emails indicates that the required action is updating:

Action required:

Update your Drupal website

Later it says:

It’s extremely important that you update your site immediately to ensure you’re not putting your customers at risk.

At this point if you have Drupal 7 website still running a version below 7.32, that hasn’t been otherwise protected against the vulnerability, you should assume that it has been hacked, so just updating isn’t an appropriate resolution. That isn’t mentioned in the email at all, despite the public service announcement they cite being very clear about that.

Drupal Did Not Recommend This

After reading over this we were curious to see if GoDaddy was spreading this bad information on their website as well. It looks like they only got around to mentioning the issue on November 6, but at least in that case they provided accurate information. Another article linked to from that page those highly inaccurate though. Specifically the section Manually Remove Backdoors, which says:

If you do not have a backup of either your website or database (or both), you must manually remove any backdoors from your Drupal installation.

To do this for you, we offer an Expert Service for $79. With this service, we will perform all of the work for you to make our best effort to remove all backdoors using the procedures identified by Drupal. This service does not guarantee your website is free from compromise, but it is as close to compromise-free as anything can come if your Drupal installation wasn’t upgraded before the first reported compromises or restored from a backup created before Oct. 15, 2015 at 11pm UTC.

To purchase the Expert Service, contact customer support.

You can also manually remove any backdoors yourself using the Drupal-recommended procedure outlined here. This procedure is very complicated and requires an advanced understanding of the technologies Drupal uses (PHP, MySQL) to use effectively. Not all steps listed in the procedure are applicable to shared hosting environments, but completing what you can from this list will provide you the greatest likelihood of removing backdoors from your site.

If you follow the link “the procedures identified by Drupal”, you will find that it isn’t actual something from Drupal. Later GoDaddy links to the same page and describes it as the “Drupal-recommended procedure”, but if you actually look at the page it says “The official recommendation is: Restore from pre-October-15-backups.”. You really have to wonder about a company trying to sell you on an “Expert Service”, for which they don’t have the expertise to actually understand a basic, that is they they are citing something that isn’t actually procedures identified by Drupal or recommend by them.

Posted in Bad Security, Drupal | Leave a comment

Drupal 7.32 Usage Reached 24 Percent in Second Week

With a highly critical vulnerability found Drupal 7 versions prior to 7.32 and with Drupal providing data on usage of various versions, a good opportunity to see at what speed websites are being updated when there is a pressing need to do so is available now. Last week we found that in the first week only 12.46% of Drupal 7 websites had been updated to Drupal 7.32. In the second week it has now increased to 23.77%. We should note that it is possible to patch the vulnerability without doing a full upgrade, so not all websites that have not been upgraded are necessarily vulnerable at this point.

drupal-7-usage

Drupal 7.32 usage has now surpassed to 7.31 usage, which was also a security update. What is rather troubling is that 59.28% of Drupal 7 websites haven’t been updated to at least 7.31 despite it being released nearly three months ago.

For those in need of an upgrade we provide one time Drupal upgrades and ongoing upgrades for Drupal 7 (with security updates in a day). You can use our Drupal Version Check chrome extension and Up to Date? Chrome app to keep track of the update status of Drupal websites you manage.

Posted in Drupal, Outdated Web Software | Leave a comment

Exploit Attempts of Drupal 7 Vulnerability Are Reminder That Hiding Software Versions in Use Isn’t a Security Measure

When it comes to securing website there is lots of bad advice out there, much of it coming from people that claim to have security expertise. A prime example of this bad advice is the claim that hiding version of software in use on the website will somehow protect you being hacked. While there a number of reason it won’t protect you, the central issue is that most hackers won’t bother checking if you are using software, much less what version of the software is in use. Instead they will simply try to exploit the vulnerability without checking anything first. That means that no matter how hard you try to hide the version information it won’t protect you if you are running a vulnerable version. Seeing as people continue to believe and tell others that hiding versions information is a security measures we thought it would be a good time show a real world example of this in action.

Recently a highly critical vulnerability was found in Drupal 7 versions below 7.32 and shortly afterward attempts to exploit it were happening. Below is the series of requests from one of those attempts that occurred the day after the vulnerability was fixed:

62.76.191.119 – – [16/Oct/2014:21:03:25 -0400] “POST /?q=node&destination=node HTTP/1.1″ 200 4929 “-” “Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20130101 Firefox/10.0″
62.76.191.119 – – [16/Oct/2014:21:03:26 -0400] “POST /user HTTP/1.1″ 500 3566 “-” “Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20130101 Firefox/10.0″
62.76.191.119 – – [16/Oct/2014:21:03:27 -0400] “GET /?q=ocyuys HTTP/1.1″ 404 6035 “-” “Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20130101 Firefox/10.0″
62.76.191.119 – – [16/Oct/2014:21:03:27 -0400] “GET /ocyuys HTTP/1.1″ 404 6035 “-” “Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20130101 Firefox/10.0″
62.76.191.119 – – [16/Oct/2014:21:03:28 -0400] “GET /modules/profile/mhtd.php HTTP/1.1″ 404 6035 “-” “Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20130101 Firefox/10.0″

The IP address the requests came from, 62.76.191.119, appears to have been used for a widespread attempt to exploit the vulnerability.

Looking at the requests the first thing that sticks out is what isn’t requested. If you were going to check what version of Drupal is in use the first thing to request would be the file CHANGELOG.txt, which on Drupal websites will contain the Drupal version in use, if the file hasn’t been deleted. Since our website is running Drupal and we haven’t deleted the file the hacker have seen that we were running version 7.32 and therefore were not vulnerable. If the CHANGELOG.txt file doesn’t exist then you could check other files to get some idea of what version is in use. In this case the vulnerability only exists in Drupal 7, so a hacker might check for a file that exists in that version and not in Drupal 6.

Instead of doing any checks first, the hacker first request appears to be an attempt to exploit the vulnerability. The log of requests doesn’t include the POST data, so we don’t exactly what was done, but it was likely something similar to the POC #1 listed here. The rest of the requests seem to be checking if the first request was successful.

Beyond this being a reminder that hiding software is not a security measure, it is an important reminder that you need to keep the software running up to date. Something people running Drupal 7 websites have not been good at doing. It also highlight the fact that many people dealing with security have little understanding of it and in many cases are not doing the work they should do. Determining how a website has been hacked is one of the key things to properly cleaning up a hacked website, yet we see over and over we are hired to re-clean hacked websites that person hired before hadn’t done that. If people were doing that then they would know that hackers are not checking for the versions of software in use and therefore wouldn’t be telling people that hiding software versions is security measure.

Posted in Bad Security, Drupal | Leave a comment

Handling Errors in Modules Caused by Zen Cart 1.5.3’s Change to the mysqli Extension

For the most part, the changes introduced in Zen Cart 1.5.3 have little impact on add-on modules in use, but we have found that one under the hood change is causing some problems. Previous versions of Zen Cart connected to the website’s database using PHP’s MySQL extension, starting with Zen Cart 1.5.3 the connection is instead made using PHP’s MySQL Improved (mysqli) extension. This change was needed at the very least to future proof Zen Cart as the MySQL extension was deprecated in PHP 5.5 and will be removed in a future version. For most modules the change has no impact, either because they don’t interact with the database or because they interact with it though Zen Cart’s database abstraction layer, so they don’t have any direct interaction with the database extension in use. In doing upgrades to Zen Cart 1.5.3 we have found that some modules, including the popular Easy Populate CSV and Super Orders, have direct interaction with the database using the MySQL extension. Because Zen Cart 1.5.3 is no longer using the MySQL extension to connect to the database, errors like the following will be shown when a module tries to utilize MySQL extension based functions:

Warning: mysql_query(): Access denied for user ‘root’@’localhost’ (using password: NO) in [redacted]/orders.php on line 1229 Warning: mysql_query(): A link to the server could not be established in /[redacted]/orders.php on line 1229 Warning: mysql_fetch_array() expects parameter 1 to be resource, boolean given in [redacted]/orders.php on line 1230

The quick solution to this type of error is to create a MySQL extension based connection for the module’s code to utilize. This can be done by adding the two following lines near the top, but below the line “<?php”, of the file with the error:

mysql_connect(DB_SERVER, DB_SERVER_USERNAME, DB_SERVER_PASSWORD);
mysql_select_db(DB_DATABASE);

The first line makes a connection to the database server listed in your configure.php file and the second will select the database listed in the configure.php.

A more permanent solution would be to modify the module’s code to utilize Zen Cart’s database abstraction layer, if possible.

Posted in Zen Cart | Leave a comment

Only 12 Percent of Drupal 7 Websites Upgraded to 7.32 In First Week

One of the basic measures needed to keep websites secure is to keep the software on them up to date, as that prevents them from being hacked due to a known vulnerability in the software. That unfortunately isn’t something that people are very good at doing. With Drupal you can get fairly good data on how well people are at keeping up to date due to the developers publicly releasing data on what version are in use. When we looked at the data in late March we found that only 33 percent of Drupal 7 websites were up to date and only 72 percent of Drupal 7 websites were up to date or less than year out of date.

With a highly critical vulnerability fixed in Drupal 7.32, which hackers started exploiting shortly after the fix being released, we are curious see how fast websites are being updated. The first week of data, for the week of October 19, has now been released and it shows that only 12 percent of websites have been upgraded to 7.32. We should note that it is possible to patch the vulnerability without doing a full upgrade, so not all websites that have not been upgraded are necessarily vulnerable at this point.

That number is better than with a previous, less severe, security update. We previously look at the rate that Drupal 7 was updated to 7.27, which fixed a moderately critical vulnerability. In that case after a week only about 5 percent had been upgraded and it was only up to about 15 percent at two weeks.

What is more troubling is how few websites have been upgraded to the previous release, Drupal 7.31, which fixed a moderately critical vulnerability. That version was released on August 6, so there has been plenty of time for an upgrade. As shown in the chart below, at this point 62 percent of Drupal 7 websites are still running a version below that:

Drupal 7.32: 12.46%, Drupal 7.31: 25.74%, Drupal 7.30 or older: 61.80%

For those in need of an upgrade we provide one time Drupal upgrades and ongoing upgrades for Drupal 7 (with security updates in a day). You can use our Drupal Version Check chrome extension and Up to Date? Chrome app to keep track of the update status of Drupal websites you manage.

Posted in Drupal, Outdated Web Software | Leave a comment

6Scan Is Bad At Detecting Malicious Code

From dealing with lots of hacked websites one of things that we know is that detecting malicious code through automated processes isn’t very effective. The variety of code makes it difficult, but what makes it much more difficult is that often the code appears to be designed to be able to avoid detection from these automated processes (which in turn usually makes it easy for a human to spot). Unfortunately other companies dealing hacked website haven’t figured this out or are not interested in making sure the websites they deal with get fully cleaned and secured, leading to many instances where we are hired to re-clean up hacked websites after they have failed to get the job done. One of the latest examples we saw was of a web host using 6Scan on a hacked website. 6Scan describes their services as “Powerful Automated Website Protection” and they describe their ability find malicious code with the following, “You might not be aware if your site has already been compromised, but our scanner will recognize the traces hackers leave behind. You’ll see immediate results—as comprehensive as they are easy to understand—displayed on our dashboard.”. Though, from what we saw it is at least a rather poor malicious code scanning tool.

At the point we were brought what had happened is that the web host for the website would detect the website was sending spam emails, suspend it, run 6Scan on it and remove the files they detected as malicious, and then after some amount of time spam email would get sent out again and the process would start over. What a quick check of the website’s files showed was that 6Scan was not detecting much of the malicious code and that meant the hacker still had access after the code they were detecting was removed. Considering that the web host in question is touted on 6Scan’s homepage as one of their “Trusted Partners” we don’t think that they were doing something wrong in use of the tool that lead to the poor detection.

The 6Scan scan that was run right before we did our clean up detected 54 files with malicious code and missed the malicious code in 40 other files, so their detection rate was not very good at only 57 percent. What was more surprising is how easy to spot most of the files they missed were. Many of the files were stored in the wp-admin and wp-includes directories of a WordPress website. Since those two directories generally should only contain files that come with WordPress any additional files would be a red flag. In other cases malicious code was added to core WordPress files that shouldn’t be modified, which also would be a red flag. In both cases someone reviewing the results of a file comparison with a clean install of WordPress would have easily noticed the malicious code, while 6Scan’s automated processes did not.

There are a few of important takeaways from this. First, if someone says they are going to clean up a hacked website with automated tools, you are going to want to find someone else to do it. You might get lucky with a hack that is rather simple and the malicious code gets fully detected, but if you don’t then it is going to mean multiple cleanups and in some cases more problems. It also important to hire someone that will determine how the website was hacked in the first place, as doing that and fixing the vulnerability is the way to protect against the hack happening again (that was certainly important for us to fully clean up the website in this instance). The final one is that you should avoid 6Scan as they either don’t understand that the service they provide can’t do what they claim or they know that it can’t don’t care. Instead you should spend your time and money on making sure you do things that will actually protect your website from being hacked in the first place, so someone like us doesn’t have to clean up after it gets hacked.

Posted in Bad Security, WordPress | Leave a comment

Hackers Still Trying To Exploit Joomla 1.5 Vulnerability Fixed Six Years Ago

We were recently checking something in our analytics and noticed that a rather odd URL had been accessed. The URL, http://www.whitefirdesign.com/blog/?option=com_user&view=reset&layout=confirm, was for a section of our website running WordPress but the URL parameter, ?option=com_user&view=reset&layout=confirm, was for something Joomla related based on the “com_user” portion. A quick search identified that this was an attempt to exploit a vulnerability in older versions of Joomla. What is interesting about this is that the vulnerability was fixed in Joomla 1.5.6, which was released in August of 2008. Since most hacking attempt will not show up in analytics – due to them not requesting the tracking code – we were curious to see if there had been other attempts to exploit this that would show up in our access logs. We found that in the last six months there were attempts to exploit the vulnerability on 48 days. So hackers still feel there are enough Joomla website that haven’t been updated in six years to try to exploit it regularly.

There are a couple of quick takeaways from this. One is that is that if you still have websites running Joomla 1.5, for which support ended in September of 2012, you should make sure they have been upgraded to the last version, 1.5.26, and had the additional security fix applied so that they are protected against attempts to exploit any vulnerabilities in older versions. The other is that you don’t need concerned just because there has been an attempt to exploit a vulnerability on your website, considering that in this case a hacker tried to a vulnerability in very old versions of Joomla on a website running WordPress.

Posted in Joomla, Website Security | Leave a comment

Your Website Probably Wasn’t Hacked by a Competitor or Former Employee

When first discussing with a potential client about dealing with a hacking issue on their website what often comes up are questions about who hacked them and why. On a fairly regular basis they suspect it was a competitor or someone previously involved with the website. In reality the person hacking the website is almost always going to be someone who has no knowledge of the specific website, much less has any connection to it. These hackers are not targeting specific websites, instead they are just trying to gain access to as many websites as possible to use for their own purposes. To get a better idea of what is going on lets take a look at a hacking on a fairly high profile company’s website.

A recent hack we looked at involved a website having a set links added to the website’s page when Google crawled them (this is referred to as cloaking). Several of the links stood out, as they were to pages on justborn.com. You might not recognize the company the website belongs to, Just Born, but you probably are familiar with their products, which include Peeps, Mike and Ike, and Hot Tamales. When visiting one of the linked pages, http://www.justborn.com/services.cfm, the website looks normal at the top but then as you look farther down the page it has repeating text about soccer jerseys:

just-born-spam-hack-1

In fact all of the main content of the page is like that (click to enlarge):

just-born-spam-hack-2By comparison the page it looks like the hacker based the spam page on, http://www.justborn.com/mike-and-ike/the-story, has normal content:

just-born-spam-hack-3

Creating a page on their website with a bunch of text about soccer jerseys wouldn’t make much sense for a competitor or a former employee to do, so what is the purpose of this? Well if you come to the page through a search engine you are redirected to http://www.jerseysokbuy.com/, which as the address suggests is selling jerseys. If you do a search on their address on Google the second result is a page on ScamGuard that describes the website as a “Fake merchandise web-store operating from China. Consumers are advised to avoid making purchases from this site.“. Due to how Google ranks pages this type of hacking can lead to getting pages on websites otherwise unrelated to the product to rank highly. For example, earlier this year we found that a hacking campaign was able to get a website to rank in the top ten for UGG boots, the problem as shown in one of the screenshots in that post is that Google will usually catch up with this eventually and label the website as being hacked. That is part of why the hackers try to get access to as many websites as possible so they can switch to new websites when the old websites get labeled or the webmaster catches on and cleans up the hack.

Interestingly, while someone involved with the webiste is hacking other websites to direct to traffic to jerseysokbuy.com, they don’t appear to be interested in getting traffic directly to their website as the listing for their own website in Google says “A description for this result is not available because of this site’s robots.txt – learn more.”.

 

 

Posted in Website Hacked | Leave a comment

SiteLock Doesn’t Do Basic Part of Proper Hack Cleanup

A few weeks ago we wrote about the web security company SiteLock failing to do a basic security check, checking to make sure software running on a website was up to date when labeling before labeling the website as secure. Based on that we weren’t surprised at our next interaction with their work.

A couple of days ago we were contacted by someone who looking for help after their website had been hacked and SiteLock had been hired to clean it up. After SiteLock had said that they had removed all the malware the owner of the website had requested their web host to bring the website back online. The web host told them that they couldn’t do that since they detected files for outdated software, Joomla 1.5.25, on the website (despite the website using Joomla 2.5). At that point we were contacted about finding and removing those files and in reply we told them they should go back to SiteLock since that should be something SiteLock should do for them. In response they let us know that SiteLock told them they “don’t have the capability to remove or update outdated CMS content”. That is rather troubling since getting the software running on a hacked website up to date is a basic part of a hack cleanup, as it is a basic part of making a website secure. In this type of situation, where a proper hack cleanup hasn’t been done we would only get involved if we are going to do a full cleanup, since we don’t want to be involved in leaving a website insecure, so we suggested that since they were only interested in having the Joomla 1.5.25 files removed they could probably find someone else to do it for less than having a full cleanup done.

The idea that a company is cleaning up hacked websites without doing such basic part of the work is pretty troubling, so we wanted to double check that it wasn’t just that they were refusing to remove some out of date files and instead that they don’t actually update the software running on the website when doing a cleanup. Since the website is running Joomla it is easy to check if the website is up to date with our Joomla Version Check extension for Chrome. After the website came back online we checked and found that website was running an outdated version:

Joomla version 2.5.22

That confirms that SiteLock isn’t doing some of the basic work of the hack cleanup, which is pretty good reason to not to use them for that or any other service they provide since they don’t appear to actually be interested in properly securing websites.

Posted in Bad Security, Outdated Web Software | Leave a comment