Update For Critical Security Issue in Joomla Being Released Tomorrow Morning

Joomla has announced that an update to fix a critical security issue is going to be released tomorrow morning, 8am MDT. They haven’t released any details on the issue, but have said that “Since this is a very important security fix, please be prepared to update your Joomla! installations next Tuesday.”. That sounds like good advice to us.

Posted in Joomla | Leave a comment

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.


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 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:


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.

Complete Website Protection DDoS Mitigation and Hack Prevention Mitigate DDoS Attacks Stop Vulnerability Exploits Prevent Website Reinfections Proactive Website Protection Global Anycast Network Content Distribution Network (CDN) Performance Optimization / Acceleration Full DNS Management Customer Support $19.98/month Annual Billing Available 24/7/365 Attacks We Prevent: TCP SYN Flood HTTP/s Flood SQL Injection (SQli) Brute Force Attempts Vulnerability Exploits Malformed Requests Zero Day Prevention Bot Requests / Traffic Many More

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.

Posted in Bad Security | Tagged | Leave a comment

SiteLock Promotes The Idea That Protecting Websites Involves Leaving Them Vulnerable to Being Hacked

When it comes to cyber security, it has been clear to us for some time that most of the companies in the field don’t really care about security. Just yesterday we discussed a cyber security company that doesn’t even bother to keep the software running their websites up to date, despite that being a really basic security measure (that is far from the first time we have spotted that type of situation either). One of the areas where we see this lack of care about security is shown by the fact that security companies services and products often are focused not on things that would actual prevent systems from being hacked in the first place, but on detecting the system has been hacked after the fact.

That brings us to a recent post on the web security company SiteLock’s blog. The post uses the results of a test they recently had done by the Tolly Group to argue their product is better at protecting against threats to website than another product of a different type. As we discussed last week the test was, at best, quite poor, but might be accurately describe as being rigged. The test involved testing if their product and another product could detect malicious code on a website and SiteLock not only had access to the samples being tested, but provided the sample code that was tested. Not surprisingly they were able to detect 100 percent of it (the developer of the other product wasn’t provided the sample code). To make things even ridiculous they then promoted the testing as having been independent, despite the fact that they even provided the samples to be tested.

First off, the post really could have used some editing, as it has some quite bad statements such as one in this paragraph:

In recent years, though, informal blogging environments, such as WordPress, have blossomed into full-blown web application platforms. Commercial and community developers contribute blocks of codes, known as “plugins” to enable just about any type of functionality that you can imagine. (A Google search on “WordPress Plugins” shows over 11 million hits.)

If you want to measure how many WordPress plugins there are, you could look at the homepage of the official Plugin Directory, where most WordPress plugins are made available, as that provides a count of plugins available through that, currently 47,146. If SiteLock was as familiar with WordPress as they promote themselves, they should have known that.

Explaining the basis of the test you can see what is so wrong with the view that SiteLock appears to agree with:

The basis of the test was the assertion that traditional endpoint security solutions are not designed to detect web application threats and, therefore, would have a low detection rate when scanning for such threats.

The actual threats against web applications would be vulnerabilites in the software, not malicious code that can be added by exploiting those. But the testing instead looked at the end results of threats being exploited:

A corpus of nearly 3,000 web-based malware samples, defined by SiteLock, was run through a prominent “traditional” endpoint security solution to illustrate SiteLock’s point.

The conclusion on the post is:

The point, really, is not the absolute percentage of malware detected. The point is to illustrate that there is an entirely new set of threats “out there” that traditional endpoint solutions have not been designed to detect. And, those new threats clearly require an additional, “next-gen” endpoint security solution in place to provide protection.

The reality from dealing with many hacked websites that many of those could have been prevented by taking basic security measures and many other could have prevent if other security practices were improved. From what we have seen of automated methods for trying to detect and clean malicious code, they produce poor results. Also, websites don’t just get hacked to place malicious code on them, so leaving a website vulnerable and trying to detect malicious code added to it, would among other things, allow for the possibility of sensitive data being extracted from it on a repeated basis.

