There Should Need to Be Evidence That Security Measures Are Effective, Not Ineffective

When it comes to security advice for websites, there is a nearly endless supply. What there decidedly isn’t is an abundance of is testing or other evidence presented that the measures mentioned in that advice are effective.

That seems particular acute when it comes to advice to use paid security products and services, for which we have frequently see bold claims about their effectiveness in their marketing materials, but we have seen almost no evidence presented as to their effectiveness (when it has, it hasn’t been very reliable, for example, one company claimed to have had independent testing done, when the testing decidedly was not independent).

That brings us to a couple of recent comments on one of the posts on the blog for our Plugin Vulnerabilities service.

We had noted that a lot what is supposed to provide protection doesn’t actual do that and cited our testing to see if WordPress security plugins could protect against real vulnerabilities in other plugins:

A lot of what is portrayed as protecting, including a lot of security hardening, doesn’t actually provide any protection. There is even a term for that type of thing, security theater. That is part of the reason we started doing testing of security plugins against real vulnerabilities, to show what, if any, protection they provide. So far BulletProof Security hasn’t provided any, which is what brought this up in the first place.

The response we got to that was this:

This is a big claim and it is one you would need to back up with some proof, especially given that so many people rely on them to protect their websites. Please point me to articles which back these statements. As a typical web dev customer who spends time hardening sites, and promoting a secure WP service, I’m unconvinced about your claims.

This seems to us to be backwards, the onus should be on proving something actual provides protection. Just because a lot of people are doing something that doesn’t mean that is effective, especially since a lot of people are following advice from others that don’t actual have the experience needed to be a reliable source.

Now in reality we have also written plenty about this sort of thing from years ago when we wrote about how hiding the WordPress version isn’t an effective security measure (this seems to have dropped off as claimed important security step) to the currently very popular, but false, claims that there are a lot of attempts to brute force WordPress admin passwords (which are pushed by security companies that then tell you their product or service is the solution). That second item is also a good example of why evidence is important, because we were actually able to disprove the claim based on the evidence that security companies were presenting as supporting it.

It Looks Like SiteLock is Scamming People

Over the past couple of years we have run across a lot of bad stuff involving the security company SiteLock, from not doing basic security checks to not doing basic parts of hack cleanups to breaking websites they are supposed to be cleaning to labeling a website that is very dangerous for visitors as being “secure”. Unfortunately those kinds of things are really par for the course when it comes to security companies (it is a really sleazy industry in general). But recently we have started to see and hear more that indicates that SiteLock has gone past that and moved to more egregiously cheating their customers. Making this more of  a problem, is that they now have partnerships with many web hosts, which gives them additional legitimacy that they shouldn’t have considering the multitude of problems we have see involving them.

One of the issues that we see coming up a lot involves SiteLock charging a monthly fee to protect websites and then when the website gets hacked they want a much larger amount to clean up the website. If the website is getting hacked then the protection being paid for doesn’t seem to be actually happening or isn’t very good. There also seems to be an incentive for the protection they provide to not actually protect, since they can actually make even more money if it doesn’t work.

The other that comes up is fairly frequently is them contacting people claiming that a website has been hacked and that they can clean it, without SiteLock actually checking to see if the website is actually hacked. One example of that we were contacted about involved a website that had been actually hacked, for which the person who took over resolving that decided to start fresh, only reusing the domain name. So the website would have been clean at the point that SiteLock contacted them, which didn’t stop SiteLock from charging them for a cleanup:

When the site was hacked, the domain was blacklisted by every major blacklister, however,since I built the new site from scratch, it was clean when it went live. In spite of that, Sitelock contacted me the day after bringing the new site live that they were in the process of cleaning malware from the site and to contact them as it was going to involve manual removal and additional costs above what the plan that came with WordPress covers. They offered me two options, 300 to clean the site and submit to the blacklisters for review or 299 (in three installments) to clean the site and provide manual removal coverage for three months, after which I could continue with the scan and removal tool and add manual removal coverage for 49.00 per month from then on.

