Are Your Websites Up to Date?You can keep track of what versions of concrete5, Drupal, Joomla, Magento, MediaWiki, Moodle, PrestaShop, Revive Adserver, TYPO3, SPIP, WordPress, and Zen Cart are running on all of the websites you manage with our Up to Date? Chrome app.
Search This Blog
Web Software Updates
WordPress VersionWe are running WordPress 4.1.1 and despite what many supposed "security experts" claim letting you know what version we are running does not make us less secure.
Did We Make a Mistake?While it seems to be acceptable for blogs discussing web security to contain numerous factual mistakes, we hold ourselves to a higher standard. We only write about things that we actually understand and only after we have double checked the information. So if you see a mistake in one of our posts please leave a comment on the post or contact us so that we can add a correction.
Category Archives: Bad Security
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.
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:
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.
The recent massive credit card breach at Home Depot was yet another reminder that whether offline or online, IT security is often lacking. For consumers the question then is how can they know that their information is secure when they provide it to companies? Numerous security companies have created trust seals – that can be placed on websites if they meet certain requirements – that let the public know that a website is secure. The problem we have found with a number of these is that they are not doing basic security checks and therefore their assurances of security are false. Last week took a look at SiteLock’s and earlier this year we looked Norton’s, now we will look at another bad trust seal that we ran across recently.
While visiting the website of a client’s web host recently our Chrome extension Meta Generator Version Check provided an alert that website was running an outdated version of Joomla:
It obviously isn’t a great sign that web host is running outdated software on their website (especially when that version hasn’t been supported for two years), but what was more surprising was the Trust Guard security verified trust seal at the bottom of the website:
In this case it is easy to detect that the website is running an outdated version of Joomla since there is a meta generator tag in the source code of the website’s pages that tells you exactly that:
<meta name=”generator” content=”Joomla! 1.5 – Open Source Content Management” />
With such an easy to detect security issue a trustworthy trust seal shouldn’t claim that the website is secure. We were curious to find out exactly what security checks Trust Guard was actually doing. Clicking the trust seal brought up a page that explained why they are claiming the website has verified security:
In order for www.hostica.com to qualify for the Trust Guard Security Verified Seal, we verify that their website is using at least 128-Bit SSL Encryption on pages where private information can be entered, such as credit cards, Social Security numbers, loan information, etc. and we monitor the SSL certificates expiration.
While using SSL encryption when sensitive information can be entered is important for security it doesn’t mean a website is secure, just that someone cannot snoop on the information as it sent to the website. For example, we have done plenty of cleanups of hacked websites in which the credit card information was compromised once it made its way to the website. Since a web browser’s user interface already provides notice when a secure SSL connection is in use, it isn’t clear what security value the trust seal is meant to provide, but it doesn’t seem that it out ways how misleading it is to claim that a website’s security is verified based only on the fact that it is using SSL encryption.
When it comes to the security of websites what we see is a situation where basic security measures, like keeping software up to date, are not being taken and security companies, most of whom appear to have little interested in actually improving security, are selling security services that are really not needed. A good example of this is SiteLock, which sells a security service that doesn’t provide any of the security measures that need to be taken to protect your website from hackers. Worse than that, we recently found that it is really poor at doing one of things that it is supposed to do, leading the people running websites and their customers to have a false sense of security.
We recently were hired to do an upgrade of website running Magento 188.8.131.52, a rather out of date version (the next version, 184.108.40.206, was released in December of 2010). When we took a look at the website we were rather surprised to see a security seal from SiteLock claiming the website was secure (we have blacked out the domain name in the image):
Version 220.127.116.11 of Magento is old enough that security patches for major issues are no longer released for it and anyone concerned about security would be running at least the most recent major release, 18.104.22.168, as it includes a number of security enhancements:
- Addressed a potential cross-site scripting (XSS) vulnerability while creating configurable product variants.
- Addressed a potential security issue that could result in displaying information about a different order to a customer.
- Users can no longer change the currency if the payment method PayPal Website Payments Standard is used.
- Removed an .swf file from the Magento distribution because of security issues.
- Improved file system security.
- Enhanced the security of action URLs, such as billing agreements.
- Addressed a potential session fixation vulnerability during checkout.
- Improved the security of the Magento randomness function.
We don’t really think that a website should labeled as secure in that instance, but we assumed that SiteLock had at least provided a private warning that the website was in need of an update. But according to our client they never heard anything from SiteLock about the issue. This is surprising considering it is something that service is supposed to be providing. On the homepage of their website they start the description of their services as “We scan your website to find and fix existing malware and vulnerabilities “. On the page about the service they further expand on that:
Our scanners identify applications you have installed and which version you have. We compare that to industry and proprietary lists to determine the security of your installation. SiteLock’s comprehensive scanning eliminates reports of “false positives” that are not truly dangerous to your business. If we discover a vulnerability in our testing, we report it to you immediately and can help you upgrade your application version and secure your site.
How did SiteLock miss that the website is running such outdated software? It is not because it is difficult to detect. If you have access to the website’s underlying files, which it appears SiteLock would have, then you can easily get the Magento version number from the file /app/Mage.php in Magento. Without access the underlying files you can still get the version number of Magento in use. One way to do that is with our Magento Version Check extension for Chrome, which had no problem detecting the version in use on the website:
For anyone looking for a tool that will actually alert you when your websites are using outdated software our Up to Date? app for Chrome provides just that:
As for the SiteLock service, you would better off using the money you would spend on their service on the things that will actually keep your website secure.
When it comes to the security of websites, keeping the software running them up to date is an important. While web hosts make a point of emphasizing the need to keep the user added software up to date, up to point of often incorrectly jumping to the conclusion that a website must have been hacked due to outdated software, they often fail to their part by keeping the software running the server up to date. In the case of DreamHost, this now not only means that their servers are not properly secured, but also that recent software can’t be used.
The latest version of Moodle, 2.7, requires at least version 5.5.31 of MySQL. This shouldn’t be a problem as MySQL 5.5 is currently the oldest series supported and version 5.5.31 was released 16 months ago. Unfortunately, while we preparing to do a Moodle upgrade for a client hosted with DreamHost we found that they are still on version 5.1.56. Our client contacted them about this and didn’t get any movement on getting this updated. They were not first, as the issue was brought up in May on a thread on DreamHost forum requesting that MySQL be updated. A DreamHost representative replied in the thread before and after that so they should have be aware that it was mentioned.
While the inability to use the latest version of Moodle is of concern, the larger issue is just how out of date DreamHost leaves the software running on their servers. Support for MySQL 5.1 ended at the end of last year, so they have been running an unsupported version for eight months. If they needed to stick to MySQL 5.1 for some reason, then you would expect that would be running the last version of 5.1, but there not. Instead they are running a version that is over three years out of date (5.1.57 was released in May of 2011) and they didn’t update after either of two subsequent releases with security updates were put out (5.1.62 and 5.1.63).
On this blog we focus a lot on the large problem of software on websites not being kept up to date. But the importance of keeping software up to date is misunderstood or misused, leading to more security problems. What we often see with web hosts, and to a lesser degree security companies, is that they tell people that their hacked website must have been hacked due to outdated software. There are a couple of major problems with this. First, websites are often are hacked due to reasons other than outdated software. It could be caused by malware on the computer of someone involved in the website, poor security at the web host, a vulnerability that even exist in the latest version of software, or a variety of other issues. The second major problem is that if you assume that the website was hacked due to outdated software and it wasn’t then the vulnerability doesn’t get fixed and the website could get hacked again (which based on the people that come to us to re-clean hacked websites, happens often). Below we dive into more detail of several of the important points on understanding what role outdated software plays in hacks.
Most Vulnerabilities Are Not Likely to Lead to Your Website Being Hacked
If you look at popular software like Drupal, Joomla, and WordPress they release security updates on a fairly regular basis. While you should be applying those security updates, it is important when dealing with a hacked website to understand that most security vulnerabilities fixed in software are not likely to lead to your website being hacked. For the average website, hackers will only try to hack it using very basic hacks that don’t rely on human interaction, so vulnerabilities that would require targeting your website are unlikely to be used. There are other vulnerabilities that would need to be combined with another vulnerability to be successfully exploited and yet other security vulnerabilities that couldn’t be used to hack your website, for example an old WordPress vulnerability allowed users to view other user’s trashed posts.
When it comes to Drupal, Joomla, and WordPress, only with Joomla have we seen a new vulnerability in the software successfully be exploited in the past few years. So with Drupal and WordPress if somebody is telling you an outdated version caused the hack chances are they are wrong. The vulnerabilities in Joomla could impact websites running 1.6.x, 1.7.x, and 2.50-2.5.2 if user registration is enabled or versions 1.5.x, 1.6.x, 1.7.x, 2.5.0-2.5.13, 3.0.x, and 3.1.0-3.1.3 if untrusted users are allowed to upload files.
When hiring someone to deal with a hacked website, finding someone with expertise with the software you use can be important for understanding what impact the security vulnerabilities in an outdated version of it potentially have and if they could have lead to the website being hacked.
You Need to Determine How the Website Was Hacked
Our experience is that many companies provide hack cleanup services don’t actually do the important task of determining how the website got hacked. While you might get lucky and the vulnerability is fixed without determining what it was first or the hacker doesn’t come back, you shouldn’t bet on that. We often have people comes that had previously had someone else clean up the website and then in short order it gets hacked again. Our first question in those situation is if the source of the originally hacked was determined and we have someone answer that it was, the usual response is that determining the source of the hack was never even brought up.
When it comes to saying that your website must have been hacked due to outdated software, what we have seen is this often not based on any evidence. In fact, in some cases we have seen web hosts blaming outdated software despite the software being up to date at the time of the hack. If somebody tells you that it is the cause they should be able to tell you what the vulnerability is and provide evidence that supports the claim. If the logs of access to the website are available they should be able to show you the relevant log entries showing when the hack was exploited. Unfortunately, in too many cases web hosts do not have good log retention policies so the logs are gone once the hack is discovered, but someone who knows what they are doing should be able to explain why the evidence still available matches exploitation of the vulnerability.
Before you hire someone to clean up a hacked website make sure that determining the source of the hack is part of their service, if it isn’t they are not doing things properly.
You Can Be Up to Date Without Running the Latest Version of Software
We often see people confusing the need to keep software up to date with the need to be running the latest version of the software. While they are the same in some cases when the developers only support one version of the software at a time, in other cases you only need to be running an up to date version of one of the supported versions to be secure. For example, Drupal currently supports versions 6 & 7, so at the moment you should be running 6.31 or 7.28. While newer versions may include security improvements over an older version, the older version should still be secure against hacking as long as it is receiving security updates. Using Drupal as an example, Drupal 7 introduced better password hashing, which improves security but would only have impact on it in a situation where someone has gained access to the database, which they shouldn’t if things are secure.
For those in charge of managing numerous websites you can use our Up to Date? Chrome app to keep track of the update status of websites running Drupal, Joomla, WordPress, and other software all in one place.
When it comes to the security of websites, what we see over and over is that the basics are not even being handled by people that shouldn’t have a problem doing it. If you are running a WordPress website then part of Security 101 is keeping WordPress up to date, as it prevents your website from being hacked due to a known vulnerability in an older version of WordPress. Unfortunately, that isn’t being done in many cases as can been seen in the fact that only 40 percent of WordPress websites were running the latest series of WordPress in the data set we looked at in March.
You would think that providing better management tools would help this situation, though the example of one of the providers of such a tool would say otherwise. ManageWP describes its services as providing you the ability to “Manage all your WordPress sites from one place – including updates, backups, security and more.” You would certainly expect they would be keeping the WordPress installation powering their website up to date, but they’re not:
ManageWP’s failure to take handle a basic security task is sharp contrast to their claims of security. For example, they claim
Securing ManageWP and the sites we interact with has always been our highest priority. We use state-of-the-art encryption and security standards that go above and beyond what WordPress, itself, offers, to ensure that your sites are protected.
On another page they make a series of claims about their security:
How ManageWP Is Secure
- We have a full-time security specialist
- We regularly perform penetration testing
- No credit card information stored
- No WordPress passwords stored
- OpenSSL encryption
- ManageWP is built on top of WordPress
- Account password encryption
- White hat reward program
If you are security specialist who fails to make sure such a basic security measure is taken then you probably should find another profession.
When it comes to IT security companies, what we see over and over is that they have little to no concern for security (and also often have little to no understanding of proper security practices). So it isn’t surprising that despite billions being spent on IT security, IT security continues to be in such poor shape. This leads to situation like the massive breach of Target’s systems last year. While that was big news, what didn’t get much attention was the company who declared Target compliant with standards for handling credit card transactions shortly before the breach, Trustwave. Trustwave has a history of declaring companies compliant shortly before they suffer major breaches and for being lax in their assessments.
We recently spotted another example of their highly questionable practices of Trustwave. We were contacted about doing a migration of a Joomla-based website still running version 1.5, for which support ended in September 2012. While taking a look at the website, we noticed a seal for Trustwave Trusted Commerce:
Considering that the website is running software that is no longer supported and therefore cannot be considered secure, we were curious to see if Trustwave was claiming it was secure. It would be quite easy for them to find that the website is running Joomla 1.5 if they wanted to as the source code of every page on the website the following line is included:
<meta name=”generator” content=”Joomla! 1.5 – Open Source Content Management” />
If you click on the seal you get this page:
At the top of the page Trustwave proclaims that “Your credit card and identity information are secure.”, which they shouldn’t be saying for a website that is running unsupported software.
As we looked closer we noticed the small text disclaimer at the bottom of the page were they say “Trustwave Holdings, Inc. makes no representation or warranty as to whether [redacted] systems are secure from either an internal or external attack or whether cardholder data is at risk of being compromised.”. So they are basically telling you that despite saying “your credit card and identity information are secure”, there not actually saying that at all.
It is highly inappropriate for them to mislead the public like they are doing with this seal, but unfortunately our experience is that this kind of thing is considered acceptable in the security industry.
Recently we have had a lot of blog posts highlighting major organizations running outdated and insecure versions of Drupal, but we don’t want to give the impression that it is only with Drupal based websites that major organizations are failing to keep the software up to date on. So we wanted to find an example of a website running Joomla to highlight as well and we quickly found a very concerning example. The third website listed on Joomla’s showcase of websites running Joomla is the website of Guaranty Trust bank, which is Nigeria’s largest bank and has assets of over 12 billion USD. As you can see with our Joomla Version Check web browser extension, available for Firefox and Chrome, their websites is running a fairly out of date version of Joomla:
That version is over two years out of date and there have been twelve subsequent updates with security fixes. One of the security vulnerabilities fixed in a subsequent version is of particular concern. The vulnerability, which we discussed before, allows a new user account to be created with “Administrator” privileges through privilege escalation. If user registration is disabled this will not work, but in this case it does appear that user registration is enabled. It is important to note that account access portions of Guaranty Trust Banks’ website are separate from the main website, so they are not directly impacted by the lax security of the main website. But it does raise the question of how well they secure the other portions of their website if they are not doing something this basic. Also, if someone could exploit one of the vulnerabilities in the version of Joomla on the main website they could change the links directing people to the account access portion of the website to another location and use that to gather login credentials.
Due to how potentially serious the security issue with their website is we attempted to contact Guaranty Trust Bank as soon as we saw the version they are running, but we were unable to get far. For one of their listed email addresses we got back message that the mail box was full. For the other we were told to “liaise with our Corporate Affairs Unit at the head office”, but our reply asking how to do that was met with a message that the email address we were replying to did not exist.
Last week we spotlighted the fact that only a third of websites running Drupal 7 are up to date. As keeping the software running a website up to date being an important security measure and with the most recent version of Drupal 7 being a security update that obviously is a problem (though certainly not a problem limited to Drupal). What makes this more troubling is that it isn’t just small websites that are not keeping their software up to date, but large institutions that are more than capable of doing the upgrades. In gets worse when you see institutions that have departments focused on the technology security that are failing to keep their software up to date. Last month we looked at the fact that the University of Cambridge was running an outdated version of Drupal, while the blog of their Security Group was running on a very out of date version of WordPress. They unfortunately are not alone.
That version is now a year out of date and two security updates have been missed (7.24 and 7.26). Making sure the website is kept up to date is something that you would hope that Rutger’s University Information Protection and Security Division would be on top of, but they are not even keeping their website up to date:
That website is less out of date than the main Rutgers website as the current version of Drupal 6, 6.30, was released in January, but it was a security update so they should have gotten it upgraded by now.
For those reading this and realizing they need to get their Drupal installation up to date, you can find the upgrade instructions here.