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.
AntiVirus
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.)
Sucuri SiteCheck
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”.
As can been seen in the screenshot below Sucuri’s scanner claimed “Site infected with malware” and that it contained known JavaScript malware:
We looked at the code that they identified as malicious and found it to be legitimate and non-malicious. We also found that it was on a legitimate website and we could find no indication that website in question was recently infected, so why was Sucuri flagging it? To try to figure that out we looked at the malware entry that they were flagging the code for. The description given is “A suspicious remote javascript include was identified. It was set in an non-standard place (before the <html> tag) and was used to distribute malware to someone visiting the infected web site.” It is true that sometimes malware is placed at locations were you wouldn’t usually find legitimate code and it would make sense for a malware scanner to flag that for additional scrutiny, beyond a regular scan of the code for malware.
What appears to have happened is that Sucuri automatically flagged the code based on their signature without actually scanning the JavaScript file for malicious code, which, if their scanner was reliable, would have determined that it was not malicious. That should be a basic part of scanning the page for malware even if it wasn’t in that odd location or part of a signature. When you don’t actually scan things for malware before falsely identifying them as malware, you really shouldn’t be calling what you do website malware scanning.
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.
Seriously? Your complaint is that a scanner, correctly, identifies that JavaScript is detected and it’s outside the tags and it’s flagged as malware? That a scanner isn’t perfect? Therefore don’t use any scanners?
This is a classic case of throwing out a solution because it doesn’t solve every problem, which is a terrible way to try to solve a problem. Scanners are just one part of a defense in depth approach to security. Anyone that thinks a scanner or anything else, including your advice that you can “keep the website secure” is all you need to do doesn’t not know anything about security. In this case, a scanner would be one method you can use to KNOW your properly secured website was infected. Is it perfect? Of course not, security is a process, not a state. It’s all about defense in depth, and this kind of hyperbole don’t help anyone.
If you read the post you will see that we said that it would be reasonable for the malware scanner flag the code for additional scrutiny. The problem is that there wasn’t any scrutiny at all; the malware scanner didn’t even scan the file for malware. If it had, it would have seen that it wasn’t malicious. At that point it isn’t even actually a malware scanner. There is a big difference between perfection and not bothering to actually scan for malware with something claiming to be a malware scanner.
We actually know about security. Not the kind the kind that involves throwing around catchy phrases like “defense in depth” and “security is a process, not a state”, but the kind that deals with the real world. We deal with websites every day, including many that are hacked. We actually determine how those websites get hacked, so we know what needs to be done to prevent those things from happening to other websites. If people do the things in the article that we linked to at the beginning of the post, then that will prevent the kinds of hacks that are actually causing the average website to be hacked. (There is more that security community can do to improve security beyond that, but unfortunately many of them are instead focused on pushing products and services that don’t fix the real problems.)
A good example of the how things are in the real world can be seen in a blog post of ours from earlier today. Nearly four months ago Panda Security, which is a computer security company, had one of their web servers hacked and numerous websites defaced. You would think that after a computer security company had their websites hacked they would now be making sure they follow security best practices going forward, but as of today we found three WordPress installations on their website running a year and half old version of WordPress. If even a security company isn’t taking such a basic security precaution of keeping WordPress up to date, then there is still plenty to be done to actually keep websites secure.
The solution to this isn’t for people to spend money on an unreliable malware scanner or even a malware scanner that works perfectly. At best a malware scanner would tell you that the website is infected after it already has been infected. At that point you need to clean up the infection and secure the website to make sure the infection doesn’t reoccur. We think it is better to secure the website before it can be infected.
Disclosure: I am a happy Sucuri customer.
I found them when my sites were infected from the TimThumb issue about six months ago. Yes, the infection was “my fault” in that I didn’t secure my websites completely and I used what turned out to be an unreliable plugin (though it was one of the most popular at the time and was considered secure, so there’s that).
I tried to fix the issue on my own but the infection recurred. I am not strictly a web security expert but I know my way around code; I can code in my sleep. Still, I spent days trying to patch up my sites.
Ultimately, I paid Sucuri to clean it up. Not only did they clean it up, but they also fixed the holes in my security that caused the problems in the first place. I haven’t had an infection since, so to say that Sucuri is only reactionary and not preventative overlooks a large part of what they do.
I will continue to pay them because of this: They will not only fix my sites if there is a problem, but they will prevent the problem from recurring. To use a cliche, I’m paying for piece of mind. And what I pay them is also far less than the time I would have spent doing what they do. I’m not a web security expert, but they are.
It sounds like you know more than your share about website security, and that’s great. But not all developers or designers do (to say nothing of the general population). When my pipes burst, I call a plumber. When my site is infected with malware, I call a security service.
You say: “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.”
That’s the thing about vulnerabilities. They evolve. What is secure and a best practice today is a vulnerability tomorrow. Unless web security is your full-time job, I think you’re much better off paying someone to do it for you.
You are wrong when you say that the hack of your website was your fault. It was actually the fault of the WordPress developers and more importantly the people that professionally deal with the security of WordPress. For far too long we were part of the problem, we have previously acknowledged that we are in part to blame for it and we are committed to continuing to push to get things fixed. The vulnerability in TimThumb was resolved nearly a year ago, so any plugin that still had the vulnerable version of TimThumb six months ago would of have been one of the plugins that was removed from the Plugin Directory and was never fixed. You should have been warned that the plugin had a security vulnerability by WordPress, but that currently doesn’t happen. There is good news on that front though, just yesterday it was disclosed that the process of adding alert in WordPress when plugins that have been removed from the Plugin Directory are installed has begun (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.
Getting those alerts added to WordPress is only part of the larger effort needed to improve the security of WordPress plugins, which lags far behind WordPress. We previously found that many plugins with unresolved security remained the Plugin Directory (including a plugin that there were attempts to exploit at the time). Since then we have been monitoring the reports of unresolved vulnerabilities in WordPress plugins and making sure that that the people running the Plugin Directory are aware so that the plugins can get handled properly. Among our other efforts to improve WordPress plugin security we have a security bug bounty program that includes high profile plugins.
The rest of your comment actually shows that Sucuri is reactionary and not preventative. They only fixed the TimThumb vulnerability on your website after you were hacked. That doesn’t do anything for anyone else using that vulnerable plugin and it doesn’t do anything if you and many other people ever happen to be using another plugin that has a serious security vulnerability that doesn’t get fixed. If you want to pay someone to keep your website secure (and we never suggested you should or shouldn’t do that), then you should find someone who actually does the things that keep websites secure instead of hiring a company that uses a faulty malware scanner to attempt to detect that websites are already infected with malware as you are with Sucuri. If Sucuri was actually interested in keeping WordPress based websites secure, instead of profiting off them remaining vulnerable, you have to wonder why they haven’t had an effort to get the issues with unresolved plugin security vulnerabilities fixed.
Daniel Cid from Sucuri here.
That’s a good point you made. In this case it was indeed a false positive, and our scanners shouldn’t flag it anymore.
Thanks for helping us improve our scanner (not perfect, we know).
Also, as far as sitecheck flagging the files without checking, we do actually visit them directly. But we also look at the positioning and flag them in some cases even if the destination file is offline, or appears clean. Why?
Because we often see sites with malicious iFrames or JavaScript includes that get disabled, or are offline when we scan, but that doesn’t mean the site wasn’t compromised, or that didn’t get injected. It is still infected, just not loading for anyone that visits the site.
In any event, if you ever find issues in our scanners, or any of our products, let me know and I will be glad to answer or get that fixed.
thanks,
I just began working with a client who was blacklisted by Sucuri…three after this original post. All I know is that one of my client’s major business partners is using Sucuri, and the false positive is now costing them business. Their partner will not do business with them until they are able to access my client’s site. This could end up in severe financial damage for them. I have made two attempts to contact Sucuri, over 3 weeks, and the issue has not yet been resolved. Very soon, the issue will need to be escalated. NOT impressed with Sucuri.
I just got hit with another forced MS Edge update on my little asus laptop. I am so mad I can’t see straight this sucuri crap comes up blocking me from known sites I frequent and has made everything hard to load. I have malwarebytes and didn’t ask for this or want it. If they were a legitimate firewall app I wouldn’t know about htem unless I was hitting an infected unknown site not somewhere I frequent. They seem to have a skin on as I am now shown the old cached screen of the site I’m trying to get into if it doesn’t just go over to this crap:
Sucuri CloudProxy – Backend Server timeout
What is going on?
I am sorry, but we are unable to connect to the page you requested. It seems that the hosting server (where this site is located) is down and we do not have a cached copy to give to you. Please try again in a few minutes.
What can I do to fix it?
If you own the web site, please verify with your hosting company if your server is up and running. They might be doing a maintenance or be overloaded. Please wait a few minutes and try again. If the problem persists, open a ticket on our support page and we will troubleshoot: https://support.sucuri.net.
If you are just visiting the site, just wait a bit and it should be back soon. We apologize for the inconvenience. If you have any question, email us at cloudproxy@sucuri.net.
Error details
Error Code: HTTP 504
Error Message: Backend or gateway connection timeout.
Server ID: cp12002
Sucuri CloudProxy
CloudProxy is a Website Firewall from Sucuri. It stands between your site and the rest of the Internet and protects against attacks, malware infections, DDoS, brute force attempts and mostly anything that can harm it.
Not only that, but your sites get cached, speeding it up quite a bit. Interested? Visit https://sucuri.net
this is what I hae spent my whole day on