Checkmarx Fails the Wikipedia Test

When looking at the poor state of the security industry one of the things we have noticed is that far too often you can get better information from the Wikipedia than you can from many in the security industry.

One re-occuring issue we see is people in the security industry referring to dictionary attacks, which involves trying to log in using common passwords, as being brute force attacks, which involve trying to log in using every possible password. The Wikipedia by comparison manages to accurately describe both dictionary attacks and brute force attack. They even mention the contrast between them:

In contrast to a brute force attack, where a large proportion of the key space is searched systematically, a dictionary attack tries only those possibilities which are deemed most likely to succeed.

While looking for some information on the website of security company Checkmarx recently we ran across them not understanding the difference between hashing and encryption.

The last sentence of an article looking at a hack of website is as follows:

Included in the leaked information of the VerticalScope forum and website users were their usernames, user IDs, email addresses and encrypted passwords.

For people that know about password security the use of encrypted passwords would seem rather odd and would indicate things were not being done securely.

Further down the article it goes in to more details.

Finally, a vast majority of the passwords were encrypted using methods that were very easy to break using MD5 with salting and less than a couple million of the 45 million passwords were sufficiently encrypted.

That brings us to the first sentence of the second paragraph of the Wikipedia article on MD5:

Like most hash functions, MD5 is neither encryption nor encoding.

To understand why that matters, it helps to think of hashing as one way encryption. When using that on a password the actual password is converted in to some other text, but unlike encryption you cannot decrypt it. That way even if someone gets a hold of the stored versions of the password, say on a website, they can’t get the original password.

If you wondering how the system then know how if the correct password is being entered in the future, the answer is that the password entered then is run through the hashing algorithm and the result is checked to see if it matches the stored version.

The misuse of the term encryption continues in the article, even being used to promote one of Checkmark’s services:

The Importance of Proper Encryption

VerticalScope attempted to hash their passwords using MD5 with salting which security minded developers agree is an “emphatically poor choice” when it comes to securing passwords. First designed in 1992, the MD5 algorithm is a hash function which produces a 128-bit hash value. As early as 1996, flaws were determined in the design of MD5 and in 2005 it became apparent that MD5 was not collision resistant, a key component for a secure encryption algorithm.

How to Ensure Proper Encryption

In addition to avoiding MD5 hashing as your method of choice, it’s important to also avoid SHA-0 since it has been conclusively broken, SHA-1 as well as DES as it can be broken by the average desktop computer’s GPU.


When choosing your encryption method, be sure to focus on using a symmetric algorithm key size that is at least 168 bit and if you’re dealing with financial transactions, use at least 256 bits. Ensuring that your application protects all cryptographic keys within the file system will also help ensure that your encrypted data is not exploited.

Additionally, using a static code analysis solution to ensure that your application has sufficient encryption is also recommended as your developers will be able to mitigate any encryption issues at the earliest stages of the SDLC. Checkmarx’s CxSAST scans and for and identifies encryption security issues in multiple languages including Java, CPP, JavaScript, Objective C, C++ and Perl.

CheckMarx Running Outdated and Insecure Version of WordPress

Back in November over at the blog for our Plugin Vulnerabilities service we discussed the fact that the security company Checkmarx was making a claim that a number of WordPress eCommerce plugins had severe vulnerabilities without providing any evidence, even what the name of the plugins was, to support that. That didn’t stop security journalists from covering the claim at the time. The details were supposed to be released later, but when went looking for them several weeks ago we couldn’t find them and when we contact Checkmarx to inquire about them, we received no response. At this point we think it is reasonable to wonder if the vulnerabilities ever existed.

It turns out though that this company that doesn’t seem to have a problem with making what appear to be baseless claims about the security surrounding WordPress, uses WordPress on its own website at the same time.

What should be surprising, but is an all too common occurrence, it also turns out that they are running an out of date and insecure version of WordPress on their website as can be seen in the source code of the website’s pages:

The Checkmarx Website is Running WordPress Version 4.6.1

