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:

sucuri-sitecheck-results

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

sucuri-sitecheck-blacklist-status

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:

norton-safe-web-report

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.