Sucuri | White Fir Design Blog

Sucuri’s Scare Tactics on Display with Their Claim That the Washington Post’s Website Contains Malware

Back in March we put out a post about the, now GoDaddy owned, website security company Sucuri’s SiteCheck scanner falsely claiming that our website was “defaced” and that “malicious code was detected”. That claim was based on a page on our website being named “Hacked Website Cleanup – White Fir Design”.

We recently had someone contact us that ran across our post after having Sucuri make a similar false claim about their website. In their case they were contacted by their web host SiteGround with the Sucuri results. In looking in to what was going on we found a post on SiteGround’s blog from March announcing they were going to start doing that. What they say about Sucuri is disconcerting:

There are several reasons to change our scan partner from Armorize to Sucuri. First, Sucuri is one of the most respected companies in the website security field. In addition, we have been working in partnership with them for several years. We have relied on their expertise for solving numerous complex security issues. And last, but not least, many of our clients’ websites have also been cleaned by Sucuri from malicious code over the years. That is why it was only natural that we extend this already successful partnership and make it cover the daily site scans too.

If they are truly one of the most respected companies in the website security field, that doesn’t same much about the field. Not only has their scanner been quite bad for years, but what we have seen with their clean up of hacked website hasn’t been good either, an example of that involved a website they claimed clean despite compromising credit info entered on it. They also don’t seem to understand the basics of security. And about a year ago they accidentally made a good case for avoiding themselves.

But let’s get back to their scanner, which SiteGround is now helping to cause more people to interact with the results of.

Scare Tactics

If you go to the web page for Sucuri’s Scanner you will notice that just below where you enter an address to have it scanned, it states:

Disclaimer: Sucuri SiteCheck is a free & remote scanner. Although we do our best to provide the best results, 100% accuracy is not realistic, and not guaranteed.

That sound reasonable, the problem is that it doesn’t in any way match how they present results from it. Here is what it looks like when they think a web page contains malware, as can be seen with a page from the Washington Post’s website, which we happened to submit to test out something related to the false defacement claims:

Among the very scary sounding things they have on their are:

Warning: Malicious Code Detected on This Website!

Status: Infected With Malware. Immediate Action is Required.

Malware Detected Critical GET YOUR SITE CLEANED

Get Immediate Clean Up CLEAN UP MY SITE

Your site appears to be hacked. Hacked sites can lose nearly 95% of your traffic in as little as 24 to 48 hours if not fixed immediately – losing your organic rankings and being blocked by Google, Bing and many other blacklists. Hacked sites can also expose your customers and readers private and financial information, and turn your site into a host for dangerous malware and illicit material, creating massive liability. Secure your site now with Sucuri.

Though looking at the evidence presented to back that all up they seem a lot less sure there is even an issue as it is stated that “Anomaly behavior detected (possible malware)”.

When looking at the malware definition given, MW:ANOMALY:SP8, things are also unclear, as first they refer to what it detects as being “suspicious” and “possibly malicious”:

A suspicious block of javascript or iframe code was identified. It loads a (possibly malicious) code from external web sites that was detected by our anomaly behaviour engine. Those types of code are often used to distribute malware from external web sites while not being visible to the user.

But then states their “engine found it to be malicious”:

This is not a signature-based rule, but looks at anomaly behaviors on how the web site is being loaded. Our engine found it to be malicious (related to remote includes).

It isn’t reassuring that on one page they both claim detecting this would mean that something is malicious and that it is only possibly malicious.

Get a Second Opinion

We would strongly recommend that web hosts don’t do what SiteGround is doing here and further spreading Sucuri’s inaccurate results. It would probably be best to avoid any web host that does something like this as well, since it doesn’t show they have an interest in best helping their customers or that they are doing proper due diligence.

If you do get sent results by your web host that claim your website is hacked, whether they come from Sucuri or another company, we would recommend that you get a second opinion as to their veracity from a more trustworthy company that does hack cleanups. We are always happy to do that for free and we would hope that others would too.

Sucuri Claimed Customer’s Website Was Clean Despite It Comprising Credit Card Info Entered on It