There have been four releases of 4.6.x with security fixed since then: 4.6.2, 4.6.3, 4.6.4, and 4.6.6 (they also have updated to the latest major release of WordPress, 4.7). The oldest of those was released over four months ago.

The plugin listing its version number below the line for WordPress is not surprisingly also out of date.

What makes their lack of updating stick out is that WordPress would have normally automatically updated without any action required by Checkmarx, due to the automatic background updates feature. So either Checkmarx’s server environment has some incompatibility with that (which they could help WordPress to get fixed) or they intentionally disabled them. In either case you should expect that a security company would be concerned enough about security enough to manually apply those updates.

With all of that, it doesn’t seem like it should be all that surprising that security is in such bad shape these days.

SiteLock Incorrectly Labels Spam Content In Databases as Malware

When it comes to the many problems that we hear about with the web security company SiteLock one of the most prominent is that they falsely claim that websites contain malware and then web hosts they are partnered with shut off access to the websites based on those false claims, while suggesting to their customers that they hire SiteLock to clean it up. (It is important to note that while this significant problem, you shouldn’t ignore claims coming from either SiteLock or your web host that the website contains malware or is otherwise hacked.)

There are a lot of questions that issue raises.

One being why would web hosts shut off access to their customers websites based on the word of company known to make false claims? That one is answered in part by the fact that those same web hosts make a lot of money if their customers purchase SiteLock services and by the fact that the owners of SiteLock also run a major web hosting company.

Another question being, what causes the false claims? For that, part of the answer is the SiteLock’s scanner, while labeled as a malware scanner, also tries to detect issues other than malware. That causes problems in trying to resolve real issues because people are being told that they have an issue other than they really have. Another issue with that is that they don’t seem to very careful in their detection of those other issue, so in one situation where we consulted on it looks like a website was falsely claimed to contain malware due to the phrase “hacked by” appearing on a page (we recently ran across a similar issue with the Sucuri SiteCheck scanner). Then people at SiteLock and their web hosting partners either don’t understand the quality issues with the malware scanner’s data or don’t care, leading to owners of websites falsely being told their website contain malware and having them shutdown.

A recent tweet from SiteLock shows another example of this, as they have a pretty bad idea of what constitutes malware in the database:

Malware refers to one of two things when it comes to websites, malicious code in general or malicious code being served to those visiting a website. Spam content itself would not be considered malware.

More problematic with that, is that if you had someone submit a comment with spam content on a WordPress website it would be stored in the database, so if you start labeling any spam keywords in the database as malware you would cause any database with spam comments, even if they were in the trash, as having malware.

That seems like a possible explain of another problem we have been hearing about recently with SiteLock, which is them claiming that backups of website’s databases contain malware.

Another Reminder That People May Fail To Take Basic Security Measures While Doing More Advanced Ones

When it comes to what security companies do one of our major concerns is they tell people that need to take all sorts of advanced security measures while some many people are still failing to do the basics. Our main concern for that for some time was that people would feel overwhelmed and instead making sure they are doing the basics, they wouldn’t do anything. What we have seen more of recently is that people will do more advanced things instead of the basics, which can produce bad results, as was the case with one of security company Trend Micro’s websites getting hacked due to them failing to do one of the basics and relying on more an advanced measure that failed (even after they got hacked they didn’t take the more basic step).

Another example we ran across recently involved someone reporting that when trying to install plugin for checking for vulnerable WordPress plugins there was fatal error. The error was caused by the plugin trying to use a function that was introduced in WordPress 3.4, which was released nearly 5 years ago. That doesn’t seem like it should be a problem, but was in that case because the website they were trying to install it on was still running WordPress 3.2.1.

Why SiteLock’s Poor Cleanups Lead to Website Reinfections

If you follow our blog you will have seen us say before that we are often brought in to re-clean hacked websites after another has cleaned and then it hacked again. And as we have said before, while it isn’t always the fault of a company that did the a clean up that a website has gotten hacked again, what we have found is that in almost all the instance where we are brought in to re-clean websites the first company has cut corners. As one of three main components of a proper cleanup is trying to determine how the website was hacked and when we ask if the source of the hack was determine by the first company that answer is almost always that trying to determine that never even came up.