While the post was written by the found of the Tolly Group, it isn’t just a situation that SiteLock posted someone else’s words with this very wrong view on the security, our past experience has shown that SiteLock view is in line with this. For example we have found that they label websites as being secure when they are using outdated software with known vulnerabilites and they don’t make sure that the software on a website is upgraded when they are cleaning up after a hack.

Posted in Bad Security | Tagged , | Leave a comment

HostGator Is Actively Hiding the True Nature of Their Partnership With SiteLock

When it comes the really bad practices of the web security company SiteLock, they often involve their partnership with various web hosts. Considering that long ago we had seen that SiteLock didn’t seem to very good at handling security, whether it be not properly cleaning up hacked websites or not doing a basic security check before declaring a website secure, we had long assumed that these partnerships were not based on the web hosts believing that SiteLock was the best company to best help their customers, but instead based on the web hosts being paid to push their services. Those payments, it turns out, are happening, but they tell only part of the story of the partnerships with some of the web hosts.

Last month while looking for some other information about SiteLock we can across the fact that the companies majority owners also are the CEO and a board member of the web hosting company Endurance International Group. That companies does business under the brand names A Small Orange, Bluehost, FatCow, HostGator, HostMonster, iPage, IPOWER, and many more.

Through that we also found that in the case of Endurance International Group, not only were they getting paid for the sales of SiteLock services through the partnership, but they were receiving a majority of the fees as of fiscal year 2014.

In the case of both of those facts, they were disclosed to investors, the ownership is disclosed in financials statements and the fee breakdown was disclosed in a prepared remarks for an earning conference call. To the public those things have not been disclosed in the normal course of business. And a recent interaction we had with HostGator support on twitter show that isn’t just that they don’t go out of the way to disclose them, but are actively trying to hide those facts.

The interaction starts with this tweet from HostGator Support to a customer of theirs that doesn’t mention either of those items as reason why they are partnered or “suggest” SiteLock:

Its worth noting that when it comes to cleaning up a hacked websites, you would do things the same way no matter the web host, so working well with their service is explanation that doesn’t make much sense for hack cleanups. It also worth noting, as we did before, that HostGator doesn’t make it easy to properly clean up hacked website since log files are not stored for a sufficient amount of time be default. If this was a real partnership and SiteLock actually properly cleaned up hacked websites, we would expect that issue would have been resolved a long time ago.

We sent a reply to their customer mentioning the CEO connection:

In turn HostGator starts to obfuscate (due to the limits of tweet length our tweet had not had made the distinction that the CEO in question, was of Endurance International Group, but it is clear in the linked post)

We then sent a reply clarifying that and they replied:

At that point we said that we hope they would start to disclose the true nature of their partnership:

Which in turn lead stating they could not confirm that, despite those being facts that their parent company has already confirmed (otherwise we wouldn’t know them):

At this point, they claim they can’t confirm they are getting paid:

It is one thing for them to not mention what is going in the normal course of business, but to actual being unwillingly to tell the truth is pretty telling as to what is going on.

The conversation ended after we pointed out that we were not asking them to confirm anything, just disclose what we both already know to be true:

What To Do If You Get Contacted by HostGator or SiteLock About a Hacked Website

One of the bad practices we have seen from SiteLock is to claim that website are hacked when they are not, so if you get contacted by either of them with claim that the website is hacked you should get a second opinion. We are always happy to provide a free consultation on how to best deal with a hacked website, which includes double checking as to whether the reason the website is believed to be hacked does in fact make sense (often times other issues are confused with actually hacking issues and that can usually easily recognized by someone who deals with hacked website on a regular basis).

Considering how bad of a job SiteLock has been doing with cleaning hacked websites as of just the last month and their bad practices you would probably be best off avoiding them when you are dealing with a hacked website. You also might want to consider moving to a web host that doesn’t partner with SiteLock, as that partnership seems like it is pretty clear warning of how they treat their customers and a lack of concern for security.