Back in June of 2012 we wrote a post mentioning that looking at false positives produced by a malware scanner would give an idea of the quality of the scanner. In that post we looked at a rather bad false positive from web security company Sucuri’s scanner. Moving forward nearly five years it is clear that Sucuri hasn’t improved the quality of their scanner as a month ago we looked at them falsely claiming our website was defaced because we have a page named “Hacked Website Cleanup”. When your scanner is that bad, it doesn’t seem all together surprising that it would manage to miss things that it should catch as well and a recent situation we were brought in to deal with confirmed that. But much worse, it also reconfirmed everything we have seen in the past that Sucuri is company that either really doesn’t have much clue about what they are doing or doesn’t care to do things right, and in this situation that lead to people’s credit card information being compromised.

A week after we wrote the post about Sucuri falsely labeling our website as being defaced we were contacted by someone with Magento website that was having credit card information entered on it compromised. Sucuri, who they had brought on while before to deal with the situation, was telling them that website was clean, despite the compromises continuing to happen. Since that claim that the website was clean was pretty clearly not true, the person behind the website was then looking for someone competent to properly resolve the situation.

If credit card information is being compromised when entered on a website, the default assumption should be that the website is hacked. About the only other possibility we can think of is if the payment processor is compromised (which is lot less likely). So upon believing it was clean, Sucuri should have realized they were missing something and figured out what they were doing wrong, but they didn’t.

One of the questions we asked about the situation right after being contacted was who is the payment processor, if it was a major one then the payment processor could be ruled out as the source. It was a major one.

At that point we assumed that code causing the credit card info must be well hidden seeing as Sucuri couldn’t find anything. But after getting the response about the payment processor, we did quick check of the website from the outside and we immediately ran across part of the problem. It wasn’t even detected using any highly advanced proprietary technology, but off the shelf tools.

What we noticed was that there was JavaScript being loaded from the domain adyenweb.com through this script tag:

That was clearly meant to look like it was loading some type of tracking code.

The code in the file being loaded from that was highly obfuscated (when we ran through a tool to deobfuscate it, all it could pull out is that the code was requesting another file that was an encryption library for JavaScript):

At that point, considering the code didn’t look legitimate, instead of spending a lot of time trying to get a more complete deobfuscation before moving forward, we did a few other quick checks to try to assess the legitimacy of the domain the code was being loaded from.

First, we tried to trace where the server the domain was hosted on was, but found that it traced back to Cloudflare, which could have pointed to this being legitimate or it could have been someone with malicious intentions protecting themselves through Cloudflare (which is apparently a fairly common thing).

Second, we looked at the domain name registration, which didn’t look all that suspicious, but the domain was only registered on March 17.

Finally we tried to take a look at the website, but we found that there was nothing served at http://adyenweb.com or http://www.adyenweb.com. There also was nothing that came up for it in a Google search.

At that point we could safely say that this was at least part of problem. At the same time we noticed that despite something fairly obviously malicious being on the website Sucuri was telling the public the opposite about the website, as the website had this badge claiming it was “Secured by Sucuri” at the bottom:

Clicking that brought up this:

Not only did they claim the website was clean, but that their service “provides peace of mind that the website is not infected”, despite that not being true.

After we got access to the logins, we found that script tag shown earlier was stored in Magento’s settings in the database (as shown from phpMyAdmin):

This turned out to not be the only fairly hard to miss portion of the hack that Sucuri missed. In the root directory of the website was the backdoor script that the hacker was using to take actions on the website. That was something that Sucuri should have noticed at multiple points. Those points being during a visual inspection of the filesystem (since you need to get an understanding of what all is part of the website when first assessing the situation), during the reviewing the website files for malicious code (it wasn’t something that was obfuscated in a way that would make detection difficult), and when reviewing the log files to try to determine the source of the hack. In looking at the logs we found that the backdoor script had most recently been accessed two days after adyenweb.com was registered.

The backdoor script looks like it might have been on the website for nearly a couple of years, so we were not able to say what was the source of that was, but continued reviewing of the logs files showed that after it was removed and the various logins changed the hacker no longer had access to the website. So getting this resolved was rather simple for a competent company, which this incident shows Sucuri is far from.

Sucuri SiteCheck Scanner Falsely Claims Our Website is Defaced