One of company that comes to mind as one that doesn’t do proper cleanups is SiteLock. As we seen for years they don’t upgrade the software on the website (which is large part of one of the other main components, getting the website secure as possible) and they don’t determine how the website was hacked.

So we were somewhat surprised to see a recent SiteLock had a post on their blog “Why Website Reinfections Happen”, which while written to get around the issue, is really a indictment of how SiteLock’s improper cleanups leaves websites vulnerable to being reinfected.

In the post they start out by explaining why websites get reinfected:

The short answer is that it’s most likely due to unresolved vulnerabilities. While it may seem like you’ve been singled out and targeted by some menacing hackers, most of the time that isn’t the case. The majority of website compromises are preceded by automated campaigns that locate websites vulnerable to a particular exploit the hacker wishes to employ.

That would dictate as part of the original cleanup you would want to resolve the vulnerability, so what does SiteLock claim are the causes of the vulnerabilities.

Up first is outdated software with vulnerabilities:

It is for this reason that we stress not only cleaning the website, but also patching all software and identifying and remediating all vulnerabilities present on the website.

While they stress this, their cleanup don’t actual involve updating the software and neither doing their ongoing security services. They do try to get to what they actual provide by saying this:

It is also advisable to take a more proactive approach in the future by utilizing a web application firewall (WAF) to protect your website.

The problem with this is using a WAF isn’t more proactive, instead it is reactive, as the WAF often would need to have code or a rule written to protect against a vulnerability, so unless the WAF maker is aware of a vulnerability before it is fixed that will happen after the software is able to be upgraded. There is another problem with this that trying to protect in this manner is more likely to not work properly, as can be seen with what happened recently to another security Trend Micro, decided not to keep their one of their WordPress installations up to date.

Also, worth pointing at this point is a post from yesterday where we look at the fact that one of SiteLock’s major web hosting partners (which also happens to be run by SiteLock’s owners) is offering installing outdated and insecure software on their customers websites.

Next up is unfixed vulnerabilities, which are usually newly discovered (unless a software developer doesn’t fix vulnerabilities promptly when they are notified of them):

On the less common end of the spectrum we see compromises due to undocumented vulnerabilities, where the bad guys were the first to the punch with discovering that a vulnerability exists.

To know if there is an unfixed vulnerability that was exploited you would need to know how the website was hacked, which isn’t what SiteLock does. Instead they get back to the WAF:

In this instance, your best defense is taking a proactive approach by implementing and training a web application firewall (WAF) to block future attacks.

There is no explanation of how you are supposed to be able to train the WAF to block future attacks, when you haven’t determined how the attack happened. Going back to previous issue, it also would be more effective to get vulnerability fixed in the software than trying to block attacks, because sometimes even a minor change can evade a block, whereas properly fixing the vulnerability at its root should stop any attack. Doing this would also would likely leave others using the same software vulnerable unless they used a WAF that provided protection against the vulnerability.

Also worth noting here, is that while SiteLock promotes the WAF that is included in some of their services as being their own it is fact Incapsula’s WAF.

A Nexus of Insecurity Between EIG, SiteLock, and MOJO Marketplace

Last year as we started hearing and seeing more and more complaints about the web security SiteLock one thing we wondered was why would web hosting companies continue to partner with a company that was harming their reputation. The answer is in part that they get a lot of money from SiteLock, the Endurance International Group (EIG) has disclosed to investors that they get 55 of the revenue from SiteLock services through their partnership. When you are talking about $300 for a hack cleanup or $100 a month for a protection service, their cut of that could easily be more than they are getting paid by the customer for the service they are actually providing (without the costs that come with actually providing something).

That wasn’t the only explanation for that particular partnership, as turns out that the majority owners of SiteLock are also the CEO and a board member of EIG. While EIG isn’t all the well known by that name, they provide web hosting under a number of well known brands including A Small Orange, Bluehost, FatCow, HostGator, iPage, IPOWER, JustHost and quite a few others.