Posted in Bad Security | Tagged , , | Leave a comment

Cyber Security Company’s Poor Website Security Reminder of Industry’s Lack of Focus On Actually Improving Security

When it comes to the poor state of website security one of the issues we see is that while too often people are not doing the basics of security, security companies are pushing all sorts of advanced security products that provide little to no value beyond what could be had by doing the basics. Sometimes those things are fairly connected, take for instance the cyber security company Lunarline that claims to have “clients in the intelligence community, DoD and nearly every cabinet agency”. In post on their blog back in July, No Website Is Immune From Cyber Attacks, they stated:

Reducing your risk of critical website attacks requires a multifaceted approach, but you can take the necessary steps regardless of your organization’s size. While you may be running vulnerability scans on your web servers, these scans can only find known issues, and weak points specific to your organization’s systems may go unnoticed. This is where skilled penetration testers come into the picture, using up-to-date real-world hacking methods to see where you could run into problems.

The reality that we see in dealing with hacked websites is the problems would have been prevented with pedestrian measures, say keeping the software up to date. That is something that Lunarline isn’t doing on that same blog:

The Lunaline Blog is Running WordPress Version 4.2.1

It isn’t just that they have kept WordPress up to date, but they are not running the latest version of the outdated version of WordPress, 4.2, they are using, which is 4.2.10 (4.2.2 was released in May of 2015). All the 4.2 releases since then have include security updates.

For those not familiar with WordPress, that indicates something is wrong. Normally WordPress would have automatically applied the 4.2 updates due to WordPress’ automatic background updates, which were introduced in WordPress 3.7. There are two likely possibilities why those updates haven’t happened, the first being that they disabled the automatic updates and then didn’t handle the updates manual or there there is a problem with those updates occurring in their hosting environment and they also never bothered to manual update either. If it was the latter then helping WordPress to resolve that issue would help them, since they can’t seem to manage to the update themselves, and it would help anyone else with the same issue.

This isn’t the first time we have run into a situation like this. We previously discussed the fact that the maker of a WordPress security plugin’s website had an out of date WordPress installation. In that case they later contacted us and let us know that they had disabled the updates since they had modified core WordPress files, which you shouldn’t do. The fact that someone making a WordPress plugin couldn’t properly handle using WordPress built-in capability to modify it instead of modifying core files, makes what we found the next time we ran into them none to surprising. We found that their plugin was using custom for a security check instead of using WordPress built-in function for doing the same and that the custom code had a security vulnerability in it.

The outdated WordPress install on Lunarline’s blog isn’t the only obvious security issue with their website. They are also running an outdated version of WordPress on their School of Cyber Security website as well: The School of Cyber Security Website is Running WordPress Version 4.2.2

Their main website is also running on an outdated version of Drupal:

The Lunaline Website is Running an Outdated Drupal Version (7.0-7.42)

A little further checking show that the Drupal version is 7.36, 7.37, or 7.38, which means they haven’t applied any updates since at least August of last year .

Posted in Bad Security | Tagged , | Leave a comment

ZDNet’s Zero Day Blog Doesn’t Understand What A Zero-Day Vulnerability Is

Earlier this week we discussed a situation where a couple of articles on tech news websites labeled several vulnerabilities disclosed in a Dell EMC product as being zero-day vulnerabilites despite there being no indication that was the case. A zero-day vulnerability is a vulnerability that is exploited before the developer is aware of the vulnerability. That obviously is serious situation since you have a vulnerability that is being exploited and having kept your software up to date will not protect you against exploitation. As we discussed in more detail in that previous post, security companies and the press often label vulnerabilites that are not zero-day vulnerabilities as being them, which is not helpful in trying to understand the threat landscape. Our best guess was that the claim that these were zero-day vulnerabilites was included in those articles due to a press release from the discoverer of the vulnerabilites referring to them as being zero-day vulnerabilites (without any supporting evidence), as the discoverer’s post on the issue didn’t not make any reference to them being zero-days.

