Category: Bad Security

Joomla 3.7 is Not Hack-Proof

When it comes to bad information on the security of websites, far too often that information is coming from companies offering security services. A recent example we came across, while dealing with a hacked website, involved a Joomla focused web development company that in their marketing their service for upgrading or migrating to Joomla 3.7 claimed that Joomla 3.7 is “hack-proof”:

That certainly isn’t a claim that is made by Joomla (nor would you expect it to be a claim that is likely ever made by someone trying to be taken seriously).

Already a “high” priority SQL injection has been fixed since 3.7.0 was released, which was considered serious enough for Joomla to pre-announce that a security update was coming.

The same company offers to clean up hacked Joomla websites, so they should know better than to make that sort of claim and in fact they seem to understand that vulnerabilities continue to be found in Joomla based part of how they advertise that service:

We will identify possible loop hole in security and install required updates and patches. Because of consent Joomla and component upgrades, this is a critical step to prevent hacking.

In describing their service there was also this troubling claim:

As soon as we are engaged to fix your hacking issues or to prevent your website from hacking, we will do a thorough analysis and prepare an action plan to recover your website at the earliest. Mostly a Joomla upgrade should fix it, but it depends on the kind of website and problem you have.

We deal with lots of hacked Joomla websites and upgrading would not normally fix them. Perpetuating that idea is decidedly not helpful, as if our experience is any indication people with hacked website will often come to that conclusion and then hire someone to upgrade it without mentioning that they are doing that to clean up hack. Trying to upgrade a hacked website could actually make the situation worse, as it might cause the upgrade to go wrong and it could erase important evidence needed to determine how the website hacked, which may be needed to prevent it from being hacked again.

SiteLock Uses Harmless Activity on Website as a Reason to Try to Sell Unneeded Malware Removal to One of Their Customers

When you have a malware infected or otherwise hacked website it can make a lot of sense to hire someone with expertise in handling the cleanup of them to do that for you. Beyond that they would have the knowledge to quickly resolve the issue for you, where we have seen the value of doing that for our clients is that they often can use help understanding what is going on. Often times they are concerned about things that they don’t need to be and we can easily clear things up for them.

Unfortunately, far too often they are concerned about things due to misleading or outright false information being put out by other security companies. That then leads in to the big problem when it comes trying to hire an individual or a company for any type of security service, many of them really don’t know and or care much about security. On top of that there doesn’t appear to be good way to find one that isn’t true about, since these companies don’t seem to have a problem with lying and reviews of them come from customers who often are unlikely to have a good sense of the quality of the service they have gotten since they don’t have the expertise needed to determine that (we have had people saying another company did a good job even after they have hired us to re-do work that wasn’t done right by that company).

We recently had someone that came to us that believed there website had a re-occurrence of a malware issue and were looking for an alternative to the company they were already paying to secure their website, SiteLock, to do deal with it. That was in part because SiteLock had not detected any issue they had noticed.

The first thing we always do when someone comes us to about dealing with a malware infected or otherwise hacked website is to determine that it is in fact hacked. In this situation the belief that the website was infected with malware was based on some things the website’s owner had seen in the log file of HTTP activity. In reviewing those we found that those things were harmless. There were several request for spammy URLs, but the status code of the responses was 404, which indicates that a page with that URL did not exist. The other concerns related to request coming from a Russian search engine and requests coming from the file that does cron jobs for WordPress. Other checks should no current issue with the website.

SiteLock had given them a very different response when they had brought up what the customer had seen the log. SiteLock didn’t address the specifics that were raised and seemed to just assume that the website infected. They implied that the infection coincided with the SiteLock’s web application firewall (WAF) service that was in use being downgraded from “Enterprise level” to the “Premium level” (contrary to SiteLock’s marketing that service is actually provide by another company). To resolve the issue they suggested upgrading the WAF back to “Enterprise level” and having their “Expert Services” clean it up.

If all that were true it would seem to be reasonable to ask why they offer the “Premium level” WAF that permitted the website to get infected. You might also ask why you should pay more to clean up a website when the service you already paying to protect didn’t actual accomplish that.

While it is possible that SiteLock assumption that the website was infected and recommending that more money being spent with them was based on them not understanding that you should determine that a website was hacked before trying to clean it up, everything we have seen points to something else. That being that from everything we have heard and seen when you get in touch with SiteLock you are usually going to interact with commissioned sales person. It wouldn’t be surprising that a person that is not a tech and are getting paid if they can sell you something, would instead of determining that there wasn’t any issue, try to sell this person on an additional service and to a more expensive version of an existing service. It also would be in line with what have heard in numerous other instances when SiteLock failed to provide protection, that the answer was to move to a more expensive service.