Web hosts can play an important role in keeping websites secure. They have a responsibility to keep the things in their power secure and they can also do things that help their customers do their part. The type of partnership that SiteLock has with EIG could influence EIG to not take the steps they could to keep websites secure since they can potentially make so much money off websites they host getting hacked. While we would think that might impact them doing extra things to help their customers, it turns out that EIG is not doing something that is their responsibility.

We are currently working on a cleanup of a hacked website hosted with JustHost, where JustHost and SiteLock have pointed to an outdated Joomla installation as being a weakness. While looking around at things we found that JustHost is currently offering to install that version of Joomla, despite it having not been supported for over two years.

From the JustHost cPanel control panel clicking the One-Click Installs button took us to The company behind that website, MOJO Marketplace, is another EIG company, which among other things provides the ability to install various software on websites. Looking over that page we found that not only were they offering to install the version of Joomla, 2.5.28, that JustHost and SiteLock were pointing to as being a weakness, but they are offering plenty of other outdated and insecure software. Below we have highlighted some of those.

If we were not already well aware of what SiteLock is really about, we would asking why SiteLock would be partnered with a web hosting company putting their customer at risk like this. It is worth noting that as far as we are aware none of SiteLock’s protection services include updating software, despite that being an important measure (and them seeming to be aware of the risk of outdated software).


MOJO Marketplace is Installing Joomla 2.5.28

First up MOJO Marketplace is still offering Joomla 2.5.x despite that reaching end of life (EOL) on December 31st, 2014.

MOJO Marketplace is Installing  Joomla 3.6.4

The next release of 3.x, 3.6.5, was released on December 13 of last year and included security fixes.


MOJO Marketplace is Installing Drupal 6.33

Not only has Drupal 6 been EOL over year ago, but there were five security updates after 6.33: 6.34, 6.35, 6.36, 6.37 and 6.38.

MOJO Marketplace is Installing Drupal 7.43

The next release of Drupal 7, 7.44, was released 11 months ago. Not only did that include security fixes, but so did the subsequent 7.52.

MOJO Marketplace is Installing Drupal 8.1.0

The next release of Drupal 8, 8.1.1 was released a year ago. Subsequent to that there have three releases with security fixes: 8.1.3 8.1.7, and 8.3.1.


MOJO Marketplace is Installing Magento

That version is two years out of date, with being released in May, 2015. That version included security fixes, as did 7 subsequent versions:,,,,,, and


MOJO Marketplace is Installing PrestaShop

The PrestaShop version is more than a year out of date, was released last April, and a security fix was released in the subsequent


MOJO Marketplace is Installing Moodle 3.0.4

Moodle 3.0.x was replaced as the most recent major version of Moodle just about a year ago. Support for 3.0.x ended a week ago. Not surprisingly the version of 3.0.x being offered isn’t recent, with the next version 3.0.5, being released 11 months ago. That version included security fixes as well five subsequent releases: 3.0.6, 3.0.7, 3.0.8, 3.0.9, and 3.0.10.


MOJO Marketplace is Installing MediaWiki 12.3.6

MOJO Marketplace isn’t offering the latest major version of MediaWiki, but at least you could explain providing 1.23.x as it long term support release in they were keeping it up to date. But as with the other software they are not doing that. The next release of 1.23.x, 1.23.7, was released in November of 2014. That was a security release, as were 8 subsequent releases: 1.23.8, 1.23.9, 1.23.10, 1.23.11, 1.23.12, 1.23.14, 1.23.15, and 1.23.16. Version 1.23.x reaches EOL this month.

SiteLock Unintentionally Provides Reminder That They Don’t Keep WordPress Websites Secure

One of our long time concerns with the security industry is that that their efforts to sell more advanced security measures make it less likely that people will take more basic security measures. Right now even many security companies are not doing the basics when it comes to security and as a hacking of one of Trend Micro’s websites earlier this year showed, more advanced security measures are not necessarily even as effective as the basics.