In the previous post we mentioned that one of the articles came from ZDNet, but more specifically it came from their blog Zero Day. It would be a pretty telling example of how bad security journalism is if they didn’t even understand what the namesake of their blog actually means. But making that assumption on one wrong article would be unfair, so we started taking a look to see if this had happened before and it clearly wasn’t a one time fluke.

We just had to go back to the 3rd to find another example, this time OpenJPEG zero-day flaw leads to remote code execution. The last two paragraphs make it clear this wasn’t a zero-day vulnerability:

The vulnerability was discovered by Aleksander Nikolic from the Cisco Talos security team in OpenJpeg openjp2 version 2.1.1.

Cisco Talos disclosed the vulnerability to affected vendors on 26 July, granting them time to prepare patches to fix the problem before public release.

So the vulnerability was discovered by a researcher, reported to the developers, and fixed before public release. There is no indication in the article or advisory that it has ever been exploited.

The discover also breaks down their vulnerability reports as Zeroday Reports and Disclosed Vulnerability Reports and you can see that this issue is listed as being the latter:


Heading back a few weeks we found the article Zero-day vulnerability found within MySQL database application. In this case the vulnerability was reported to the developer before it was disclosed:

On Monday, independent security researcher Dawid Golunski released his findings through a public security disclosure, stating that over 40 days have passed since the zero-day vulnerability was reported to the vendor.

Nothing in the article or the linked public security disclosure provides any indication it was being exploited before the developer was notified, so it is not a zero-day.

Posted in Bad Security | Tagged , | Leave a comment

Would You Be Surprised to Hear That SiteLock’s Idea of Independent Testing Doesn’t Involve Actual Independence?

Recently for several different reasons we have taken a look at claims made about quite a few web security services and products and noticed that there are often bold claims that seem highly unlikely to be true. There also is a decided lack of evidence put forward to back those claims, much less independent third-party evidence to back them. So we were surprised today to see a press release from the web security company SiteLock, Independent Testing Shows SiteLock Web-Based Malware Protection Outperforms Traditional Endpoint Solutions. Considering their track record, we wouldn’t have expected them to be the ones actually having independent testing done. After taking a quick look over the details of the testing, we found that, not surprisingly, the testing was actually the opposite of independent.

The test compared their ability to detect malicious code on websites against McAfee Complete Endpoint Protection ability to do that. It appears the testing was intended to show that products of the type that McAfee have are not well suited to doing this, but since there is not a comparison of multiple products in each category, the value that could be gleamed from the test is limited.

One finding of the test did stick out to us though:

SiteLock SMART provided 100 percent PHP and JavaScript coverage versus less than 6 percent coverage by McAfee

Considering the poor quality we have seen with SiteLock’s detection in the past, whether it be missing malicious code or falsely identifying non-malicious code as malicious, we had a hard time believing that that they would possibly detect 100 percent of the tested malicious code in a reasonable test.

A key question to determine the quality of the testing was how the malicious code being used in the test was picked. When the items tested are mentioned in the press release there source isn’t mentioned either time, here:

Testing a group of nearly 3,000 web-based malware examples to determine effectiveness

and here:

Tests showed that the SiteLock solution detected and cleaned 100 percent of the samples provided.

Looking at the complete report (PDF) by the Tolly Group, there is the answer:

The test corpus was provided by SiteLock and consisted of 2,972 samples that included PHP, JavaScript and other executables that contained a variety of attacks.

So SiteLock provided the items that would be tested against. The test clearly isn’t independent at that point and the real story would have been if SiteLock didn’t detect them all.

The complete report also makes no claim to the testing being independent.

While SiteLock knew ahead of time what would be tested, since they provided the items being tested, the company behind the other product was not allowed to see them:

In accordance with Tolly’s Fair Testing Charter, Tolly personnel invited representatives from McAfee/Intel to participate in the testing. Because of internal guidelines, McAfee/Intel was unable to review the test corpus in detail and had no further comment.

Based on that you wonder what else might be in their internal guidelines that could skew the test results.

