Using Insecure WordPress Plugins?Does your WordPress blog contain known insecure plugins? Check Now
Search This Blog
- Outdated Versions of Joomla 2.5.x and 3.x Widely Used
- Norton Secured Seal Service Doesn’t Do Basic Security Check
- Joomla Hack Cleanup Providers Don’t Care About the Security of Their Own Websites
- Joomla 1.5 Still Widely Used Despite Support Ending in September of 2012
- Checking For Outdated Plesk Installations or InfoRiskToday’s Bad Security
Web Software Updates
WordPress VersionWe are running WordPress 3.8.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: WordPress
Last month we spotlighted at the fact that 31 percent of Joomla websites checked with our Joomla Version Check tool during January were still running Joomla 1.5, for which supported ended September 2012. This month we decided to take a look at if websites that were running a supported Joomla series, either 2.5.x or 3.x, were being kept up to date based on last month’s data from the tool. Unlike websites still running Joomla 1.5 that need a more complicated migration to be brought up to a supported version, the upgrade process for websites running 2.5.x or 3.x is relatively simple. Keeping software running on a website up to date is a basic security measure, so if websites are not being kept up to date when it is relatively easy it shows that website security is in bad shape.
Joomla 2.5.18 was released during the month so Joomla 2.5.x websites would have been up to date if they running 2.5.17 or 2.5.18. Unfortunately 58 percent of the Joomla 2.5 websites were detected as running older versions (for some installations the tool only could tell they were using Joomla 2.5 and those listed as 2.5.x in the chart).
54 percent of the Joomla 2.5 websites checked contain known security vulnerabilities, as they are running versions below 2.5.15, the most recent release with security fixes.
For Joomla 3.x the results are slightly better as only 48 percent were detected running versions prior 3.2.1 or 3.2.2 (3.2.2 was release during the month alongside 2.5.18).
41 percent of the Joomla 3.x websites checked contain known security vulnerabilities, as they are running versions below 3.1.6, the most recent release with security fixes.
Outdated WordPress and MediaWiki Versions Heavily Used Too
The results for the WordPress and MediaWiki websites checked during February using our tools for those pieces software were also not good.
For WordPress 60 percent of the websites checked were running a version below the current series, 3.8.
For MediaWiki 47 percent of the websites checked were running a series no longer supported. The currently supported versions are 1.19.x, 1.21.x, and 1.22.x.
When it comes the security of WordPress there are unfortunately a lot of people out there spreading bad information. We were on the receiving end of one of these in the past few days. We received an email from xpedientdigitalmedia.com trying to get us to promote an infographic on WordPress security from their website WPTemplate.com. You can tell how much they care about security when you see this:Keeping WordPress up to date is one the basic security measures that you need to doing to make sure your website is secure. If you are website about WordPress you have no excuse for not keeping it up to date, especially when the release notice for the new version, that was released last month, warns:
This is a security release for all previous versions and we strongly encourage you to update your sites immediately.
Amazingly their security advice includes making sure to keep WordPress up to date, but they don’t follow their own advice and you shouldn’t either.
It really isn’t worth going through all of the bad information they managed to pack in to their infographic, but here are a couple of really bad pieces of advice:
One of their security recommendations is “Do not install WordPress themes that are available for free.”. Something being free doesn’t make it insecure and something costing money doesn’t make it secure. WordPress is free, would that make it insecure? Do they think that the free themes on the WordPress website are insecure?
The second one is doozy. They claim that one of the “most common ways that result in the site being hacked” is “approving comments that are non relevant”. This isn’t even a way to be hacked, much less a common one. If adding a comment could lead to your website being hacked that would be a huge security vulnerability and the solution wouldn’t be to not approve irrelevant comments. What would stop someone from exploiting the vulnerability with a relevant comment instead?
Unfortunately their bad advice isn’t just on their website. A lot of websites have taken up their offer to spread the thing, including noupe, WP Daily Themes, and WP Daily. Incidentally, WP Daily titled their post on WordPress 3.5.2 UH OH. WP 3.5.2 SECURITY UPDATE. DO THIS NOW. and yet they didn’t:
A Step To Actually Improve WordPress Security
Currently if a plugin in the WordPress.org Plugin Directory is found to have a security vulnerability and it is not fixed the plugin is removed from the Plugin Directory. Unfortunately anyone who is already using the plugin is not provided any alert that the plugin is known to be insecure. We have been pushing for this situation to be handled properly for some time. Until an alert is added in WordPress itself, you can get a more limited version of this functionality using our No Longer in Directory plugin.
In yet another sad sign of how bad internet security is these days, a security company named Checkmarx released findings on security vulnerabilities in WordPress plugins (PDF) while running their own website on an outdated an insecure version of WordPress:
In their report one of their recommendations is keeping plugins up to date:
3. Ensure all your plugins are up to date
Do not ignore all those notification emails of an upgraded plugin version. You can even use a
purposeful WordPress plugin that notifies admins on updates to other installed plugins.
There are also third party services which provide a plugin update notification and
How is it that security companies that seem to understand basic security practices fail to take them with their own websites?
Also, on Checkmarx’s website they tout they are a member of the Open Web Application Security Project (OWASP), which we recently noted also runs their website on outdated and insecure software.
Another Security Recommendation for WordPress Plugins
Checkmarx’s report is missing one important step that should be taken related to security of WordPress plugins. Currently if a plugin in the WordPress.org Plugin Directory is found to have a security vulnerability and it is not fixed the plugin is removed from the Plugin Directory. Unfortunately anyone who is already using the plugin is not provided any alert that the plugin is known to be insecure. We have been pushing for this situation to be handled properly for some time. Until an alert is added in WordPress itself, you can get a more limited version of this functionality using our No Longer in Directory plugin.
We have had a number of people contact us about having issues gaining access to the login page in WordPress recently and we wanted to pass along information that affected websites should be getting told by their web hosts as well by now. There has recently massive attempt to brute force the login for WordPress based websites. Hostgator describes it as being a highly-distributed and global attack. While hackers have been attempting to gain access to website, whether using WordPress or a variety of other software, that use weak passwords for years, the big issue here is that the massive size of attempts is causing high load on servers and that has caused web hosts to block access to the WordPress login page while attempting to deal with this. If your website is hosted on a server shared with websites being targeted it can impact your websites even if you are not targeted.
Hostgator has reported seeing over “90,000 IP addresses involved in this attack”, which means that a web host cannot simple block a few IP address to stop the attempts. That also provides a reminder that limiting login attempts by blocking IP addresses after several failed attempts has a serious limitation as security feature when massive amount of IP address are available for an attack.
While security of the login process can be improved by restricting login access to certain IP addresses or using multi-factor authentication, websites can prevent an un-targeted login attack by making sure only strong passwords are used.
As part of our continued focus on the problems related to the security of WordPress plugins, last month we compiled some statistics on plugin vulnerabilities found during the second quarter of 2012. As they might be useful to others we wanted to share them.
We used Secunia’s advisories for our data set as their advisories include vulnerabilities discovered by the developers of the plugins and those discovered by others, which provides a good mix of data. Secunia reviews the reported vulnerabilities so their advisories do not include false reports of vulnerabilities that we find in other sources of vulnerability data.
It is important to keep in mind that the vulnerabilities found are not necessarily representative of what vulnerabilities remain in plugins. A lot of what determines what vulnerabilities are found is what kind people happened to look for or find.
A few more quick notes on the data: we have excluded a plugin that was not ever available in the WordPress.org plugin directory, the data was generated on July 16, and the numbers in the charts do not correlate with each other as some plugins had multiple vulnerabilities.
This chart shows the breakdown of the types of vulnerabilities found in the plugins:
The largest percentage were reflective cross-site scripting (XSS) vulnerabilities, which, while serious, are not a kind of that are likely to be used in an targeted hack of a website so they are not a major concern. The second largest group of vulnerabilities was unrestricted file upload vulnerabilities. This type of vulnerability can be easily exploited to place backdoor script on a website, which a hacker can then use to do pretty much anything on the website. Some may be familiar with the TimThumb vulnerability, which was this type of vulnerability. That so many unrestricted file upload vulnerabilities were found is a good reminder of need for plugins with file upload capabilities to be carefully scrutinized to insure that plugins with this type of vulnerability are not available in the plugin directory.
This chart shows the number of plugins with vulnerabilities that have been fixed and not fixed:
That over a quarter of the plugins have not fixed is troubling, but even worse is the types of vulnerabilities in those plugins:
A third of those vulnerabilities are unrestricted file uploads. Not surprisingly due to the ease of exploitation and power granted, we have been seeing attempts to exploit the plugins found to have those vulnerabilities.
There is good news, plugins with unresolved security vulnerabilities are getting removed from the WordPress.org plugin directory, which had not always happened in the past. That is partly due to our making sure that plugins with unresolved security vulnerabilities are reported to the people maintaining the plugin directory, so that they get properly handled. Removing the plugins does not help when the plugin is already installed and that is why WordPress needs to provide alerts for removed plugins with unresolved security vulnerabilities. In the mean time you can use our plugin No Longer in Directory to check if you are using plugins that have been removed. If a removed plugin has a Secunia advisory that will be linked to in the plugin’s report.
SC Magazine Australia’s recent article “50,000 sites compromised in sustained attack” incorrectly claims that WordPress was associated with a past malware campaign and tries to link general security issues to WordPress. As we continue to see the harmful impact of the bad security information, particularly when it involves WordPress, we want to clear up some of the claims in the article and fill in the critical missing information on actually protecting against security vulnerabilities in WordPress plugins.
The most blatant error in the article comes near the end of the article where it is stated that “Vulnerabilities in WordPress plugins have been long understood. Last year, large malware campaigns including the LizaMoon attacks exploited those holes” The LizaMoon attack was part of a frequently hyped multiyear campaign that targets ASP and ColdFusion based websites that have fairly basic SQL injection vulnerabilities. It had nothing to do with WordPress or any WordPress plugins. The link they provide about the LizaMoon attack makes no mention of WordPress and we are not aware of any source that ever claimed that it had a connection with WordPress. The rest of the article isn’t much better. Earlier it says:
Attackers targeted holes in a string of plug-ins for blogging software — such as WordPress— including timthumb, uploadify and phpmyadmin.
None of those things are themselves plugins for WordPress or other blogging software, nor is blogging software the only thing targeted by hackers. We probably deal with as many websites that are hacked due to outdated Joomla extensions as WordPress plugins, so there doesn’t appear to be a good reason to spotlight WordPress for special attention as the article did.
phpMyAdmin is web based administration tool for MySQL database. Several years ago there was WordPress plugin that added phpMyAdmin to WordPress which contained an exploitable vulnerability, but at this point it isn’t a major target of hackers as the plugin was removed back then. phpMyAdmin itself is frequently probed for on our website, so that is likely why phpMyAdmin would be listed as being targeted. That doesn’t explain why it be listed as a being a plugin for WordPress or other blogging software, though.
The TimThumb and Uploadify libraries are included in some WordPress plugins and those have been targeted (though since we last discussed recent serious security vulnerabilities in WordPress plugins we have seen attackers expand from targeting just the recent Uploadify based vulnerabilities to the other upload vulnerabilities recently identified).
Later in the article it claims then claims that Plesk is being targeted (web hosts are not always good about keeping that up to date), so it appears somebody involved in the article just threw together an incomplete list of software that gets targeted without any specific relation to the malware mentioned, while singling out WordPress.
Another worrisome aspect of the article is that it cites a “malware researcher” from Sucuri, the company that has a malware scanner that doesn’t actually bother to scan a website for malware before falsely flagging it.
Protecting Against WordPress Plugin Vulnerabilities
What the article lacks, as stories about hacks often do, is any information on protecting websites from the vulnerabilities they are warning about. For WordPress plugin vulnerabilities, you would hope the answer is to update your plugins, as by the time a vulnerability is being exploited it should have already been patched. Unfortunately, in an analysis of WordPress plugin vulnerabilities in the second quarter of 2012, that we just did, we found that a fourth of the plugins had not been fixed (we will have a post with the full details of the analysis in the next few days). What makes this even worse is that most of the vulnerabilities in those plugins were serious vulnerabilities that are the most likely to lead to website being hacked. So what happens when plugins are not fixed?
When the maintainers of the WordPress.org Plugin Directory are made of aware of a security vulnerability in a plugin they will remove the plugin from the directory until it is fixed. Unfortunately, when we started looking into this earlier this year we found that many plugins had never been reported and had remained in the directory including one in which hackers were attempting to exploit at the time. Since then we have been making sure that any plugins with reports of unresolved security vulnerabilities are reported and appropriate action is taken (we have also been warning them about security issues that impact plugins, including notifying them about the recent Zend Framework vulnerability that impacted several plugins). While removing the plugins until they are fixed prevents any additional websites from being exposed to the vulnerabilities, websites already using the plugins don’t receive any warning and remain vulnerable as we have discussed before. The process of adding alert in WordPress when plugins that have been removed from the Plugin Directory are installed has begun and you can help to make sure it is given a high priority by voting for implementing that change. Until an alert is added in WordPress itself, you can get a more limited version of this functionality using our No Longer in Directory plugin (we released update for the plugin, with new vulnerabilities, at the beginning of the week).
Currently when a WordPress plugin is reported to have a security vulnerability it is removed from the WordPress.org Plugin Directory until the vulnerability has been resolved, but no warning is provided to anyone who already installed it. While many plugins are promptly fixed, there are quite a few that remain vulnerable for a long time or are never fixed. We think that WordPress should alert on the Installed Plugins page in WordPress if an installed plugin has been removed from the directory and provide at least a general reason it has been removed, as many are removed for reasons other than security vulnerabilities, so that appropriate action can be taken by admins. If you would also like to see that happen you can help by voting for our idea on the Ideas section of WordPress.org. To vote you will first need to create a WordPress.org Forum account (or log in if you already have account) and then you can rate the idea by clicking on one of the stars under the heading Rate This (click the right most star for the highest rating for the idea). You can also add your own comments on how the issue should be handled.
Until an alert is added in WordPress itself, you can get a more limited version of this functionality using our No Longer in Directory plugin (we just released our beginning of the month update for the plugin).
While we are discussing the issue of plugin vulnerabilities, we should say that since our last post about this we have been seeing that plugins with Secunia advisories for outstanding issues are being promptly removed from the Plugin Directory until those are resolved. This is great improvement from earlier this year when we found that vulnerable plugins had remained in the directory for years. With that happening we are now looking to make sure that they maintainers of the Plugin Directory are aware of any vulnerabilities which haven’t received Secunia advisories. We just reported a plugin that was found to have a fairly serious information disclosure vulnerability to them and they promptly took action (we alerted the developer of the plugin a week ago and had not received any response). For anyone that finds a vulnerability in a plugin available in the Plugin Directory and is unable to get a response from the developer, you can find directions for contacting the Plugin Directory here.
Nearly four months ago a Panda Security web server was hacked into and about two dozen of their websites were defaced, including the PandaLabs Blog. It is probably reasonable to be concerned that a major computer security company isn’t able to keep their websites from being hacked, but once they have been hacked the more important issue is how they respond going forward. Do they promptly take actions to insure they are now following best security practices or do they do the least possible to resolve the issue?
When it comes to website security, the number one thing you are probably are going to hear is that you need to keep your software up to date. By doing this you prevent a known vulnerability in the software from being exploited (assuming the software’s developers promptly fix security issues). When it comes to keeping web software up to date WordPress is one of the best, if not the best, at making the update process easy, so we would expect that any WordPress installs Panda Security is running would be up to date now if they had taken the hacking seriously. Let’s take a look if they have done that:
The PandaLabs Blog:
The blog for their support forum:
The Panda Research Blog (which admittedly hasn’t been active for nearly a year):
All three WordPress installs we found were using a year and half old version of WordPress. There have been eight releases with security improvements since WordPress 3.0.4 was released.
Several times in the past we have looked at instances where Websense has inappropriately implicated that WordPress was connected to malware infections. In the most recent instance they falsely claimed that a malware infection was only infecting a certain version of WordPress and that there were known vulnerabilities in that version of WordPress. Just a month later they came out with another post that falsely implicated WordPress with another infection. We missed this at the time they put it out because we don’t follow their reporting as it has proven to be so bad. The post was recently brought to our attention and it is worth discussing it now, as what they continue to do is inappropriate and damaging.
This time it began with a posting titled “New Mass Injection Wave of WordPress Websites on the Prowl“, which is a pretty clear implication that the WordPress software had some involvement in the infection. But if you actually read the body of the post you find that they only mention of WordPress is in saying that a “majority of targets are Web sites hosted by the WordPress”. They don’t make any claim of an actual connection between the infection and WordPress. This isn’t a small distinction, as many websites are running WordPress and therefore it would not be unexpected that a more general issue would impact many WordPress based website. (As we will come back to in a little bit, there is also the issue of how accurately Websense measures what software websites are running.) If the issue isn’t related to WordPress than WordPress shouldn’t be emphasized, if mentioned at all, as many people will unnecessarily worry about the security of WordPress. It is quite clear there posting had that effect by looking at the comments on the post and the title of their follow up post “I have the latest WordPress version – is my Website protected?“.
Because Websense provided such little actual information about the malware infection, probably because they didn’t actually have any, it is hard to determine for sure what infection they are referring to and therefore the source. The infection looks to be related to a hack of many Dreamhost based websites, due to Dreamhost’s poor security. That occurred during the same time period, the malware code looks very similar to what we saw with those websites, and the comments on the first post reference that as well. If Websense’s security researchers were actually interested in doing security research, they would have actually investigated what the underlying source of the infections was instead of creating a post that baselessly implicated WordPress as somehow being related to the infections.
We don’t think Websense is intentionally trying to damage WordPress; the reason for doing this appears to get them press coverage. Unfortunately, just as they did with Websense’s last false report, some of press spread this and its non-existent WordPress connection. PCWorld’s article is titled “30,000 WordPress Blogs Infected to Distribute Rogue Antivirus Software” (Websense’s post actually only claimed that a majority of a total “close to 30,000 unique Web sites” were running WordPress) and the WordPress logo is at the top of the article. Dark Readings’ article actually introduces more harmful information to the mix. The article says that a Websense researcher says that “WordPress is so widely used around the world, every version of it is studied and exploited by hackers”, which is highly alarming but not even close to the truth. While there have been a number of security vulnerabilities found and fixed in WordPress in recent years, there haven’t been any that have lead to a major hack of WordPress based websites. That doesn’t mean that there haven’t been targeted attacks using them, though we haven’t seen any reports of that, or that a serious vulnerability couldn’t be found (so make sure you are keeping WordPress updated), but it does mean that running WordPress, as opposed to less popular software, doesn’t put you at some great threat of being hacked.
A Majority of Infected Websites Running WordPress?
The last time Websense brought up WordPress they originally claimed that all of the infected websites they found were not only running WordPress, but that they were all running a specific version of WordPress. When we did our own small analysis of 11 websites that had been listed as infected by Google, we found that 2 of them were currently infected and either not running WordPress or running an older version of WordPress. There were others that also were not running WordPress, but were not infected at the time so we couldn’t independently confirm they had been infected. Based on that data and the fact that they later admitted that the infection was unrelated to WordPress, there data in that instance was at least unrepresentative, if not faulty in some way. The information provided this time doesn’t provide any confidence that they have improved things since then.
In their first post it says that the “majority of targets are Web sites hosted by the WordPress”. A week later in their second post it says that “when we discovered the attack, we found only WordPress sites, and after a week or so, the picture did not change that much” and that “WordPress still serves the majority of the compromised websites; however, we did see a small amount of other CMS as well”. It’s not clear why the second post says that WordPress went from the only thing found to just the majority over a week, when the first post from a week earlier said it was only a majority at that time. There definition of a small amount seems off as well. They say that they found 14 percent were running something other than WordPress, with 10 percent being Joomla and 4 percent being “other”. That is a number far beyond what you would expect if this was truly something related to something in WordPress and had then spread to other parts of websites, which were running WordPress and other some software on different portions of their websites.
Another piece of their analysis seems even odder. They have a rather odd chart:
The chart shows some use of PHP versus an undefined other. PHP is a scripting language, so this could be a measurement of what language the code powering the website was written in, that website is capable of running PHP code, or maybe something else. The text preceding the chart doesn’t do much to explain what it is measuring or how they measuring it:
We checked several aspects of each of these compromised websites and concluded that most of them are served by Apache webserver and PHP environment. As you can see in the pie chart below, PHP dominates the server side:
Both WordPress and Joomla are written in PHP, so even if all of the “other” were not PHP based you would expect that a measure of either websites written in PHP and websites capable of running PHP code to be 96 percent but on the chart PHP is only 94 percent. One possible explanation of this is that it could be due to some of the websites being served by CDN or some other caching infrastructure, so the underlying server powering the website isn’t measured. Another possibility is that it another example of the poor quality of their measurement infrastructure. Whatever the cause of the discrepancy, it is something that would expect to be explained if they were going to present that chart as part of their analysis.
The larger issue is why they brought up PHP in the first place. Based on the fact that so much web software is written in PHP you would expect that many hacked websites would be using PHP, without the hack having anything to do with that. While there was a recent vulnerability in PHP, found two months after Websense postings, that could lead to websites being hacked some very limited circumstances, PHP isn’t something that is generally going to be the source of the hack. In this case, their data says that six percent of the websites are not using PHP, which would be a pretty good indication that it wasn’t related to PHP. The most likely explanation for highlighting PHP usage, and not many other things, is that they highlighted this finding simply based on PHP high usage among the infected website, without having a reason to believe it is connected to the actual source of the infection. You would hope that a researcher would understand that correlation is not causation, especially in an instance where you would expect there to be a correlation.
We often get asked by clients about whether they should be using some sort of malware scanner on their website and our answer has always been no. Two major reasons for this are that with proper security websites can be protected from being infected in the first place and that these website malware scanners are not very good at identify malware. What we haven’t considered before was the issue with these scanners producing false positives. We know that when people are told that their websites are infected with malware it is stressful and it can lead to them taking drastic, including deleting the websites. Deleting a website won’t always solve the underlying that caused the infection when a website is infected, but with a website that is not infected it is just a waste. This is why it is critical for those developing malware scanners to be very careful in making sure their scanners work properly and properly detailing what they are detecting. This is something that has been disregarded by the developers of the AntiVirus WordPress plugin and the Sucuri SiteCheck website malware scanner, as we recently discovered when we were contacted by someone unfortunate enough to have run into these two tools.
We were contacted, as we often are, by someone who wasn’t sure it there website was infected. (We are always happy to do a quick free check to confirm whether a website is infected or in some other way hacked. For potential clients that contact about dealing with a hacking issue we always do this first, as we find on a regular basis that the issue they are experiencing are not related to a hack or have actually already been resolved.) They and their web host couldn’t find anything wrong their website, but they were getting warning from two website malware scanning tools. As with any check we do, it involves discussing what leads them to suspect the website is hacked and us doing some of a variety of manual checks. Automated scanners are not reliable way for detecting issues for a number of reasons. In this instance the two scanners were falsely identifying two different items as being malware. We were able to determine this after a quick review of what they were reporting.
By looking at the false positives a malware scanner produces you can get a good sense of how good or bad it is.
On the page for the AntiVirus plugin on the WordPress.org Plugin Directory the plugin is described as a “useful plugin that will scan your theme templates for malicious injections” and “a easy and safe tool to protect your blog install against exploits, malware and spam injections”.
On the website we were contacted about the plugin was displaying a warning in the Admin Bar that a virus was suspected:
What was being identified is shown in the screenshot below:
As shown in the screenshot the suspected virus was the use of the statement require_once. The require_once statement causes a file to be included, with the further requirements that it only be included once and that an error occur if the inclusion fails. This isn’t a malicious statement and it isn’t something that should on its own be used to claim that malware is suspected. It is possible that something malicious could be included with this statement, but as it was with this website, there are perfectly legitimate uses of it.
After seeing this result we wondered why the use of this statement was being identified as a suspected virus, did the developer of plugin believe that this particular statement was only used with malware? What about the similar include, include_once, and require statements? When went to start testing this, we saw a startling result. As can been seen in the screenshot below, the default theme in WordPress 3.4 was being identified as suspected of containing a virus, for simply using the require statement:
A theme using any of the statements used for including files is identified as being suspected of infected, despite that clearly not being at a reliable indicator of a virus. It is quite troubling that something that is so clearly inaccurate is allowed to be in the Plugin Directory. At the very least it should have a very visible warning explaining what the scanner actually identifies. Looking at the support forum for the plugin you can see there are numerous threads involving these false positives. (There is also a topic where the self proclaimed “Hack Repair Guy” says that he recommends “this to my clients for basic security”, which is affirmation for our warning about that guy last year.)
In their marketing material Sucuri describes their SiteCheck website malware scanner as being “highly sophisticated” and that it “leverages internal definitions that are refined daily, external sources, and intelligence to identify both potentially harmful signatures and anomalies that may not be known”. They also claim to be the “de facto standard in website malware monitoring”.
If you are to believe their marketing claims about how great their website malware scanner is, you have to wonder how much worse the other scanners are. The more troubling aspect of this for their customers is the fact Sucuri’s idea of protecting websites is detecting that they already have been hacked and then cleaning them up. Putting aside the fact for the moment that properly secured websites are highly unlikely to be hacked and that allowing websites to be hacked has consequences even after they are clean again, with a scanner this poor it is unlikely that it will actually do a good job of detecting when website are infected. You really are much better off spending your time and money on actually keeping the website secure in the first place, instead hoping that when the website does get hacked it can be detected and cleaned properly.