Another example of this comes from a recent case study from the security company SiteLock where they highlight a website that is using a version of a WordPress plugin with known vulnerabilities while they falsely claim one of their services is insuring the website is “safe and secure at all times.”

The Unmentioned Business Relationship

Before we get the details of that it is worth noting that SiteLock isn’t being upfront about how they came to be involved with the website mentioned in the case study, which seems important when you consider they are leaving it insecure.

Here is their explanation:

One day Kasal unexpectedly received an email from his hosting provider alerting him that his blog had been infected with malware. Due to the stealthy nature of the attack, there were no obvious signs that his blog had been compromised. “I was unaware that my site had been hacked and at a total loss as to how to find or fix the problem,” he recounts.

Kasal’s hosting provider informed him that his blog would be taken offline unless he removed the malicious code that was inserted on his website. His host recommended he contact SiteLock® to remove the malware and help prevent future attacks.

What they don’t mention is who the web host is or why they recommended SiteLock. Looking at the DNS records the web host is IPOWER. That is one of the many brands names that the Endurance International Group (EIG) does business under. That is rather important in explaining the recommendation, as it turns out that SiteLock’s owners are the CEO and a board member of the company and the company has disclosed that they get 55 percent of revenue coming from the sales of SiteLock’s services through a partnership they have. If there were not those connections we doubt the web host would be recommending SiteLock, considering the many problems with SiteLock (one the reoccurring complaints is that they sell protection services that don’t actually protect websites).

SiteLock Doesn’t Detect Vulnerabilities

The case study doesn’t go in to details as to how the website was cleaned, but no mention was made of doing two important parts of cleanup, making the website secure as possible (which usually mainly involves getting the software up to date) and trying to determine how the website was hacked. Based on our own experience being brought in after them to re-clean websites and everything else we have seen, it is likely those things were not done.

Without knowing what caused the website to be hacked you can’t say what would have prevented it from happening, but we can be fairly sure that SiteLock’s idea of a “proactive approach” isn’t the best way to secure the website going forward:

Once his website was clean, Kasal decided to take a proactive approach to website security by implementing SiteLock® SMART, a daily scanner to help protect his blog from future attacks. SMART provides continuous file scanning to detect vulnerabilities and malware, including backdoor files and malicious code. If malware is identified, it is automatically removed and Kasal is immediately notified.

SMART also provides a full website analysis of each scan, ensuring Kasal’s site is safe and secure at all times.

It is strange that they are describing that as being proactive, since it is clearly reactive. If you are detecting malware on a website, it means it has been hacked and it wasn’t protected. There are further problems with that approach, like the inability to undo the compromise of a website’s data and that SiteLock has a limited ability to remove malicious code automatically (when they are even successful at detecting it).

A quick look at the website shows that is a couple of vulnerabilities that SiteLock must not have detected. Looking at the source code of the website’s pages you scan see that the version 2.9.45 of the plugin WordPress Download Manager is in use:

The plugin is several versions and a couple months out of date, with the next version, 2.9.46, having been released on April 17. That version fixed two vulnerabilities in the plugin, which is somewhat obliquely mentioned in the changelog with these two entries:

  • Added nonce check with settings form
  • Blocked unwanted file type upload

This is a perfect example of where doing the basics would be better, because if the website’s owner was keeping their plugins up to date they would actually be protected against those vulnerabilities. They wouldn’t even have to take manual action do that as there are a number of options available, including our Automatic Plugin Updates plugin, to have plugin updates happen automatically.

Keeping plugins up to date is free, unlike SiteLock’s service, but would another paid service actual have warned about those vulnerabilities? We know of one, our Plugin Vulnerabilities service, which warned about both vulnerabilities even before they were fixed (we also were the ones that discovered one of the vulnerabilities).

One last thing to note is that instead of SiteLock being able to tout that it actually detected those vulnerabilities or any other issue, they instead point to the number items checked:

SiteLock captured’s SMART scan results from a 30-day time frame. During the given 30 days, over 170,000 files, 120,000 links and 15,000 pages were thoroughly scanned for malware.