Posted in Bad Security | Tagged , | Leave a comment

Press Release Journalism Unsurprisingly Leads To Bad Security Journalism

When it comes to the poor of state of cyber security, we think one of the important elements that has gotten us to the current situation is the poor state of security journalism. Instead of shining a light on the many bad practices of the security industry, journalist are too often repeat the claims of security companies without doing any due diligence as to their accuracy. From what we have seen with web security companies that is a bad idea, since you not only have companies that will blatantly lie to the public, but you also have a lot of companies who don’t seem to understand the basics of security.

One company that doesn’t seem to understand the basics of security is Wordfence, which a couple weeks ago we found doesn’t understand what a zero-day vulnerability is, leading them to be claiming to have exclusive knowledge of ones, when the vulnerability they were aware of are not in fact zero-day vulnerabilities at all.

Based on how often we see security products and services promoted as protecting against zero-day vulnerabilites or attacks, at least the marketing departments of security companies think that their customers are fairly interested in protection against them.

A zero-day vulnerability refers to a vulnerability that is being exploited before the developer has become aware of the vulnerability. To be able to protect against those when they start getting exploited requires you to be able to protect against any kind of vulnerability, since any type of vulnerability could be a zero-day vulnerability. That would be difficult to pull off, to put it mildly.

As we have found detecting those vulnerabilites in WordPress plugins for our Plugin Vulnerabilities service, quickly detecting them once they are being exploited isn’t necessarily difficult, but it hasn’t been something other companies dealing with WordPress security have not been doing (as can be seen in the fact we have found numerous of those that look to have been in the wild for some time with out other security companies doing anything about them).

What is far easier then actually protecting against or quickly detecting zero-day vulnerabilites is to simply label any vulnerability you have found as a zero-day vulnerability. That is what Wordfence has done, in their cases it doesn’t seem intentional, just their lack of security knowledge once again at work.

The distinction between an actual zero-day vulnerability and any vulnerability that a security company happens to discover is quite important. First, many (maybe most) vulnerabilities are unlikely to be exploited, whereas by definition, a zero-day vulnerability is one that hackers are likely to be exploited, considering they already have been exploiting it. Protecting against a vulnerability that isn’t likely to be exploited is of a lot less value than one that is likely to be exploited. Second, if the security company doesn’t disclose the vulnerability as soon as they discover it and notifies the software’s developer, then they have a chance to fix it before it would be exploited, but again by definition, a zero-day vulnerability is being exploited before they have had a chance to do that. If a fix has been released before the security company discloses it, then those keeping the software up to date will protected if there are an exploit attempts after it is disclosed, while that won’t be the case when a zero-day vulnerability at least when it is first being exploited.

That all brings us to today, where there was an example of bad journalism leading to unfounded claims of zero-day vulnerabilities. Over at Ars Technia an article titled “Security company finds five “zero-day” flaws in EMC management console” was put out. If you read the article there isn’t anything that backs up that these are zero-day vulnerabilites, just that vulnerabilites that were discovered. In looking at the post on the discoverer’s website that is cited in the article, there is no mention of zero-days at all, instead what they state is this:

The Digital Defense, Inc. Vulnerability Research Team (VRT) has identified six previously undisclosed security vulnerabilities found in the Dell EMC VMAX Management Product family.

Ars Technica was not the only news outlet claiming they were zero-day vulnerabilites, ZDNet has an article titled “Multiple zero-day flaws found in EMC storage systems“, which again doesn’t include anything that backs up that these are zero-day vulnerabilites.

So where did the idea that these were zero-day vulnerabilites come from?

The answer seems to be the press release the discoverer put out, entitled “Digital Defense, Inc. Discovers Multiple Zero-Day Vulnerabilities within EMC Unisphere for VMAX“. While zero-day vulnerabilites are mentioned in that, there isn’t any indication in that the vulnerabilites are being exploited or were being exploited before the developer knew of them, which would be required to make them zero-day vulnerabilites and not just vulnerabilites that this security company had discovered.