SiteLock Still Spreading False Information About the Security of WordPress to Their Customers

Back in September we wrote about how the web security company SiteLock had introduced a new feature that was supposed to warn about vulnerabilities on WordPress websites, but would falsely claim that websites running older WordPress versions had vulnerabilities in them that they didn’t.

This seemed to be caused in part by a fundamental lack of understanding of how WordPress handles security, which involves security fixes being released for older version of WordPress that have the automatic background updates feature (WordPress 3.7 and above). This is something that anyone dealing with hacked WordPress websites should know since part of properly cleaning them involves determining, to the extent possible, how they were hacked and you would need to know what vulnerabilities would exist in a version of WordPress when cleaning it. From everything we have seen SiteLock doesn’t properly clean up hacked websites (and they even use that fact as a reason to upsell their customers), so maybe it shouldn’t be surprising they wouldn’t know this.

It also seems to be caused in part by them not understanding the underlying data source for the vulnerability information, the WPScan Vulnerability Database, as that correctly labels which versions of WordPress are vulnerable to the vulnerabilities (as we will show in a bit).

We know that SiteLock is aware of all of this as they clearly read our post as they filed a DMCA takedown notice to remove an image we had included in the post.

You would think that after becoming aware of this SiteLock would have fixed this, right? Well it turns out 9 months later they are still falsely claiming that WordPress website contain vulnerabilities they don’t.

The other day someone contacted us after they had been told by their web host iPage that they their website had security issues and they should sign up for SiteLock. After doing that they contacted us after seeing our previous post about this issue and thinking that what SiteLock had told them about vulnerabilities on their website wasn’t true.

The website was running WordPress 4.6.6 at the time and SiteLock claimed it had the following medium and high severity vulnerabilities:

Severity: High
Category: csrf
Summary: WordPress 4.2-4.7.2 – Press This CSRF DoS
Description: CSRF DoS vulnerability in WordPress versions 4.2 to 4.7.2 through the Press This functionality.
Severity: Medium
Category: rce
Summary: WordPress 4.3-4.7 – Potential Remote Command Execution (RCE) in PHPMailer
Description: Potential Remote Command Execution (RCE) in PHPMailer used in WordPress versions 4.3 to 4.7.1 can potentially be used to remotely execute commands.
Severity: High
Category: bypass
Summary: WordPress 4.2.0-4.7.1 – Press This UI Available to Unauthorised Users
Description: Authentication bypass vulnerability in WordPress Press This versions 4.2.0 to 4.7.1 allows unauthorized users to access the UI.
Severity: High
Category: csrf
Summary: WordPress 2.8-4.7 – Accessibility Mode Cross-Site Request Forgery (CSRF)
Description: Cross-Site Request Forgery (CSRF) in WordPress versions 2.8 to 4.7 via Accessibility Mode allows unauthorized actions to be performed.
Severity: Medium
Category: bypass
Summary: WordPress 2.8.1-4.7.2 – Control Characters in Redirect URL Validation
Description: Control Characters vulnerability in WordPress versions 2.8.1 to 4.7.2 through the Redirect URL Validation
Severity: Medium
Category: unknown
Summary: WordPress 3.0-4.7 – Cryptographically Weak Pseudo-Random Number Generator (PRNG)
Description: Cryptographically Weak Pseudo-Random Number Generator (PRNG) vulnerability in WordPress versions 3.0 to 4.7 in the multisite activation key creates the potential to guess/brute-force the activation key.
Severity: High
Category: xss
Summary: WordPress 3.4-4.7 – Stored Cross-Site Scripting (XSS) via Theme Name fallback
Description: Stored Cross-Site Scripting (XSS) WordPress versions 3.4 to 4.7 via Theme Name fallback allows malicious code to be stored on the site.
Severity: High
Category: xss
Summary: WordPress 4.3.0-4.7.1 – Cross-Site Scripting (XSS) in posts list table
Description: Cross-Site Scripting (XSS) vulnerability in WordPress versions 4.3 to 4.7.1 through the posts list table.
Severity: Medium
Category: xss
Summary: WordPress 2.9-4.7 – Authenticated Cross-Site scripting (XSS) in update-core.php
Description: Authenticated Cross-Site scripting (XSS) WordPress versions 2.9 to 4.7 via update-core.php allows malicious code to be injected to the page.
Severity: High
Category: xss
Summary: WordPress 4.0-4.7.2 – Authenticated Cross-Site Scripting (XSS) in YouTube URL Embeds
Description: Authenticated Cross-Site Scripting (XSS) vulnerability in WordPress versions 4.0 to 4.7.2 allows an attacker to inject malicious code on to the site through YouTube URL Embeds.
Severity: High
Category: xss
Summary: WordPress 3.6.0-4.7.2 – Authenticated Cross-Site Scripting (XSS) via Media File Metadata
Description: Authenticated Cross-Site Scripting (XSS) vulnerability in WordPress versions 3.6.0 to 4.7.2 allows malicious code to be injected on to the site via Media File Metadata
Severity: High
Category: sqli
Summary: WordPress 3.5-4.7.1 – WP_Query SQL Injection
Description: In WordPress 3.5 to 4.7.1 WP_Query is vulnerable to a SQL injection (SQLi) when passing unsafe data.
Severity: Medium
Category: unknown
Summary: WordPress <= 4.7 – Post via Email Checks mail.example.com by Default
Description: Post via Email Checks mail.example.com by Default in WordPress version 4.7 and earlier.