Beyond the fact that SiteLock was charging them for an unneeded cleanup, a website shouldn’t need continuing removals of malicious code. If that is the case, that would usually indicate that the original hack cleanup wasn’t done properly and the hacker could get back in, in that case the person who did the original hack cleanup should go back in and get the issue fixed for free (we certainly would want to do that for a client).

What SiteLock then did for that monthly fee doesn’t sound great either:

I have not been able to make it even a week (in two months) without Sitelock sending me some scary critical security warning email concerning the site. One of them said that they were cleaning malware, which I had a hard time believing since I had really good passwords, 2 step verification and login limiting onthe site. It turned out, the “malware” was a file that was created when I installed the Ithemes security plugin.All the other warnings were the result of them constantly not being able to connect and access the files in ordder to scan, which I don’t understand since I had not changed the passwords and each time, the problem ended up being resolved without a clear explanation as to how or why it happened in the first place.

Based on what we are seeing we have some recommendations if you are contacted by SiteLock or if your web hosts is recommending using them:

Get a Second Opinion

Based on what we are seeing it sounds like SiteLock sometimes is claiming that websites have been hacked that haven’t actually been hacked, so it would be a good idea to get a second opinion as to whether you have been hacked when you are contacted by them.

This is a good idea in other instances as well, since we sometimes see web hosts claiming a website has been hacked due to issues that were caused by something that was actually unrelated to a hack or them not double checking results of antivirus scanners (which can produce some bad false positives).

We are happy to do a free check to see if a website is actually hacked (we always will do that before taking on the clean up of a hacked website), so we are happy to provide you with a second opinion.

Hire Someone Who Properly Cleans Up Hacked Websites

If your website has in fact been hacked it is important to make sure you are hire someone that does a proper hack cleanup. You don’t want to be like many of our clients who hire to us to re-clean their hacked website after the first company they hired didn’t do those things.

The three main components of a proper hack cleanup are:

  • Cleaning up the malicious code and other material added by the hacker.
  • Securing the website (that often means getting the software on the website up to date).
  • Attempting to determine how the website was hacked.

While determining how the website was hacked is often not possible to do due largely to web hosts failure to store log files on a long term basis (something that we found SiteLock had not rectified with at least one of their hosting partners), we have found going through the process is important to get a hacked website fully cleaned. If the source of hack hasn’t been determined then that increases the chances that the security issue hasn’t been resolved and that the website will get hacked again.

We would recommend asking the companies what there hack cleanup service involves and if they don’t mention that they do those things, then you probably should look elsewhere.

Securing Your Website

One really important thing to understand it isn’t naturally for websites to get hacked. For that to happen something must have gone wrong. So the solution to keeping your website secure is to make sure you are taking the proper security measures with your website, instead of going with a security product or service that doesn’t do those things and instead make bold claims that it will keep you secure some other way.

It also important to understand that the chances of a website being hacked are pretty small, so when you see people saying that they use a service and haven’t been hacked, it is entirely possible that the service had nothing to do with them not being hacked.

WordPress Leaks Potentially Sensitive Information From Private Posts and Pages

Over at our Plugin Vulnerabilities service we are in the process of trying to help to get a fairly serious security issue with a WordPress plugin fixed. In the process of doing that we have noticed an issue with WordPress that impacts more than this plugin. Without getting into the details of it, since a fix is still in progress, the plugin created WordPress pages which provide access to non-public data. These were accessible by the public, which was a problem. As part of trying to fix this, these pages were intended to be made private (we say intended because that wasn’t done right). This would have worked in private pages were totally private, but it turns on they are not.

Here is how the WordPress documentation describes what the impact of setting a post’s or page’s visibility to private:

Private content is published only for your eyes, or the eyes of only those with authorization permission levels to see private content. Normal users and visitors will not be aware of private content. It will not appear in the article lists. If a visitor were to guess the URL for your private post, they would still not be able to see your content. You will only see the private content when you are logged into your WordPress blog.