In the past we have discussed the fact that the web security company Sucuri’s scanner SiteCheck is rather poor at what it does, including falsely claiming that a website was infected with malware due to a bad false positive and claiming that a website was running on outdated software without knowing if that was true.

We just ran across another example, which this time involves our own website. On a post about them astroturfing from four years ago, we recently got this comment:

The Scam is strong with this one

https://sitecheck.sucuri.net/results/www.whitefirdesign.com

If you follow that link as of us writing this you will see that the status of our website is “Website Defaced (hacked)”:

Not only is it not actually defaced, but there reason for claiming that is just baffling, as the claim is based on the title of one of the pages on our website being “Hacked Website Cleanup – White Fir Design”:

It would appear they are claiming that a website is defaced just due to the words “hacked” and “website” in the title of a page, which clearly isn’t reliable to determine if a website is defaced. On top of that they are claiming an issue that doesn’t actually exist is of “Critical” severity.

We of course can spot that their claim was wrong since we deal with websites that are actually hacked all the time (and it was quite obvious at least in this case), but based on plenty of experience dealing with people that think that their websites have been hacked, we would guess that a lot of webmasters and owners could be mislead by this type of thing, leading to some of them paying Sucuri to clean up a hack that didn’t exist.

Sucuri Also Misrepresents Other Companies Data

The problems with their scanner don’t end there as the results for our website show. They also mention that our website is “Blacklisted”:

Looking into the details of that they claim the website is blacklisted by Norton Safe Web:

The reality is lot less alarming then they claim. Here are the Norton results:

What seems rather relevant to that is this part:

Web sites rated “Caution” may have a small number of threats and annoyances, but are not considered dangerous enough to warrant a red “Warning”.

So unlike Sucuri they don’t think that it should get a red warning.

So what are the threats on our website? There are not any, instead Norton’s scanner doesn’t understand the difference between showing malicious code in harmless form on one of our website’s pages, with actual malicious code on a website (the poor quality of website scanners isn’t limited to Sucuri):

While Sucuri warning if websites are actually blacklisted by other services would be useful, it should be accompanied by a disclaimer that the other services results may not be accurate instead of overhyping the issue to try to sell their services.

A Better Way to Get Your Website Check to Confirm if it is Hacked

Based on all that there is plenty of reason to avoid Sucuri’s SiteCheck, but what is a better way to confirm whether your website is hacked if you believe it is? The simple answer is to contact us, as we are happy to do a free check to confirm whether a website is hacked or not. We don’t rely on low quality automated tools to do that, since they produce poor results as was shown above. Instead we will discuss the situation with you and then do any necessary checking to look into the possible issue. For websites that are hacked we will also provide a free consultation on how best to deal with the issue, instead of trying to scare you into using our services, unlike Sucuri.

Sucuri Makes A Persuasive Case That You Should Avoid Using Their Services

When it comes to the security of websites the situation isn’t good these days. Who’s to blame for that? Well there is plenty of blame to go around, but in dealing in the field we can say that one of the big culprits is security companies. The reality is that most of them don’t know and or care much about security, so they end up in many cases being counter productive to improving security. You won’t hear much about that, as these companies seem to have realized that as long as they all keep quiet about how bad they all are then they can get away with it. That has lead to what appears to be a de facto code of silence in the industry, which we have come to notice since we have pointed out problems with security companies’ products and services on a number of occasion and have had more than a few people contact us and tell us we shouldn’t being doing that. They have never were claiming that we had said something false, just that we shouldn’t be pointing out problems, which obviously sounds rather odd. In one recent case someone from a security company said that if we kept doing this, other security companies would turn “against you as it already happened to others in the past”.

Recently though a couple of web security companies with a focus on WordPress security criticized each other. Though one of them, Sucuri, ended up making a persuasive case that you should avoid them as well as the other company (which seems to be a good example why these companies normally keep quiet).

Last week Sucuri put out a post on their blog, Security Through Confusion – The FUD Factor. While the post doesn’t mention any companies by name, in a now deleted tweet they specifically mentioned the company Wordfence, who wrote a couple of posts that pointed to problems with Sucuri’s service (not surprisingly considering Wordfence’s poor understanding of security, they missed a key element of the topic). If you are in even vaguely familiar with the truth about Sucuri, you can’t help but notice how much of their post applies to them as well.