Those vulnerabilities don’t exist in WordPress 4.6.6, which can be seen by looking at the relevant entries in the WPScan Vulnerability Database. Let’s take a look at a couple of examples:

For the vulnerability “WordPress 3.0-4.7 – Cryptographically Weak Pseudo-Random Number Generator (PRNG)” the vulnerability was fixed in version 4.6.2:

For the vulnerability “WordPress 3.6.0-4.7.2 – Authenticated Cross-Site Scripting (XSS) via Media File Metadata” you can see that it was fixed in version 4.6.4:

It also worth noting here that the severity ratings that SiteLock provides here look to be vastly overstated since none of these vulnerabilities is likely (or has in fact been) exploited on wide scale, which you would expect at least for vulnerabilities rated as being high severity.

iPage isn’t innocent in this, as not only do they get a significant percentage of the price being paid for SiteLock services sold through their partnership, but their parent company also happens to be run by SiteLock’s owners.

You would also think that WordPress might make a point of warning people away from SiteLock since they are profiting off falsely claiming that WordPress websites contain vulnerabilities, but instead they have welcomed them as sponsor and speaker at various WordCamps, WordPress conferences. In fact they thanked them for their “commitment to the WordPress community”:

We’d like to thank each of our 2017 global community sponsors for their commitment to the WordPress community. Their generous contributions support community events like WordCamps and WordPress user groups worldwide.

The Problems Caused By SiteLock Using Nessus as Their Vulnerability Scanner

The other day we mentioned how we often have people that contact us about situations where the web security company SiteLock has contacted them claiming that their website has malware, but SiteLock has not provided any evidence of that. Recently we have started being contacted about situations where SiteLock is contacting a website’s owner claiming that the website has some vulnerability that could lead to the website being hacked. So far in those instances SiteLock has not provided any evidence to back up their claims, so we can’t access their validity directly. But we have continued to see problems with their vulnerability scanner, which seems like it would likely also be what would be the source of their claims.

What looks to be an overarching issue with their vulnerability scanner is that the underlying technology isn’t really designed to be in the fashion it is. Back in December we stumble on to the fact that at least part of their vulnerability scanner is really just them using a piece of software named Nessus, which as best we can tell that is something that isn’t really designed to be used by end users. Instead it looks like it is designed to be used by security professionals and software developers. For them producing false positives would be less of an issue since they could fairly easily evaluate if there is an issue, whereas end users are not usually going to have that capability. It is even more of a problem if someone is using those unreliable results to try to sell people on security service, as SiteLock might be doing.

An example of the issue can be seen in a recent thread on the WordPress Support Forum, where someone got notified of a claimed security problem in the login page of a WordPress blog:

This was sent to me by SiteLock about a security problem on my wordpress blog. The CGI issue is attached to the login page. Can this be fixed please?

Synopsis: A CGI application hosted on the remote web server is potentially prone to SQL injection attack.

Description: By sending specially crafted parameters to one or more CGI scripts hosted on the remote web server, SiteLock was able to get a very different response, which suggests that it may have been able to modify the behavior of the application and directly access the underlying database.

An attacker may be able to exploit this issue to bypass authentication, read confidential data, modify the remote database, or even take control of the remote operating system.

Note that this script is experimental and may be prone to false positives.

Solution: Modify the affected CGI scripts so that they properly escape arguments.

Right off the bat this information doesn’t seem end user friendly as it looks as though the reference to CGI script in that is really a reference to any sort of code running on a website (as can be seen by this list of CGI abuses on the website for Nessus).

That confusion lead to a moderator falsely claiming that it would appear the website is compromised:

WordPress does not use CGI for anything, so if you’re getting that on WordPress’s login page, it would appear that your site has been compromised as their tool has identified.