Despite the claim that “normal users and visitors will not be aware of private content”, that isn’t totally true. If you have your permalink structure set to include the title of the page in it, which is fairly common set up, then someone can find out the titles of private posts and pages.

You do that by taking advantage of WordPress’ automatic redirection from plain URLs to the chosen permalink structure. Lets say a post with ID number 12 was titled Surprise Party For Julie In Accounting, when accessing

WordPress Releases Version 2.6

WordPress to automatically redirects you to

The page you see though gives no indication that a private page exists, as the documentation suggest:

Oops! That page can’t be found. It looks like nothing was found at this location. Maybe try a search?  Search for:

By enumerating through potential ID numbers you can see what the titles of all private posts and pages on a website are.

Coming back to the plugin, the title of those pages contains enough information to allow some access the non-public data. While the plugin shouldn’t have you used pages in the way it did, we suspect that in other cases private posts or pages could also contain sensitive information in the title that isn’t meant to be public, as it is now.

After noticing this we thought that we should bring this to the attention of the WordPress developers since it doesn’t seem like this should be this way. It turns out that someone already did that 8 years ago, back around the time of WordPress 2.3.1. But 7 years ago that ticket was closed and marked as “wontfix”. Maybe there was some good reason for that, but the only comment included with that change was “there’s a dup of this one somewhere, and it shoud get wontfixed too.” The fact that a potential security issue was treated in this way is more than a little concerning.

Does the Vulnerability Fixed in WordPress 4.2.1 Also Impact WordPress 3.7, 3.8, and 3.9?

Update (May 7, 2015): WordPress has now released versions 3.7.8, 3.8.8, and 3.9.6 that fix the vulnerability described below.


Last week a vulnerability in WordPress was disclosed and fixed in version 4.2.1. While WordPress only officials supports one version at a time, since the introduction of automatic updates in WordPress 3.7 they have been releasing security updates for all older releases that include the automatic updates feature. This time though only updates for 4.0 and 4.1 were released.

An update for 3.9 has a Codex entry, which indicates that the version, 3.9.6, was released to deal with this. But that version doesn’t appear to exist. Updates for 3.7 and 3.8 also had Codex entries, but those entries were deleted last Friday.

We were curious as to what was going on (as are others) since knowing the full implications of vulnerabilities that impact WordPress is important when we are cleaning up hacked WordPress websites. So we decided to do some testing to see if the vulnerabilities actually impacted versions 3.7-3.9 and they haven’t been fixed or if those versions are not vulnerable.

When using the sample exploit code provided for the vulnerability we found that vulnerability is not exploitable in versions 3.7-3.9 in the form given. The reason for this is that in WordPress 4.0-4.2 a character near the beginning of the malicious comment is encoded:

<a title=&#8217;x onmouseover=alert(unescape(/hello%20world/.source))

That allows the malicious code that begins “onmouseover” to be executed. In 3.7-3.9 that encoding doesn’t occur:

<a title='x onmouseover=alert(unescape(/hello%20world/.source))

So the “onmouseover” is treated as part of the title attribute instead of as code that should be executed, so no malicious code is run.

The underlying problem that leads to all of this, that WordPress didn’t properly check to make sure that comments longer then could be stored are properly handled also does exist in these versions, so it is possible somebody could figure out another way to exploit this in versions 3.7-3.9. If you are still running 3.7-3.9 we would recommend you upgrade to at least 4.0.4 as soon as possible. Though, it would be best that anyone still running a version below 4.2.1 to upgrade to that version.

Be Careful With Your Website’s Backup Files

When a high profile website gets hacked it always useful to see what lessons can be gleamed to insure that other websites don’t get hacked. Several days ago the technology website Ars Technica (who doesn’t have the best track record with security reporting) was breached, while the details on how they were hacked are somewhat limited, one thing stood out (emphasize ours):

At 20:00 CT on December 14, an Internet intruder gained access to one of the Ars Web servers and spent the next hour attempting to get from the Web server to a more central machine. At 20:52, the attempt was successful thanks to information gleaned from a poorly located backup file.

