Don’t Get Caught With Plugin VulnerabililitesWith our Plugin Vulnerabilities service you are alerted if you any of the WordPress plugins you use contain a security vulnerability.
Search This Blog
- WordPress Doesn’t Want You To Know That WordCamp Sponsor SiteLock Takes Advantage of People
- Here Are SiteLock’s Web Hosting Partners, You Probably Should Avoid Them
- Misleading Vulnerability Statistics and Plone Security
- Another Cyber Security Company In The News Failing To Do Security Basic With Their Own Website
- 123 Reg’s Partnership With SiteLock is Already Producing the Expected Bad Results
Did We Make a Mistake?While it seems to be acceptable for blogs discussing web security to contain numerous factual mistakes, we hold ourselves to a higher standard. We only write about things that we actually understand and only after we have double checked the information. So if you see a mistake in one of our posts please leave a comment on the post or contact us so that we can add a correction.
Category Archives: Bad Security
In looking in to some things for recent posts about SiteLock, their web application firewall (WAF) had come up a number of times and that then made us recall that previously it seemed that service was actually provided by the company Incapsula. Looking at the page for the service there was no mention of that or anything that might indicate that SiteLock was not providing the service themselves. The only mention of Incapsula on SiteLock’s website according to Google is them being cited in a couple of blog posts. The same holds true for mentions of SiteLock on Incapsula’s website.
So were we confused in thinking that there was connection between the two companies or have they just hidden it away from the public (like how one of their hosting partners wouldn’t admit to the ownership connection between SiteLock and them)? A little more looking showed the connection actually existed.
The True Provider of TrueSpeed CDN
Doing a traceroute for www.sitelock.com showed their IP address to be 184.108.40.206, for the which the canonical name is 220.127.116.11.ip.incapdns.net. Incapdns.net as in Incapsula, which you wouldn’t expect since you expect that SiteLock would be using their own TrueSpeed content delivery network (CDN) to serve their website. Next up we did a traceroute on their WordPress focused sub-domain wpdistrict.sitelock.com, which showed a canonical name of iasx4.sitelockcdn.net and an IP address of 18.104.22.168, which in turn has a canonical name of 22.214.171.124.ip.incapdns.net. We then looked at several of their customers websites listed in case studies on wpdistrict.sitelock.com and found they were running through Incapsula as well.
From all that it is clear that the TrueSpeed CDN is actually being provided by Incapsula, which you wouldn’t have any clue if you looked at how SiteLock describes the service. One part of the description that stood out for us was this:
Dynamic Content Caching
SiteLock patent-pending technology continuously profiles website resources, gathering information on how content is displayed. Static content can be safely cached. Some dynamic content might change continuously, while other content might rarely change or change only for specific users. This information enables truly optimized caching, and ensures content that is rendered is accurate—a premium feature you won’t get with most content delivery networks.
To claim you have a patent pending certainly makes it sounds like you provide the service yourself. But a quick search pulled up a PDF datasheet for Incapsula’s Content Delivery Network, which pretty clearly is the source of material on SiteLock’s page, with some rewriting of the text having been done. Here is relevant section from Incapsula’s document:
Dynamic Content Caching
Patent-pending advanced learning algorithms continuously profile website resources, gathering intelligence on each resource. Some of these resources, which may be dynamically generated, rarely change over time and for different users. This intelligence allows for optimized caching and ensures resource accuracy.
SiteLock’s lack of truthfulness to their customers about this is pretty troubling as all of the customer’s website’s traffic is going to be running through a company that they don’t have a relationship with or are even likely to know is involved. Even if there is no concern about Incapsula, SiteLock could always switch to some other provider without notice, that isn’t as trustworthy and their customer could find that out too late.
This definitely is something that should make people avoid SiteLock, as trust is so important when it comes to security companies.
What About TrueShield Web Application Firewall?
Our looking into a connection between Incapsula and SiteLock started with looking for a connection with SiteLock’s web application firewall (WAF), so is that also provided by Incapsula as well? The circumstantial evidence points in that direction, but there was no smoking gun that we have found so far.
From a practical stand point if you are already running the website’s traffic through Incapsula it would seem to be easier to use their existing WAF in their systems than creating your own and then integrating that in to their systems, if they would even allow it. SiteLock’s CDN and WAF were introduced at the same time, so that would certainly fall in line with the possibility of them having the same source.
Here is the screenshot of a report from SiteLock’s WAF from the service’s page on SiteLock’s website:
And here is a screenshot of a report form Incapsula, also related to “Bot Access Control”:
The data presentation is quite similar between the two of those, which we have hard time believing could have been coincidental.
Know Something More About The Connection Between The Companies?
If you are aware of additional details related to the connection between SiteLock and Incapsula please leave a comment.
High Profile Cyber Security Company CrowdStrike Fails To Do Basic Security Step With Their Own Website
When it comes to security companies we often say that they many of them don’t know and or care about security, which we think explains a lot of why security is in such bad shape these days. One example that we often find of this is that these companies are failing do the basics when it comes to the security of their own websites. We recently looked at one cyber security company that claims to have “clients in the intelligence community, DoD and nearly every cabinet agency” and isn’t bothering to keep the software running the various parts of their website up to date while telling the public they need to take advanced measure to protect their websites. They are not the only cyber security that has failed to that.
CrowdStrike was recently in the news due to their investigating the security breach at the Democratic National Committee (DNC) and placing the blame for it on the Russia government. They offer a variety of products and services intended prevent security breaches and respond after them. They also happen to be running an outdated and insecure version of WordPress on the main portion of their website:
The blog section of their website is running an even older version:
Like the previous case what makes is particularly troubling is that they are not just running an outdated major version of WordPress, version 4.6 was released in August, but they are not running the latest version of 4.5, 4.5.4. That isn’t normal, as back in WordPress 3.7 a new update system was introduced so that minor updates normally happen automatically. So either CrowdStrike disabled those automatic updates (which isn’t a good idea) and then failed to apply the updates manually or their is some incompatibility between their hosting environment and the update system and they also failed to apply the updates manually. If it was the later, then they could actually help improve security by working with the WordPress developers fix whatever is causing those automatic updates to no happen.
The next question is whether this an aberration or if this is indicative of larger problems with handling and understanding of security at the company, which is something that companies looking to use their products and services or journalist looking to cite them should probably find out.
Anti-Malware Security and Brute-Force Firewall Plugin Uses Non-Existent Brute Force Attacks To Get Registrations and Donations
When it comes to WordPress security, one thing we can’t emphasis enough is that people putting out security products and services for it don’t seem to have a good grasp of security. One of the most glaring examples of this is how often the falsehood that there are lots of brute force attacks against WordPress admin passwords happening, despite the evidence presented that they are happening actually showing the exact opposite.
Recently, while doing testing on how WordPress security plugins did in protecting against real world plugin vulnerabilities (short version, they haven’t done well in the testing so far) for our Plugin Vulnerabilities service we ran across the plugin Anti-Malware Security and Brute-Force Firewall. The plugin is one of the most popular security plugins, with 100,000+ active installs according to wordpress.org.
On the Firewalls Options page you will find that they have an option for Brute-force Protection:
So they are using a non-existent threat to try to get people to register and donate. On top of that, the protection seems to involving modify a core file, which isn’t a very good idea.
SiteLock Provides A Good Example of How Security Companies Are Working Against Improving Cybersecurity
Looking at the news recently you wouldn’t have to look hard to see that cyber security isn’t in good shape and that isn’t a new problem. A big part of the problem is the security companies, the organizations that are supposed to be improving things are in a lot of cases making things worse instead. For example, on the one hand we have a situation where many people are not doing the basics, while security companies are pushing more advanced security products and services, which they don’t provide evidence that would provide any value over doing the basics (or even evidence they would provide the protection to same degree as doing the basics). What make this issue stand out so much is that even the companies themselves are often failing to the basics, we recently looked at one cybersecurity company that claims to have “clients in the intelligence community, DoD and nearly every cabinet agency” and isn’t bothering to keep the software running the various parts of their website up to date while telling the public they need to take advanced measure to protect their websites.
October is National Cyber Security Awareness month, which unfortunately isn’t a time when these companies consider that they are not having a positive impact, but instead yet another chance to hock their wares. Case in point is SiteLock, over at their at their WordPress focused blog, The District, they have a post, National Cyber Security Awareness Month – What it Really Means for WordPress Users. In that post they include a list of simple security steps. Since the post is WordPress focused you would expect that making sure WordPress and it plugins are up to date would be one of them, but it isn’t. Here is what they listed below:
Simple Security Steps to Implement Today
Some of these may sound simple, but if not implemented can put you at risk.
- Never write down your username and passwords. Use a password manager tool like LastPass, 1password or others.
- Use anti-virus software on your computer.
- Always use a Virtual Private Network when connecting to public wifi. Learn more about VPNs here.
- Install a Web Application Firewall on your website.
Instead of updating the software they suggested using a web application firewall and they linked to their service that includes that. If you go to the page with the details of their WAF you will find that they don’t provide any evidence, much less independent third-party evidence, that this provides any protection at all (not even from rigged testing, like they recently did for another part of their service).
Actually updating your WordPress plugins would actual make you more secure, as vulnerabilities are frequently fixed in new versions, but telling you that wouldn’t make them money.
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:
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:
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.
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.
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:
@andyschwartz Sitelock is a trusted partner of ours, we suggest Sitelock because they do work well with our services.
— HostGator Support (@HGSupport) October 10, 2016
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:
— White Fir Design (@whitefirdesign) October 10, 2016
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)
@whitefirdesign Hostgator has it's own CEO, who does not own Sitelock.
— HostGator Support (@HGSupport) October 10, 2016
We then sent a reply clarifying that and they replied:
@whitefirdesign Thank you for that clarification.
— HostGator Support (@HGSupport) October 10, 2016
At that point we said that we hope they would start to disclose the true nature of their partnership:
@HGSupport Hopefully you will start disclosing that relationship and that you get paid when SiteLock services are sold to your customers.
— White Fir Design (@whitefirdesign) October 10, 2016
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):
@whitefirdesign We thank you for your feedback, we cannot confirm this as fact, so we will offer no comment to your claim. We apologize.
— HostGator Support (@HGSupport) October 10, 2016
At this point, they claim they can’t confirm they are getting paid:
@whitefirdesign Your asking us to confirm Hostgator gets paid, by Sitelock, and unfortunately we cant do that. We apologize. We do trust EIG
— HostGator Support (@HGSupport) October 10, 2016
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:
@whitefirdesign We appreciate your feedback. We can offer you no other comment at this time.
— HostGator Support (@HGSupport) October 10, 2016
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.
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:
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:
Their main website is also running on an outdated version of Drupal:
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 .
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.
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:
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
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:
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.