Sheer numbers clearly don’t equal quality.

Site5 Referring to SiteLock as a Third Party Seems Disingenuous At Best

As we have looked closer at the web security company SiteLock over the last year one of the things that has stuck out is how their web hosting partners are not being upfront about the nature of their partnership with SiteLock.

As we have mentioned before when it comes to one of their biggest web hosting partners, Endurance International Group (EIG), the company has disclosed to investors that SiteLock not only pays them more than half fees for services sold through their partnership, but the CEO and a board of EIG also are the major owners of SiteLock. Those seem like things that should be disclosed to their customers as well since there is an obvious potential for conflict of interest with that relationship, for which their customers should be aware of when considering their recommendations regarding SiteLock. Instead we have found previously that one EIG brand, HostGator, wouldn’t even publicly acknowledge those connections. In that instance they referred to SiteLock simply as a “trusted partner”.

We are frequently contacted by people that have had their web host shut down access to the website based on a claim that the website is hacked and recommend that they hire SiteLock to handle resolve the situation. While in many instances the websites are in fact hacked, there are some serious issues with false claims that websites are hacked. So when we are contacted in those situations we want to find out what evidence there is that the website is hacked first, so that we can double check if the website is in fact hacked before starting on a cleanup. Through that we were recently forwarded a report from the web host Site5 (about a website that was actually hacked), which referred to SiteLock is this way:

If you don’t feel comfortable removing the infected files yourself, we recommend contacting a third party professional who can assist with removing malware, such as SiteLock.

Considering that Site5 has been part of EIG for nearly a year and the connection between EIG and SiteLock, calling them a third party, while maybe technically accurate, clearly doesn’t provide their customers a honest understanding of the connection between the companies. (Not surprisingly from everything else we have seen related to EIG, the quality of Site5 service and support looks to have gone downhill since becoming part of EIG, just look at the number of negative reviews they have received on their BBB page since the purchase).

There Should Need to Be Evidence That Security Measures Are Effective, Not Ineffective

When it comes to security advice for websites, there is a nearly endless supply. What there decidedly isn’t is an abundance of is testing or other evidence presented that the measures mentioned in that advice are effective.

That seems particular acute when it comes to advice to use paid security products and services, for which we have frequently see bold claims about their effectiveness in their marketing materials, but we have seen almost no evidence presented as to their effectiveness (when it has, it hasn’t been very reliable, for example, one company claimed to have had independent testing done, when the testing decidedly was not independent).

That brings us to a couple of recent comments on one of the posts on the blog for our Plugin Vulnerabilities service.

We had noted that a lot what is supposed to provide protection doesn’t actual do that and cited our testing to see if WordPress security plugins could protect against real vulnerabilities in other plugins:

A lot of what is portrayed as protecting, including a lot of security hardening, doesn’t actually provide any protection. There is even a term for that type of thing, security theater. That is part of the reason we started doing testing of security plugins against real vulnerabilities, to show what, if any, protection they provide. So far BulletProof Security hasn’t provided any, which is what brought this up in the first place.

The response we got to that was this:

This is a big claim and it is one you would need to back up with some proof, especially given that so many people rely on them to protect their websites. Please point me to articles which back these statements. As a typical web dev customer who spends time hardening sites, and promoting a secure WP service, I’m unconvinced about your claims.

This seems to us to be backwards, the onus should be on proving something actual provides protection. Just because a lot of people are doing something that doesn’t mean that is effective, especially since a lot of people are following advice from others that don’t actual have the experience needed to be a reliable source.

Now in reality we have also written plenty about this sort of thing from years ago when we wrote about how hiding the WordPress version isn’t an effective security measure (this seems to have dropped off as claimed important security step) to the currently very popular, but false, claims that there are a lot of attempts to brute force WordPress admin passwords (which are pushed by security companies that then tell you their product or service is the solution). That second item is also a good example of why evidence is important, because we were actually able to disprove the claim based on the evidence that security companies were presenting as supporting it.