That is a good reminder that since backup files often store sensitive information (including database login details and user info), securely storing them is important to the security of your website. For example, you would not want to store the backup in a file named in the root of your website since hackers will go looking for that as can be seen in the log file entries below from a recent attempt to find backup files on our website: – – [03/Dec/2014:04:11:07 -0500] “HEAD / HTTP/1.1” 404 506 “-” “-” – – [03/Dec/2014:04:11:07 -0500] “HEAD / HTTP/1.1” 404 506 “-” “-” – – [03/Dec/2014:04:11:08 -0500] “HEAD / HTTP/1.1” 404 506 “-” “-” – – [03/Dec/2014:04:11:09 -0500] “HEAD / HTTP/1.1” 404 506 “-” “-” – – [03/Dec/2014:04:11:10 -0500] “HEAD / HTTP/1.1” 404 506 “-” “-” – – [03/Dec/2014:04:11:12 -0500] “HEAD / HTTP/1.1” 404 506 “-” “-” – – [03/Dec/2014:04:11:12 -0500] “HEAD / HTTP/1.1” 404 506 “-” “-” – – [03/Dec/2014:04:11:14 -0500] “HEAD / HTTP/1.1” 404 506 “-” “-” – – [03/Dec/2014:04:11:15 -0500] “HEAD / HTTP/1.1” 404 506 “-” “-” – – [03/Dec/2014:04:11:15 -0500] “HEAD / HTTP/1.1” 404 506 “-” “-” – – [03/Dec/2014:04:11:16 -0500] “HEAD /whitefirdesign.rar HTTP/1.1” 404 506 “-” “-” – – [03/Dec/2014:04:11:17 -0500] “HEAD / HTTP/1.1” 404 506 “-” “-” – – [03/Dec/2014:04:11:18 -0500] “HEAD /whitefirdesign.7z HTTP/1.1” 404 506 “-” “-” – – [03/Dec/2014:04:11:19 -0500] “HEAD /whitefirdesign.xls HTTP/1.1” 404 506 “-” “-” – – [03/Dec/2014:04:11:20 -0500] “HEAD /whitefirdesign.xlsx HTTP/1.1” 404 506 “-” “-” – – [03/Dec/2014:04:11:20 -0500] “HEAD /whitefirdesign.sql HTTP/1.1” 404 506 “-” “-” – – [03/Dec/2014:04:11:21 -0500] “HEAD /back.rar HTTP/1.1” 404 506 “-” “-” – – [03/Dec/2014:04:11:22 -0500] “HEAD / HTTP/1.1” 404 506 “-” “-” – – [03/Dec/2014:04:11:23 -0500] “HEAD /back.7z HTTP/1.1” 404 506 “-” “-” – – [03/Dec/2014:04:11:23 -0500] “HEAD /back.xls HTTP/1.1” 404 506 “-” “-” – – [03/Dec/2014:04:11:24 -0500] “HEAD /back.xlsx HTTP/1.1” 404 506 “-” “-” – – [03/Dec/2014:04:11:25 -0500] “HEAD /back.sql HTTP/1.1” 404 506 “-” “-” – – [03/Dec/2014:04:11:26 -0500] “HEAD /backup.rar HTTP/1.1” 404 506 “-” “-” – – [03/Dec/2014:04:11:27 -0500] “HEAD / HTTP/1.1” 404 506 “-” “-” – – [03/Dec/2014:04:11:28 -0500] “HEAD /backup.7z HTTP/1.1” 404 506 “-” “-” – – [03/Dec/2014:04:11:29 -0500] “HEAD /backup.xls HTTP/1.1” 404 506 “-” “-” – – [03/Dec/2014:04:11:30 -0500] “HEAD /backup.xlsx HTTP/1.1” 404 506 “-” “-” – – [03/Dec/2014:04:11:31 -0500] “HEAD /backup.sql HTTP/1.1” 404 506 “-” “-” – – [03/Dec/2014:04:11:31 -0500] “HEAD /web.rar HTTP/1.1” 404 506 “-” “-” – – [03/Dec/2014:04:11:32 -0500] “HEAD / HTTP/1.1” 404 506 “-” “-” – – [03/Dec/2014:04:11:33 -0500] “HEAD /web.7z HTTP/1.1” 404 506 “-” “-” – – [03/Dec/2014:04:11:34 -0500] “HEAD /web.xls HTTP/1.1” 404 506 “-” “-” – – [03/Dec/2014:04:11:35 -0500] “HEAD /web.xlsx HTTP/1.1” 404 506 “-” “-” – – [03/Dec/2014:04:11:35 -0500] “HEAD /web.sql HTTP/1.1” 404 506 “-” “-” – – [03/Dec/2014:04:11:36 -0500] “HEAD /webroot.rar HTTP/1.1” 404 506 “-” “-” – – [03/Dec/2014:04:11:37 -0500] “HEAD / HTTP/1.1” 404 506 “-” “-” – – [03/Dec/2014:04:11:38 -0500] “HEAD /webroot.7z HTTP/1.1” 404 506 “-” “-” – – [03/Dec/2014:04:11:39 -0500] “HEAD /webroot.xls HTTP/1.1” 404 506 “-” “-” – – [03/Dec/2014:04:11:40 -0500] “HEAD /webroot.xlsx HTTP/1.1” 404 506 “-” “-” – – [03/Dec/2014:04:11:41 -0500] “HEAD /webroot.sql HTTP/1.1” 404 506 “-” “-” – – [03/Dec/2014:04:11:41 -0500] “HEAD /www.rar HTTP/1.1” 404 506 “-” “-” – – [03/Dec/2014:04:11:42 -0500] “HEAD / HTTP/1.1” 404 506 “-” “-” – – [03/Dec/2014:04:11:43 -0500] “HEAD /www.7z HTTP/1.1” 404 506 “-” “-” – – [03/Dec/2014:04:11:44 -0500] “HEAD /www.xls HTTP/1.1” 404 506 “-” “-” – – [03/Dec/2014:04:11:45 -0500] “HEAD /www.xlsx HTTP/1.1” 404 506 “-” “-” – – [03/Dec/2014:04:11:46 -0500] “HEAD /www.sql HTTP/1.1” 404 506 “-” “-” – – [03/Dec/2014:04:11:46 -0500] “HEAD /wwwroot.rar HTTP/1.1” 404 506 “-” “-” – – [03/Dec/2014:04:11:48 -0500] “HEAD / HTTP/1.1” 404 506 “-” “-” – – [03/Dec/2014:04:11:48 -0500] “HEAD /wwwroot.7z HTTP/1.1” 404 506 “-” “-” – – [03/Dec/2014:04:11:49 -0500] “HEAD /wwwroot.xls HTTP/1.1” 404 506 “-” “-” – – [03/Dec/2014:04:11:50 -0500] “HEAD /wwwroot.xlsx HTTP/1.1” 404 506 “-” “-” – – [03/Dec/2014:04:11:51 -0500] “HEAD /wwwroot.sql HTTP/1.1” 404 506 “-” “-”