In several of the early paragraphs they describe companies as using FUD (fear, uncertainty, and doubt) to sell products:

FUD is very common in the infosec domain and used to gain advantage over competitors. It is often done by companies when they find themselves hurting financially, desperate for attention, lacking in adoption or the perceived real value of a product does not materialize. The goal is simple. Do whatever possible to divert attention and confuse an audience so that they buy X product.

and

In a crowded space like this, where anyone can be an expert, how are these organizations supposed to stand out? Unfortunately, the apparent answer to some seems to be to grow through the employment of disinformation strategies, the FUD factor.

More concerning is that some might not be doing it intentionally. They don’t understand security and are mixing FUD with misinformation and taking advantage of the average low-level aptitude of many WordPress users. That creates this concept of Security Through Confusion.

Next up the they have list of FUD triggers, which are “designed to help you know if you’re being deceived.” One of those is

An organization who claims “We’re the best!” or “We’re the experts!” or “We beat everyone by a wide margin!” –> Everyone is the best in their own eyes.

You don’t have to look far to see Sucuri doing that, here is the first sentence of the description page for their WordPress plugin:

Sucuri is a globally recognized authority in all matters related to website security, with specialization in WordPress Security.

Seriously, they wrote that. And now they are telling you to watch out for just that thing.

Right after that in the post they write this:

If you see any of these red flags it’s time to approach them carefully. In some instances, you’ll want to run the other direction quickly. Instead, spend the time to perform some critical thinking when working with an organization. Why are they making these claims, and is there anything that is supporting these claims?

Next they write this:

The more challenging triggers are those that are technical because not everyone is able to appreciate the nuances of an argument. You hear what you perceive to be an authority and believe them to be accurate.

This could apply to many things we have seen with Sucuri, but let’s look at one. Before that though, let’s look at example of this they provide.

Plugin creators that misuse terminology. An example of this would be claiming they are the only “defense in depth” solution as it contradicts the very idea of a defense in depth strategy.

It was just at the end of last month we looked at an example of them not having a clue what a brute force attack is, that is despite it being a common enough term that it has a Wikipedia page. That is only really the tip of the iceberg though. As we discussed back in August, either Sucuri doesn’t understand that brute force attacks against WordPress admin passwords are not happening or they are intentionally misleading the public to think they are. They even have a page that supposedly tracks brute force attacks against WordPress, but instead highlights that they are not happening.

One of the final elements of the post ends up pointing to them not being able to provide proper protection. They state:

A protection product should have enough threat-detection and analysis research to share.

We can say without any doubt that when it comes to security vulnerabilities in WordPress plugins, which is a major source of WordPress hackings, that Sucuri isn’t failing on the threat detection front based on the work we do for our Plugin Vulnerabilities service. One of the things we do to keep track of vulnerabilities in WordPress plugins is to monitor our websites and third-party websites for hacker activity. Through that we have found numerous vulnerabilities that exist in the then current versions of plugins, which hackers are have been probing for usage of, and would likely be targeted by hackers. When we started finding those we figured that other security companies would also be spotting those as well and wanted to see how our response time compared. You would assume that Sucuri would be looking for those as well, otherwise how are they supposed to protect against them if they are not aware of them. Much to our surprise we found that the other security companies are not spotting these. Through our work we have we have been able to insure many of those vulnerabilities get fixed, so even those not using our service are getting improved security thanks to us. By comparison, no one was given any additional protection by Sucuri, since they were not even aware of the vulnerabilities.

The one time that Sucuri mentioned one of those vulnerabilites it just went to show that they don’t really know what they are doing. The post starts with the following image:

disclosure-image-wordpress-768x361

While they proclaim this to be their “security disclosure”, we had actually disclosed the vulnerability a couple days before, which they were aware since they had repeatedly visited our post before releasing their post.

Here how the post originally started out (it was later edited after we had gotten news outlets to accurately reflect who had disclosed the vulnerability):