It really should go without saying that doing journalism based on a company’s press release, which makes a claim that isn’t included in their related post about the issue, isn’t a great idea if you care about getting things right.

Posted in Bad Security | Tagged | Leave a comment

So SiteLock Is Now Apparently Blaming Their Web Hosting Partners For Their Bad Practices

One of things that we had wondered for some time about SiteLock, the web security company that seems like is scamming their customers, was what explained their partnerships with so many web hosts. Before we found about the more scam level stuff going on with them, what we had see was they seemed to be quite bad at hack cleanups and the basics of website security. So we figured that the partnerships were not based on the web host believing that SiteLock was the best choice to help their customers, but about money. When we found about how SiteLock was taking advantage of people on large scale we started to wonder how much money must the web hosts being getting to continue those partnerships, considering that their partnerships with SiteLock couldn’t be good for their reputation. To a lesser degree we sometimes have had wondered why SiteLock was partnering with some web hosting companies that had some bad security practices or were making it harder to properly clean up hacked websites. We figured that they would at least be pushing these companies to improve those situations, but we saw no evidence of that occurring.

Several weeks back we ran across a couple of things that went a long way to answering those questions.

First, it turns out the majority owners of SiteLock are also the CEO and board member of a major web hosting company Endurance International Group, which does business under the brand names A Small Orange, Bluehost, FatCow, HostGator, HostMonster, iPage, IPOWER, and many more. That would seem to make it easier to get them to partner with SiteLock. From this we also know that at least at those web hosts, the web hosts are not in the dark about what SiteLock is actually doing and if they had a problem with it they could make a change directly at SiteLock. It also goes a long way to explaining why SiteLock wasn’t insisting on better security practices at web hosts, since their owners are also running a web hosting company that doesn’t have the best handle on security.

It important to note that neither SiteLock or the Endurance International Group is upfront about this connection between the two. The only place you will find out about the connection is in Endurance International Group financial reports, where they are legally required to disclose it. Even in those it hidden away, as SiteLock is not mentioned in them, instead they are referred to by the entity that owns them, Innovative Business Services. At the point where you legal are required to disclose something, it seems to us that would be a good indication that you should be upfront with your customers about what is going on, but clearly they don’t fell the same way.

Second, it turns out that web hosting partners are getting a lot of money, if the deal that SiteLock has with Endurance International Group is any indication. As of fiscal year 2014 the Endurance got 55% of the revenue coming from sales through the partnership with SiteLock. We wonder how people that have been strongly pushed to SiteLock by their web hosts would feel when they found how much money the web host is getting by doing that, especially in situation where they are dealing with a hacked websites. It also appears to create an incentive for them to not make sure their clients are secure, since they can make a lot of money off of those websites being hacked.

That brings up to the latest piece of information we ran across about their partnerships, which is that SiteLock is apparently blaming their web hosting partners for how the services are sold. Here is a tweet from one of the writers at WP Tavern:

Assuming that is true and we don’t have a reason to believe that it isn’t (the same person did a podcast interview with a SiteLock representative in June, in which their response to a question of SiteLock’s unsavory practices was that you should trust that person that it isn’t happening (despite it actually happening)), it is a rather outlandish claim. Even if you didn’t know what we just discussed, what kind of partnership would it be where one party has no control of how their services are being sold.

In reality from everything we have read and heard, SiteLock employees are the ones doing much of what is being complained about. Even if they were not, considering how much the web host is getting paid, it doesn’t seem believable that Sitelock wouldn’t have the leverage to stop bad practices.

More importantly in the case of Bluehost, that was mentioned in the previous tweet there, seeing as SiteLock’s owner also control Bluehost, they wouldn’t’ have a problem controlling how the web host sells SiteLock’s services.

We get the feeling that the idea here is that SiteLock and the web hosts each point the figure at the other and hope that more people don’t become aware that they are dealing with two parties so closely connected.

Posted in Bad Security | Tagged , | Leave a comment

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.

Posted in Bad Security | Tagged , | 2 Comments