Unfortunately not every risk is that easy to spot, take for example a vulnerability in the XCloner – Backup and Restore WordPress plugin that we discussed last week that allowed any logged in user to download any backups made by the plugin.

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

Automatically Updating Plugins in WordPress

In WordPress 3.7 a new feature was introduced that causes WordPress to automatically apply minor updates to WordPress (for example, going from 3.7 to 3.7.1). The underlying system that handles that also supports doing automatic updates for major updates, plugin updates, and theme updates as well. The reason for limiting it to minor updates by default makes a lot of sense, because there is a process in place for minor updates to make sure there is a little chance as possible for something going wrong. The lead developer of WordPress describes the process as:

Background updates are incredibly, incredibly safe. Sites already running WordPress 3.7 have attempted more than 110,000 updates without a single critical failure, thanks to a number of verification steps that have made updates that much more reliable. A background update for a minor or security release (which is all they are enabled for, by default) means downloading and copying over just a few files. We’ve gotten really good at that. We’ve also spent years honing our craft of shipping stable and targeted fixes in minor releases — we don’t indiscriminately backport bug fixes. They must be serious bugs, and fixes go through additional levels of review, including at least two lead developers. And, we have the ability to roll out an automatic update over a period of hours or days. For 3.7.1, we’ll likely see how a few hours of user-initiated updates go before telling about 1% of sites to update, then steadily increase that percentage.