For the last few days, we have noticed an increasing number of websites infected without any outdated plugin or known vulnerability. In most cases it was a porn spam infection. Our research team started to dig into the issue and found that the common denominator across these WordPress sites was the plugin WP Mobile Detector that had a 0-day arbitrary file upload vulnerability disclosed on May 31st. The plugin has since been removed from the WordPress repository and no patches are available.

In that there are several huge red flags. Let’s start with the fact that Sucuri did not detect this vulnerability as it was originally being exploited, which they should have been able to do. We were able to do that and we don’t claim to be a “globally recognized authority in all matters related to website security”. Right there you can see they don’t have “enough threat-detection”. Then they fail on the “analysis research” front as well. When you are cleaning up a hacked website one of the basic steps is to determine how the website was hacked and you do that in large part by reviewing the log files. We know that Sucuri didn’t do that in this case, because if they did they would have easily found the vulnerability. Instead for some reason they were relying on trying to find a common denominator between the hacked websites (which shows they lack even basic skills). If we hadn’t already identified the vulnerability in the plugin they may have still been in the dark.

The fact that they didn’t looks at the logs in this case isn’t an aberration, if you take a look at a recent infographic they put together on cleaning up hacked WordPress websites, you will see there is no mentioning of determining how the website was hacked. That is despite that being one of three main components of hack cleanups. This point to the fact that they don’t properly clean up hacked websites and that they can’t properly protect websites as they don’t even know what the real threats out there are.

Also problematic on the “analysis research” front is that they didn’t mention that the vulnerability was only exploitable if you had PHP option enabled that is known to permit just this type of vulnerability. We prominently mentioned it in our post, so they were aware of it. Either they didn’t understand the significance of it or they didn’t want to mention it, since knowing that would allow a lot of people to easy see that they were not vulnerable and it would also show that you can actually take actions that will protect your website, instead or relying on a paid service.

Another one of the last things they say in the post is this

Be mindful of bold claims with no supporting data, or extremely vague descriptions.

If you look at how they promote their service, they also line up with this.

On their homepage here is how they advertise their protection as:

PROTECT MY WEBSITE Currently under DDoS Attacks Stop Vulnerability Exploit Attempts Undergoing Brute Force Attacks

Beyond the fact that almost no one is actually undergoing brute force attacks ever (they really are pushing that falsehood), as we just discussed Sucuri isn’t even aware of many vulnerabilities, so their ability to protect against them is limited to say the least (also it can be incredibly easy to get around their protection, as well touch on in a future post).

If you click the link you will get a whole host of claimed protections, without any supporting data:

Protect Your Website. We Stop Website Hacks and DDoS Attacks. We mitigate DDoS attacks, improve and optimize your website's performance, and stop hackers from exploiting software vulnerabilities (i.e., SQLi, XSS, RCE, etc...). Cloud-based protection, no installation required.

Their claim of “Zero Day Prevention” also should be a red flag. A zero-day vulnerability is any vulnerability that is being exploited before the developer of the relevant software is aware of it, so to prevent those you are really saying you can prevent any vulnerability from being exploited, which isn’t all that believable.

Help Improve Security By Warning Others About Sucuri

As long as bad security companies like Sucuri are to flourish, security companies are going to continue to be an impediment to improving to improving the security of websites. So by letting others know that they should avoid Sucuri, you will be helping to improve the situation. You don’t need to take our word that they should be avoided, Sucuri has made the case themselves that they should be avoided.

Sucuri Doesn’t Have A Clue What Brute Forcing Actually Refers To

One of the problems we see when it comes to people making better choices on web security is that it easy for security companies that don’t have a clue what they are talking about to present themselves as having expertise they don’t have. For example, they can throw around technical terms that they clearly don’t understand, but that the public understandably doesn’t understand either, and it makes them sound like they actually know about security, when they don’t.

One example we keep seeing involves the term brute force attack, which refers to trying all possible password combination in attempt to login in to an account. It isn’t some obscure or exotic term, it has a Wikipedia page, but that doesn’t stop people from using it when actually referring to other types of password attacks.