SC Magazine Is Arming Their Readers With False Information

When it comes to the poor state of security these days, two of the important players to get us where we are, are security companies and the security journalists that are covering them. Security companies have shown for years that don’t know and or care much about security. You would think that with the high profile nature of security today and how bad things are, that journalist would be covering that aspect. It wouldn’t take digging very deep to find lots of material. Instead when it comes to journalists covering security they seem to be more interested parroting the claims of security companies instead of doing any actual journalism.

Take the company SiteLock, which you only have to look what Google suggests when you do a search on them to know about their well earned reputation:

Google second suggestion is "siteLock scams".

Despite that, instead of any coverage of how they and their web hosting partners take advantage of people, journalists would rather parrot false claims they make. Last week looked at a recent example where journalists hadn’t bothered to do any fact checking before running with a SiteLock claim of a trending threat, which if they had likely would have warned them about the veracity of their claims.

Earlier this week we looked at another one of SiteLock’s claims of trending threat, which once again was based on falsehoods. Most notable claiming that a backdoor script with incredibly well known malicious code was not widely recognized:

The code within the shell used to gain the initial foothold is currently listed in the SiteLock malware database, but does not appear to be widely recognized as a threat by many website security vendors at this time. You may use the code snippet below to manually add the shell to your security mechanisms.

In the case of both of SiteLock’s claimed trending threats SC Magazine provided parroted coverage. With the more recent article we left a comment that pointed to a number of the problems in their reporting, but so far it hasn’t been approved, so anyone reading the article is left without a possible counterpoint to the inaccurate information in it.

Providing their readers with false information isn’t in line with how SC Magazine describes themselves in the footer of their website:

SC Media arms cybersecurity professionals with the in-depth, unbiased business and technical information they need to tackle the countless security challenges they face and establish risk management and compliance postures that underpin overall business strategies.

To give some idea of the problems with just that one article, let’s take a look at a few issues with the article.

Here is paragraph that has the false claim that code stays hidden from security programs:

The code manages to stay hidden from many security programs, Kipp noted, suggesting cybersecurity teams manually add this piece of code to their security programs so it can identify an attack.

SiteLock didn’t provide any evidence to back this up and from our years of experience we can say that it either isn’t true or the web security industry is in much, much worse shape than even we think it is in. What is also worth noting there is the link in that sentence, which goes to Looking at that you can probably tell that that page doesn’t actual contain any code, instead it is a sales page. It isn’t clear what they could have been intending to link to because there is no link to any code in SiteLock’s post.

The following paragraph refers to taking control of a computer, but the claimed threat involves taking over websites not computers:

The malware not only enables an attacker to obtain administrative control of a computer, but it also makes the computer’s information publicly available on the web. The reason for this is oddly practical, from the cybercriminals point of view.

SiteLock Services Don’t Update Web Software

We also found the final paragraphs of the article interesting:

Because the malware only goes after known issues with these CMS programs Kipp said it is imperative that those using this software are up to date with their security patches.

“This should really drive home the importance of patching your CMS platform to website owners. Automated campaigns like these are run on an ongoing basis, which attack websites on an almost indiscriminate basis. The majority of web attacks aren’t targeting websites based on their content or popularity, but based on their use of vulnerable outdated software. These are the low-hanging fruit of the web, he said.

First off SiteLock’s report makes no mention of the need to update software, but more importantly as far as we aware SiteLock’s security services don’t involve keeping software on a website up to date, as can be seen in a previous post we did specifically mentioning they don’t do that and one about websites they included in case studies that were running outdated software. That discrepancy between what they say is important here and what they are selling to their customers seems like something a journalist might want to ask them about.

It is also worth noting that SiteLock doesn’t cite any specific vulnerabilities being exploited, which would lead us, based on plenty of experience with that type of claim, to believe that they likely don’t know how the websites were being exploited. We have often seen outdated software blamed as the source of hacks in cases where the person making the claim hadn’t reviewed any evidence that would actually support the claim and in some cases where the software was actually being kept up to date.