Depending on the situation of an individual website enabling other updates to occur automatically as well makes sense. Keeping plugins up to date is an important as it prevents the website from being exploited due to a vulnerability in an outdated version of the plugin. At this point we haven’t seen a vulnerability in WordPress that is likely to lead to the average website being hacked in years, but with plugins that isn’t the case. So keeping plugins up to date is at least as important as keeping WordPress up to date. If you use plugins that have a good track record of not breaking after an update (we haven’t had any issues with the plugins we use on our blogs over many years) then it can make sense to turn on automatic updates for plugins.

Turning on automatic plugin updates can be accomplished by adding the following line to functions.php of your current theme:

add_filter( 'auto_update_plugin', '__return_true' );

If you prefer not to modify your theme you have another option with our new plugin, Automatic Plugin Updates, which enables automatic plugin updates along with providing a couple of additional features. The lesser additional feature is that it turns on email notifications for those automatic plugin updates (this can be disabled). The bigger feature is that it enables disabling automatic updates for selected plugins. This can be useful if you have modified plugins in use or if you have plugins that you are more concerned that an update could cause problems with the website. While you can roll your own code to do this as well, with our plugin you don’t have to worry about changes being made in the process of handling excluding plugin from automatic updates. As of the current beta of WordPress 3.9 the process has changed from previous versions, causing code written for the old versions to not stop the automatic update from happening, and our plugin is already ready to handle that if the change remains in the production release of 3.9. Both of the additional features can be accessed on the plugin’s setting page:

Automatic Plugin Updates Settings Page

Migrating From Joomla 1.5 Won’t Necessarily Clean Up a Hack

Fairly often we have people contacting us about doing an upgrade of software on a website, which they are hoping will resolve a hacking or other security issue. Unfortunately in most instances they don’t tell us that is why they want an upgrade done. In the worst case this could cause the upgrade to get messed up if the hack has made modifications to things that are affected by the upgrade. In many cases the upgrade isn’t going to fully resolve the issue and may not have any impact at all. For example, if a website was running Joomla 1.6, 1.7, or 2.5.0-2.5.2 and it got hacked due to the privilege escalation vulnerability in those versions, which allows someone registering a new account to escalate their account to “Administrator” level, upgrading would prevent new accounts with those privileges from being created but the existing accounts would still exist. Those accounts can be deleted, but you have to know they exist to do that. The upgrade also might overwrite other modifications the hacker(s) made to the website, but it might not.

For website still running Joomla 1.5 the website cannot be upgraded to a newer version. Instead a more complicated migration, which move content from the Joomla 1.5 installation to a new install of Joomla 2.5 or 3. Despite support for that version ending in September of 2012, the version is still widely used and we recently have been contacted about a lot of hacked website that are still running Joomla 1.5. Since the migration leaves a lot of the website behind it would reasonable to wonder if a migration will resolve the hack. A website we were just dealing is reminder that isn’t the case.

There are three major areas where parts of the hack could move over during the migration. First a common place for placing malicious files is in a website’s images folder, which is something that will move over to new website. Another common area where malicious code is placed is in theme files. While Joomla 1.5 themes are not directly compatible with newer versions of Joomla, some can be easily converted to the new version either by hand or with automated tools. The third area, which is where malicious code was in this situation, is the in the database. In this case the malicious HTML code had been added to the content of a number of articles, which was moved over during the migration.