Often times dictionary attacks, which involve trying to log in with a set of common passwords (things like “password”), are incorrectly identified as having been brute force attacks. The distinction isn’t just semantics, how you protect against those types of attacks is very different, so anybody dealing with web security that involves either of those, absolutely should know the difference. And again the term has a Wikipedia page, so it wouldn’t be hard to know what it is.

That brings us to the security company, Sucuri, which we have seen being quite a bad security company in many ways over the years. That clearly hasn’t changed. In a recent post describe how they did an experiment that was supposed to test how long it would take for successful brute force attacks of SSH logins:

A few weeks ago we ran an experiment to see how long it would take for some IPv4-only and IPv6-only servers to be compromised via SSH brute force attacks.

As they explain in the second paragraph of the post, their experiment involved them setting the password to “password”:

We configured five cloud servers on Linode and Digital Ocean with the root password set to “password.” The idea was to see how long it would take before the servers were hacked.

To anyone who actually know what brute force attacks and dictionary attacks are, its obvious that they don’t actually know what they are talking about since that would be a password to test for dictionary attacks, not brute force attacks, but the public is unlikely to, especially as security companies keep referring to dictionary attacks as having been brute force attacks.

If you are interested in actual security, Sucuri’s lack of basic security knowledge, would be a good reason to look elsewhere.

Questionable Support Advice on Dealing With Hacked Websites From WordPress and Norton Safe Web’s Mystery Blacklisting

One of the things we do to keep track of vulnerabilities in WordPress plugins for our Plugin Vulnerabilities service is to monitor the WordPress support forum for threads related to them. In addition to threads that actual relate to that issue, we frequently run into to other security related threads. In doing that we noticed that in many threads a reply containing the same advice is given, which consisted mainly of a series of links. Some of the pages linked don’t seem to provide the best information, so we wondered if the various members providing that reply were actually aware of what they were linking to or if they were just repeating something they had seen others saying. While looking into another issue involving the forum we found that the source of the message was from a series of pre-defined replies for moderators.

While looking into another thread that came up during that monitoring of the forum we came across evidence that one of the links they include, a link to something called Sucuri SiteCheck, may not be the most appropriate to include. In that thread the original poster had written:

Sucuri is showing my site as harmful and is asking for $16/month to fix it, yet my site seems fine, traffic is normal and I have no log in / access problems on any browser or device.

When we went to look to see why Sucuri was claiming the website was harmful, the SiteCheck page was light on details and high on pushing you to use their service:

Looking at the other two tabs of information, the only issue that they were identifying was that website was blacklisted by “Norton Safe Web”:

It seems to us that a service would be careful in situation where they are not themselves detecting anything malicious, but Sucuri seems to be labeling the website as “Site Potentially Harmful” and “Site Likely Compromised” based only on the fact that Norton Safe Web was blacklisting it. Based on our limited experience with Norton Safe Web, that would seem to not be appropriate because the results we have seen from it in the past have been rather poor.

Looking at what they are claiming to have detected with this website makes us more confident of the position.

Here is what they are reporting as of now:

You can see they are not claiming that there are any “computer threats” or “identity threats”, just an “annoyance factor”. What the “annoyance factor” isn’t really further explained, with the only information being that a page is listed as having a “SWBPL” threat. There is no explanation what a “SWBPL” threat is either on the page or through a link. In searching around to try to find out what that is, we found that we were not alone in trying to figure that and that even some people at Norton did not know what it is. The most detailed information we could find was in a thread on the Norton website, where it was stated that:

SWBPL is one of the threat type in safeweb which is based on telemetry which we collect from 3rd party vendor feeds. Since these sites are classified based on the static data it is pron to few FPs

So Norton is apparently warning about the website based on unidentified third-party’s data, which is also apparently prone to a “few” false positives. That doesn’t really seem like something that should be the source for Norton warning about a website and certainly shouldn’t be used by someone else to make claims as to the security of the website.

Looking at the URL they identified as being a “SWBPL” threat, visiting it normally just returns a “Page not Found” message and when visiting it in some other ways didn’t produce any different result. Without having access to the backend of the website we can’t rule out there is some issue with it, but from the outside there is nothing we could find harmful about it.

We hope that WordPress will review the boiler plate message they provide to those with questions about hacked websites and consider if they are providing the best information in it.