Carefully follow this guide. When you’re done, you may want to implement some (if not all) of the recommended security measures.

Beyond that two things stick out.

The first being the statement noting that “this script is experimental and may be prone to false positives.” Why is something experimental and known to produce false positives being used to produce the results of SiteLock’s vulnerability scans?

The second one being the part that states “By sending specially crafted parameters to one or more CGI scripts hosted on the remote web server, SiteLock was able to get a very different response, which suggests that it may have been able to modify the behavior of the application and directly access the underlying database.”. Changing the values that are sent with a request could produce a very different response for obvious non-security reasons. Say if you changed the value of parameter specify what to be search for on a search page, you would expect to get different results. If you sent an invalid value with a request you might also get a very different result than if you sent a valid one.

Based on everything we have seen from the results of SiteLock’s vulnerability scanner so far, the results don’t look reliable. So we would recommend avoiding it if you are looking to determine the security of your website. If you do have them claiming that there is a vulnerability and you want to be on the safe side, we would recommend you get a second opinion from someone familiar with handling security issue with the software you are using.

Hacker Provides More Information on Fixing Defacement Hack Than SiteLock and HostGator

When it comes to claims that a website contains malware or is otherwise hacked coming from the web security company SiteLock or their web hosting partners our recommendations is to not ignore their claims despite the serious problems with false claims. Instead we recommend getting a second opinion from another company that deals with hacked websites. We are happy to do that for free and a lot of people have been taking us up on that offer.

The first thing we do when contacted about a second opinion is to find out what evidence SiteLock and or the web hosts has provided as to the claimed issue. In doing that we have seen that in most cases the supporting evidence of the claim falls in to one of two very different categories. In the first they have provided a listing of examples of impacted files and in the other they provided no details whatsoever. So far we haven’t seen a strong correlation between either of those and veracity of the claim.

In one recent instance where a website was really hacked they provided no information whatsoever, while the hacker actually provided helpful information.

In response to our question about what evidence the owner of the website mentioned they had received none despite multiple calls a day, but they had noticed a couple of pages in the Google search results with hacked content.

From that we already had a good idea as to what was going on.

When we looked at those pages we found that they had the following message:

Hacked By Not Matter who am i ~ i am white Hat Hacker please update your wordpress

The only vulnerability that has existed in the core WordPress software that has been exploited in a wide scale in years (maybe close to a decade) was vulnerability that allowed modify the content of posts, which existed in WordPress 4.7.0 and 4.7.1. As long as WordPress’ automatic background updates were working properly this vulnerability was not a threat, as it was fixed with a new version well before the vulnerability started being exploited. That issue could have explained how a hacker was able to add that message to the pages they did.

Based on all those things it wasn’t surprising to find that the website was running WordPress 4.7.1.

At that point we recommend that the website’s owner update WordPress, undo any changes made to the post content, and see about making sure that automatic updates are able to function going forward.

If SiteLock or HostGator had told them that in the first place the issue could have easily been resolved, but it likely wouldn’t have lead to a SiteLock sale, which is possible explanation why they wouldn’t do that. You might be wondering why a web host wouldn’t want their customer to be secured, the answer is in part that HostGator and other Endurance International Group brands received a lot of money when SiteLock sales are made through their partnership. Another part of the answer is that SiteLock’s owners also run the web hosting company.

It isn’t just that they didn’t provide any details; they told them something that is not accurate with this type of issue:

“During a recent SiteLock security scan of your website, malware was detected that could jeopardize the safety of your website and your customers’ data.”

The website doesn’t look to have contained any malware. The reason for the claim that malware was detected appears, based on our previous experiences, to be due to SiteLock’s malware scanner not just be used to detect malware, but any evidence of a hack, but any issue detected incorrectly being labeled as a malware issue.

iPage Provides Conflicting and Bad Advice on Cleaning Hacked Websites

When it comes to dealing with a hacked website, the advice you are going to get from a web host isn’t necessarily very good. For example, we have often seen them tell people their websites must have been hacked due to outdated software, without the web host having done anything to determine if that was true (and in some cases despite the website not even using outdated software). In one recent instance we found that one of the brands of the web hosting company Endurance International Group, JustHost, was pointing toward an outdated version of Joomla as the source of hack, while they were offering to install that version on websites despite support for it ending over two years before. Since the installation occurred through another Endurance brand, MOJO Marketplace, it looks like that version probably being offered for install across their other brands as well.

With that that type of thing happening at Endurance, it might not be surprising to see what we recently came across while doing a consultation with someone with a hacked website using one of their other brands, iPage, in which they provided conflicting and bad advice on dealing with a hacked website.