The malicious HTML code (shown below) was relatively harmless; it just added a link to a spam page to the page and used JavaScript code to hide the link. While this won’t harm someone visiting the page, it can lead to Google placing a “This site may be hacked” label in their search results and the lowering the website’s ranking. It was also causing the AVG antivirus software to alert for Exploit Blackhat SEO (type 1703), which is likely to scare away some visitors.

Source Code of Hidden Spam Hack

All the Exploit Attempts Security Products Stop Don’t Necessarily Mean Much

When it comes to the poor state of website security we have a situation where basic security measures often are not taken but security products of questionable value are proliferating. What we see in dealing with websites that have been hacked is that it is harder to get someone to make sure that proper security practices are being taken then it would be to sell them on these questionable security products. One of the things we see that really sells people on these security products is that they will highlight that they have stopped numerous attempts to exploit a website. It sounds impressive, but in reality they may not be stopping anything at all. Let’s take look at an example of why this information doesn’t mean much.

JCE is a popular extension for Joomla. Older versions had a serious security vulnerability  that was fixed in August of 2011. For people that used JCE the simple way to protect themselves against the vulnerability was to keep their software up to date. For anyone not running JCE they didn’t need to do anything since it wouldn’t impact them at all. We would fall in to that second category as we haven’t used Joomla on our website, so there is no chance that we would be running JCE. That hasn’t stopped hackers from attempting to exploit the vulnerability on our website. In March for example our logs recorded 16365 attempts (or about 528 attempts per day) to exploit the vulnerability. Here are the numbers of attempts our logs show for the last six months:

October: 277
November: 362
December: 674
January: 6551
February: 17050
March: 16365

Even in the month with the lowest attempts we had an average about 9 attempts a day. If you are not familiar with the vulnerability and the fact that unless a website was running a fairly out of date version of JCE there is no chance of being exploited then it would certainly sound scary that there were so many attempts. It also wouldn’t seem unreasonable that you would recommend the product to others.

While we wouldn’t recommend security products for most websites (those basic security measures are all that you will need), what you should look at when considering these products is if they have independent testing results showing that they do in have fact protect against vulnerabilities that wouldn’t be stopped by taking basic security measures. You should also consider if they will even protect against threats you face. For example a product designed to protect against exploiting software on your website isn’t going to stop someone from getting in via FTP or from exploiting a web host’s poor security.

Norton Secured Seal Service Doesn’t Do Basic Security Check

Three years ago we posted about the fact that trust marks shown on websites that claim to certify that the websites are secure cannot be trusted to identify if a website is actually secure for a number of reasons, including that in many cases they scan the websites from the outside so there are many things that they would never detect. What we recently noticed is that the Norton Secure Seal service fails to do a really basic security check that can be done from the outside. When it comes to the security of websites one of the basic security measures is to keep the software running the website up to date. This prevents the website from being hacked to the exploitation of a known vulnerability in the software that has been fixed in a subsequent release. As we have found the Norton Secure Seal service doesn’t check to make sure the software running the website they are claiming is secure is up to date.

As an example of this we will take a look at the website of an IT security company that carries the Norton Secure Seal as you can see here:

Norton Secure Seal

Using our Joomla Version Check web browser extension you can see that the website is running an outdated version of Joomla:

Joomla Version Used on Website ShownThat version of Joomla, 3.1.1, is seven months out of date and more importantly subsequent versions have fixed four security vulnerabilities, including a vulnerability rated as having critical severity and a vulnerability rated as having high severity. A website with that level of security issue should not be labeled as being secure.

The technology our web browser extension uses to detect that Joomla is powering a web page and what version is in use is rather simple and there is no excuse for a major company such as Symantec, the maker of the Norton Secured Seal service, not being able to do the same. Providing more awareness that an outdated version of Joomla is in use is definitely needed as outdated versions of Joomla are widely used, including among companies that provide security services for Joomla websites, and some older versions contain a vulnerability that is being exploited by hackers.

It isn’t just Joomla that Norton Secured Seal service doesn’t check to make sure is up to date; the same website has a blog running an outdated and insecure version of WordPress as well:

The eGestalt blog is Running WordPress 3.5.2