Here was is most of the original email they sent to their customer about a hacked website:

During a routine scan, we detected suspicious contents that suggest your ‘[redacted]’ account has been compromised. We have temporarily suspended your website to protect your website visitors from getting impacted and also preventing the impact on your website reputation as well as our server’s reputation.

We have uploaded a file ‘websitescan.txt’ within the stats directory of your account which contains the full list of infected files. We need you to take one of two actions suggested below:

Please follow the steps given below to remove the infected contents on your own:
1. Open the ‘websitescan.txt’ file through your FileManager (OR use ‘FTP’ software like FileZilla).
2. Clean or remove each of the listed files.
3. You can also upload a clean copy of web files from your local backup.

Alternatively, we encourage you to contact our preferred partner, SiteLock. In addition to long-term solutions like their Fix and Prevent products, which offer daily scans and removal of malware, SiteLock also provides an emergency service, SiteLock 911. You can call our dedicated SiteLock support representatives using the Toll Free number (United States and Canada customers only): (855) 378 6200. International: +1 415 390-2500. To learn more about SiteLock, please go to: https://www.ipage.com/product/sitelock

So in that email they recommend simply cleaning/removing or replacing the files they identified.

When they refer to SiteLock as their preferred partner what they really mean they are getting paid a lot of money to push their services (SiteLock’s owners also happen to run Endurance International Group).

In a follow up email they had these recommendations:

Please remove the malicious contents or replace the infected files with a clean copy of web files from your local backup.

Our best recommendation is to completely remove all the files from the account and restore the contents from a known clean backup. An alternative would be going through a company such as SiteLock to clean and secure all scripts. If this isn’t done and the malicious files that are found through scanning are simply removed, the vulnerability will still exist and you will encounter the files again and again.

Those two paragraphs seem to conflict with each other as the second one states that if “the malicious files that are found through scanning are simply removed, the vulnerability will still exist and you will encounter the files again and again”, but the first paragraph and the first email suggest doing just that.

The larger problem with this is that whether you were to “completely remove all the files from the account and restore the contents from a known clean backup” or remove the indicated files that isn’t going to resolve the vulnerability. The malicious code in files on the website had to get there somehow, so there must be something that allowed that and you would need to fix that. To be sure you had fixed it, instead of just guessing that you had, you would need to figure out how the website was hacked in the first place. Nowhere in the emails do they suggest doing those things and those are things their “preferred partner” SiteLock usually doesn’t do based on everything we have seen with them.

SiteLock Wants You to Believe That Leaving Malicious Code on Your Website for a While Is Not a Threat

When it comes to the much maligned web security company SiteLock we hear many complaints, but the two we hear the most about are them falsely labeling websites as being infected with malware (as we discussed in another post earlier this week) and that they provide protection services that don’t end up actually doing much, if anything, to protect websites.

One example of them not really protecting websites is when their idea of protection is try to detect that malicious code has been added to the website after that it has been hacked. While we would hope would be obvious is that if malicious code is getting on the website it isn’t being protected in the first place, but it would appear that isn’t the case considering they are not the only ones that market services along those lines as protecting websites.

That this would protect as website is something they actively promoting, as can be seen in these lines from a recent post on their blog:

Wyatt plays a key role in manually reviewing code that our SMART scan flags as suspicious. If the code is found to be malicious, he’ll write new scripts for our scanners that are designed to automatically detect and remove malicious website code before any damage is done.

There are several issues with that.

First, is what we were mentioning before, malicious code is getting on the websites in the first place.

Second, if there scanner is able to flag it as suspicious (which isn’t a given) it is still going to remain there unless code is written to be able to remove it, which delays removal for new code (which based on the variety of code we see is likely occurring frequently).

The most galling part of it though is this, that it will “remove malicious website code before any damage is done”. Unless the code is removed immediately after it is added then the chances of it being removed before any damage is done are very small. Usually the code would start impacting visitors immediately or the hacker would utilize it to take further actions right after they added it. From what we can tell it looks like they usually scan the files once a day, so the chances of it being removed immediately are also very small. One day is long time for a website to serving malicious code or a hacker to take further actions.

Where this becomes even more problematic is if the code is used to copy sensitive data off of the website, as once that has happened, removing the malicious code won’t undo that having happened.

What makes this all so unfortunate is that just doing the basics would keep many websites from being hacked and those are things that SiteLock can’t or doesn’t provide in their services. Furthermore, just looking at SiteLock’s case studies show their customers are not doing one of those things. We would guess that is in part due to their customers being misled by SiteLock that they providing protection for their website that they are not.

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.