Is SiteLock Not Even Saying What Website They Are Claiming is Vulnerable?

A few days ago we discussed a Forbes article about a report from the web security company SiteLock that claims be a score of how likely a website is to be compromised that seems to be based on nothing, as despite claiming a website had a “Medium” likelihood of compromised SiteLock couldn’t point to any way that the website would be compromised other than ones that are not considered in their score. In that post we noted that previously we have had people come to us after SiteLock had contacted and claimed that there was vulnerability on their website, but wouldn’t give them any details of it. It looks like they can provide even less information, as the following portion of an email sent to someone that was formerly a customer of one of their web hosting partners shows:

It is baffling that telling the owner of a website which one of their websites is claimed to have a vulnerability, without providing any details whatsoever of the vulnerability, is going to somehow expose the vulnerability.

What is a bit odd about this message is that Bluehost’s name is incorrectly capitalized as “BlueHost” with the “h” capitalized when it shouldn’t. It seems like you should get your partners name right, especially when that partner is ultimately run by SiteLock’s owners. Without seeing the rest of the email we can’t see if there is any indication that this actually another phishing email being sent to Bluehost customers, like the one we that came up last week when Bluehost was pushing someone to hire SiteLock to deal with a non-existent malware issue. Though that phishing email actually mentioned a specific website.

One alternate explanation that isn’t too far out there considering SiteLock’s track record and the fact this person isn’t even with the web host anymore is that there is no basis for the claim. By not mentioning a website they might hope to get more interest from webmasters than if they mentioned one and it wasn’t important.

SiteLock Likelihood of Compromise Reports Look Like Another SiteLock Scam

We have written a lot about the shady stuff involving the web security company SiteLock and the main complaint we have gotten about this is that because we also offer web security services (though very different from what they offer) that the information we provide is suspect. We can’t point to much written by others in a professional capacity because for the most part SiteLock has remained under the radar. But we now have something written by someone else that we can point to that shows the kind of activity that has caused “sitelock scams” to be one of the search predictions that Google provides when searching for SiteLock:

An article put out by Forbes last week describes something we have yet to have anyone contact us about, a report from SiteLock that is supposed to be “high-level security analysis by leveraging over 500 variables to score a website’s risk on a scale of low, medium and high”. The author of story was told that their website, which is “single-page static website with just a handful of files and no CMS or other editing software”, had a “Medium” “likelihood of compromise”. The author of the article noted they could only think of two ways that type of website could be compromised, but SiteLock told them that neither of those was consider when calculating the score:

The SiteLock representatives clarified that they do not check for or consider either password security or server vulnerabilities in their assessment and that their risk score is based exclusively on the characteristics of the site itself.

Considering that SiteLock was saying that there was a “Medium” risk of compromise how else did they think it could be compromised, they couldn’t even come up with an answer:

When asked how a remote attacker might then modify the files on a CMS-less single-page self-contained static website without either guessing/phishing/resetting the account password or finding a vulnerability in the server stack, a representative initially said they would work with their engineering team to send me some examples of how such a site could be compromised, but later said they would not be commenting further and did not respond to two subsequent requests for additional comment.

In light of the fact that the score seems to be baseless in this instance, it is worth noting the only detail of the score provided was:

The only detail of any kind offered by the report as to how it assessed my site at Medium risk was that 7% of the risk came from “Popularity: Number of visitors and overall social media presence,” 29% of the risk from “Presence of specific components” and 64% from “Site size and the number of distinct components.”

So SiteLock is making it appear that all of this is evidence based, they are giving percentages and claiming to leverage over 500 variables (we can’t even think of close to 500 variables that could possibly be used unless they are really stretching as what they count as a separate variable), but the reality is that the score seems to be baseless. The author of the piece had the expertise to see past the superficial evidence based nature of this, but SiteLock wouldn’t be doing this if they didn’t think that others would not be as knowledgeable.

This isn’t the first time that we have seen SiteLock put forward claims that websites are vulnerable based on false evidence or unsupported by evidence. In June we noted how they continued to use false information about the security of WordPress to claim websites were vulnerable. In other instances we have had people come to us after SiteLock has claimed there is some vulnerability on their website, but has refused to provide the details, instead only suggesting purchasing SiteLock services to resolve. That was also the case for the author the article.

When the web hosting partner that was passing along the score was asked what could be done to reduce it, the response was to purchase SiteLock services:

When asked what a company could do to reduce their risk score, Network Solutions noted that it offers two subscription monitoring services by SiteLock that scan a customer’s site each day, alerts them if their site has been compromised and automatically removes selected malware from infected files.

The web host would likely get a significant percentage of the fee for those services if they were purchased.

SiteLock gave a similar response:

When asked how a company might work to reduce their risk score from Medium to Low in the absence of any technical detail as to which of the 500 indicators were triggered for their site and if their subscription vulnerability scans did not reveal a known vulnerability, SiteLock offered that it has a commercial professional services team that can be hired in a consulting arrangement to review a site and determine if there are any concerns with its architecture or technical design.

In line with what we have seen in the past when caught doing questionable stuff, SiteLock claimed that they didn’t see anything wrong with what they are doing:

The company strenuously emphasized that it believes such a score is very useful and that many companies have found it of great use to them, but declined to provide more detail as to what companies have done with that information beyond simply subscribing to SiteLock’s products.

The Forbes article raises other issues with this situation that are also problematic and we would suggest you read the article.

Based on all of that it looks like these scores can be safely ignored, but with other claims from SiteLock about the security of websites that are backed by some level of evidence we recommend getting a second opinion before taking any action, as they are not all false. We are always happy to provide a free second opinion.

iPage’s Strange False Claim of Malware Being Detected on a Website

We get a lot of people that contact us looking for a second opinion as to a claim that their website contains malware coming from the SiteLock and or their web hosting partners. One of the latest included a head scratching claim in an alert from the web host iPage (the logo shown with that is SiteLock’s, so maybe they did the scan):

Malware has been detected on your site during a recent scan. 0 domain may be affected.

So there was malware detected on their site during a recent scan, but it impacted “0 domain”. Those seem like they are contradictory statements to us, but maybe something that doesn’t count as a domain was impacted?

What we suggested to the website’s owner was to contact iPage for more evidence because that wasn’t enough based on that to give a second opinion as to the veracity of the claim, though it seemed unlikely considering the website was built with the Weebly website builder provide by iPage.

The response they got from iPage was that the there was not any malware, but they were not provided with an explanation as to what had happened:

We apologize for any inconvenience caused. I have performed a scan of your account and it is malware free. Right now there is no alert regarding infection is shown in the ControlPanel.

If you receive an alert similar to this from iPage whether it actually lists a positive number of domains affected or not, our recommendation is to contact iPage for more information and then get a second opinion instead of signing up for a SiteLock service, which they are trying to sell you from that alert, right off the bat.

False Claim From Bluehost Phishing Email Leads to Bluehost Trying to Sell Unneeded SiteLock Service

On a daily basis we are contacted by people looking for a second opinion after their web host and or their web host’s security partner SiteLock claim that their website contains malware. While a lot of the time there really is some hack of the website that has occurred, though not necessarily involving malware, there are many instances where the claim turns out to be false. There have been many different reasons for that, one of the latest seems like it might be the worst the one yet, since the web hosting partner, Bluehost, tried to sell someone on a $1,200 a year security service from SiteLock based on false information from a phishing email that didn’t even claim there was malware on the website.

What we were told at first about the situation didn’t make sense to us. The website’s owner said they were told by their web host Bluehost that their website was using excessive MySQL resources and that the cause was malware. MySQL is database system and malware and other hacks rarely involve interaction with a database, so we didn’t understand where the belief that malware would be the cause would have come from. Looking at the website made things seem odder. The one possibility we could think of is if a hack added spam content to a website it could cause increased traffic to the website that in turn could increases MySQL resource usage. Not only did we not see any indication of that type of issue, but there was also the fact that the website was built with the Weebly website builder software, which seems unlikely to be hacked in that way or using much in the way of database resources.

After asking if Bluehost provided any more information that might make their conclusion that malware was the cause seem more reasonable, we were forwarded the following email that had started the situation:

Bluehost abuse12@bluehost.com via annika.timeweb.ru

11:16 PM (12 hours ago)

Dear Bluehost customer [redacted]:

It has come to our attention that your site is using an excessive amount of MySQL resources on your BlueHost.Com account. This is causing performance problems on your website as well as for other customers that are on this server. It can cause our servers to crash and cause additional downtime.

Our research shows that server performance degrades when the MySQL usage is over 1,000 tables and/or 3 GB on a single account or 1,000 tables and/or 2 GB on a single database. In order to ensure optimal performance for your account and the others in your shared hosting environment, we request that you reduce the MySQL usage on your account to under these limits in 14 days.

You must confirm the current copy of our Terms of Service here:
http://my.bluehost.com.687fe34a901a03abed262a62e22f90db.d0013151.atservers.net/domain/[redacted]
How to fix:
http://mysql.bluehost.com.687fe34a901a03abed262a62e22f90db.d0013151.atservers.net/domain/[redacted]

Terms of Service Compliance Department
1958 South 950 East
Provo, UT 84606
Phone line: (888) 401-HOST Option 5 | Fax line: 801-765-1992

The very beginning of that caught our attention first, as it referenced “annika.timeweb.ru”, which seems like it shouldn’t be where an email from Bluehost should be coming from. A Google search on that showed that this email was part of an ongoing phishing campaign against Bluehost customers. Later on in the email the URLs being linked to are intend to look like it is Bluehost by starting “my.bluehost.com” and “mysql.bluehost.com”, but the rest of the domain is “687fe34a901a03abed262a62e22f90db.d0013151.atservers.net”. The server that is hosted from is in Belarus.

Since this was a phishing email there was not anything wrong with the website. So that makes Bluehost’s claim that it was malware and that the SiteLock service should be purchased when they were contacted even odder. The Bluehost support person must not have checked to insure that the issue the customer was contacted about actually existed, despite a phishing campaign going on making false claims along those lines. Even then it doesn’t make sense to say this was malware based on the claimed MySQL resource usage issue. So what explains it?

Well it might have something to do with the fact that Bluehost gets 55% of the revenue from sales of SiteLock services through their partnership or that SiteLock’s owner also run the parent company of Bluehost, the Endurance International Group. Based on what have heard in the past it sounds like when support persons don’t know what is going on they may blame malware for what is going on and point people to SiteLock.

In any case, it is a good reminder to make sure to get a second opinion when you are contacted by SiteLock or their web hosting partners so that you don’t end up spending over a thousand dollars a year on something you don’t need. If you were really hacked you also don’t need to spend anywhere near that amount of money to get the website properly cleaned up (SiteLock doesn’t even properly clean up websites for their high fees).

Wordfence Pushes Their Less Effective Products and Services Over Doing a Security Basic

From dealing with a lot of hacked website we see the damage the security industry often causes. One of the problems we have run into over and over is that people are not interested in doing the basics of security and instead trying to rely on security products and services to protect them. Doing that has leads to website being hacked that shouldn’t, that even includes the website of a security company. It isn’t hard to understand why this happens since these security products and services are often promoted as being a magical bullet, while in reality some are somewhat useful and others are of little use to no use.

In some cases security companies are explicitly promoting using their products instead of doing the basics even when they would have provided better results. Case in point a post by the WordPress focused security company Wordfence today.

They claim that websites are being infected with a particular malware through two vectors:

So far the Wordfence Security Services Team has seen two infection vectors (methods of infection). The first is websites that are infected because they left the searchreplacedb2.php script lying around. This is a relatively uncommon infection vector. We wrote about this risk a few weeks ago.

The second vector is by far the most common. The attackers are exploiting a vulnerability in the WordPress ‘Newspaper’ theme. This vulnerability allows them to inject malicious code into the WordPress ‘wp_options’ table which then redirects your traffic to malicious websites or ad campaigns. Our Security Services Team has seen several other themes that are based on the Newspaper WordPress theme that suffer from the same vulnerability.

What isn’t noted in their post is that according to discoverer of the vulnerability in the theme, the vulnerability was fixed four days after the developer was notified and the fix was put on in April of last year. Why not note that, well one reason might be the next paragraph in their post:

Wordfence released a Premium firewall rule about 40 days ago which prevents these attackers from exploiting the Newspaper theme. Even if you had a vulnerable theme, you would have been protected. About 10 days ago, that rule became available to our free customers too.

So simply keeping the theme up to date would have protected those using it long before Wordfence ever got around to protecting against the vulnerability. Wordfence didn’t mention the importance of keeping software updated in those parts of the post, but surely they would do that in a section “What to Do To Protect Yourself” since updating the theme would in fact be the best protection against the vulnerability in the older version from being exploited. It turns otu that isn’t the case:

What to Do To Protect Yourself

As always we recommend running Wordfence Premium. In this case, our Premium customers have been protected for over 40 days from TrafficTrade by a Premium firewall rule that was deployed by our team in real-time.

The firewall rule became available to our free community users about 10 days ago. Both Wordfence free and Premium are now protecting your sites from these attacks.

Because this infection is so wide-spread, we have released additional detection in the Wordfence malware scan to detect a newer variant of TrafficTrade. We are seeing attackers modify your wp_options table to inject the malicious code into that table. A Wordfence scan will now detect this.

This new feature is immediately available for free and Premium Wordfence customerswith Wordfence version 6.3.16 which was released this morning. Simply install Wordfence or update to 6.3.16 and run a scan.

We mentioned earlier that security companies promote their products as being magic bullets, Wordfence is a perfect example. They promote their plugin with the blanket claim that its “Web Application Firewall stops you from getting hacked” despite the obvious counter example here that they only started protecting against the theme vulnerability more than a year after it was disclosed.

Your Web Host Doesn’t Require That SiteLock Clean Up Your Hacked Website

These days we have a lot of people contacting us looking for advice after the web security company SiteLock or one of their web hosting partners has contacted them about a claimed hack of their website. One of the things that has been coming up fairly often that we don’t quite understand are claims like the following:

I’ve recently had my site (a personal, wordpress blog hosted by Blue Host) deactivated and blocked and they are essentially holding it ransom and saying that I must pay an exorbitant fee to have sitelock ‘fix’ it and then pay a monthly fee on top to keep it safe.

As far as we are aware web hosts don’t require that SiteLock do the cleanup, only that the website needs to be cleaned up before being allowed back online.

Before getting further in to that it is worth noting that the web host in that instance, Bluehost, is one of many web hosting brands owned the Endurance International Group (EIG).  Their other brands include A Small Orange, FatCow, HostGator, iPage, IPOWER, JustHost, and quite a few others. They seem to be SiteLock’s largest partner at this time, which might have something to do with the fact that the majority owners of SiteLock also run EIG.

The first thing we do in a situation where someone contacts us about a claim from SiteLock and or the web hosting partners that a website hacked is to ask about any evidence provided to back up the claim. In this case the person we were dealing with forwarded us an email from Bluehost. The email contained an example of the issue on their website and boilerplate text we have seen in numerous emails from Bluehost about hacked websites. Here is what the boilerplate text says about what needs to be done need to have the account reactivated:

You will need to review your files and clean the account accordingly by removing all malicious files, not just the reported url. Once you have confirmed your files are clean and no longer a threat, please contact us again to have your account reactivated.

It’s possible that in phone conversations Bluehost is telling people something else, but from our experience dealing with lots of website hosted with Bluehost and other SiteLock web hosting partners there is no requirement to use SiteLock. And we have never had anyone have a problem getting the the web host to reactivate the website after we have cleaned it.

The only mention of SiteLock in that email is this:

You may want to consider a security service, such as SiteLock, to scan your website files and alert you if malicious content is found. Some packages will also monitor your account for file changes and actively remove malware if detected. Click here to see the packages we offer: https://my.bluehost.com/cgi/sitelock

The other important thing to note is that while they refer to the account being deactivated, that doesn’t mean you can’t access your website if you want to move it. Usually they only restrict viewing the website, so cPanel and FTP access are still available. So you can copy the website’s files, database, and any other items handled by cPanel while the website is deactivated.

As for the claim about SiteLock’s fees being exorbitant that is true. For the quality level of the service SiteLock provides, which involves them failing to do basic parts of the cleanup, you can spend much less with other providers or for many website we actual charge less while doing a proper cleanup. Part of the reason for this is that a lot of the money you pay to SiteLock doesn’t go to the cost of the work, for example at EIG web hosts, like Bluehost, that company gets over half of the fee despite not doing any of the work.

SiteLock Causes Easily Fixable Hacked Websites to be Abandoned Unnecessarily

In our interacting with lots of people looking for advice after being contacted by the web security company SiteLock, one of the problems we have now seen happen repeatedly is that in SiteLock’s quest to squeeze as much money out of people as possible, they are causing people to abandon hacked websites that could quickly and easily be fixed. This causes time and or money to be unnecessarily spent on a creating a new website, and for businesses that are generating business through their websites, unnecessary financial losses.

The business practice that leads up to this is summed up with part of a recent comment from someone that did abandon their website, as to what SiteLock told them about getting the existing website cleaned up:

if I gave them a hundred bucks a month there will clean it up and make sure it stays clean or a one time fee of 300 dollars but, not responsible if within 2 days it’s hacked again

The reality here is that if a proper one-time cleanup is done the website won’t be hacked again in 2 days. Of course, if SiteLock can get someone to believe otherwise they have a better chance of them purchasing an ongoing plan that would get them $1200 a year versus them only getting $300 from the person. The flipside of this is that it also causes people to abandon websites believing they are going to have to pay all that money to keep the existing website secure and that it makes more sense to just start over (which might not actually resolve the issue).

The other important thing to note about this is that while a website cleaned with proper one-time hack cleanup won’t get hacked again in 2 days, SiteLock doesn’t do proper cleanups for that $300. They skip two key components, which are getting the website secure as possible (mainly by getting the software up to date) and trying to determine how the website was hacked and resolving that. Their $100 a month plans don’t provide those things either as far as we are aware. By comparison for most cleanups we do we charge less than $300 for the cleanup (and we only do proper cleanups) and with other providers you can get a low quality cleanup like SiteLock provides for much less than $300.

As we noted before, SiteLock is actually aware that websites can get hacked again if those two parts of a proper cleanup are not done, but that hasn’t lead them to doing them.

What makes this even worse is that many web hosts and other entities like WordPress help to promote SiteLock, which leads to more websites being abandoned unnecessarily (as well as causing many other problems people face if they get involved with SiteLock).

The Reality Behind Praise for a Hack Cleanup Done by SiteLock

In dealing with hacked websites, we are often brought in to redo hack cleanups after another company has done a cleanup and the website gets hacked again. That isn’t necessarily the fault of the company doing the cleanup, but what we have found is that with those websites the company doing the previously cleanup almost always has unintentionally or intentionally cut corners.

The first thing we ask when it is brought up that there was a previous cleanup is if it was determined how the website was hacked. The answer is almost universally that determining how the website was hacked never even came up. Not only is doing that one of the three basic components of a proper cleanup, but if that isn’t done then you have no way of knowing if the vulnerability that allowed the website to be hacked still exists or not and therefore if the website is still vulnerable.

Even after finding out the company that did the previous cleanup didn’t do things right and having to hire us to re-clean the website we have had people say that the previous company did a good job. It is based on things like that, which leads us to believe that positive comments about companies providing security services are often not all that reliable.

A recent example of that type of issue involves frequent topic of this blog, SiteLock. Here was recent tweet from one of their customers:

It sounds like they did a good job, right?

SiteLock then thanked them:

When we first went to look at the website to see if it looked like it been properly cleaned and secured after seeing these tweets, the website was down due to the web host having restricted access to it (a web host that is run by the owners of SiteLock). As of now this is what you get when visiting it:

You don’t have to be a security expert to see that the hack hasn’t been resolved. Beyond what you can see there, which is “hacked by” message and an otherwise empty website, the website is still running an outdated version of WordPress, 4.5.9.

Based on our experience dealing with people who have been customers of SiteLock this poor result isn’t some outlier from an otherwise high quality provider of hack cleanups.

Sample Data Included with Joomla Templates from Template Monster Lead to Website Being Hacked

When it comes to cleaning up hacked websites one of the three basic pieces of doing a proper cleanup is trying to determine how the website was hacked. Without doing that you leave open the possibility that the vulnerability still exists and can be exploited again. Not surprisingly then when people come to us re-clean a hacked website after another company has done that and the website got hacked again there has almost never was an attempt to determine how the website was hacked during the previous cleanup.

Another reason for trying to determine how the website was hacked is so that you can possibly prevent other websites from being hacked through the same vulnerability. We say possibly, because as a hack we recently traced back to a template from Template Monster, trying to work with the party responsible for the vulnerability may not get you anywhere.

Before we get to the vulnerability let’s do a quick walk through how we came to find out it had been exploited.

We were recently brought in to clean up hacked Joomla website where the person already dealing with it was removing malicious code from .htaccess files and the index.php files of the installed template, but it kept returning. In situation like that our first step is to review any available log files to see what they show about how the hacker is making the changes. In this case we found suspect requests being sent to a file in the /modules/ directory.

That file was highly obfuscated and due to that, it was fairly obvious that it was malicious without needing to deobfuscate it. What was more important at the moment was figuring out how it got on the website. In looking over the other files in the directory it was pretty clear that the whole directory it was in was not legitimate and had been created by installing an intentionally malicious extension. One of the items that pointed to that was the manifest file for the extension:

<?xml version="1.0" encoding="utf-8"?><install version="1.5" type="module"><?xml version="1.0" encoding="utf-8"?><install version="1.5" type="module">
 <name>System</name>
 <author>Joomla</author>
 <creationDate>08 Jan 2010</creationDate>
 <copyright>Copyright (C)  Profexor Liberty</copyright>
 <license>http://www.gnu.org/copyleft/gpl.html GNU/GPL</license>
 <authorEmail>profexor@hell.com</authorEmail>
 <authorUrl>http://profexor.hell/</authorUrl>
 <version>1.0.0</version>
 <description>ͮ崫��殨��鲯ﲲ橼/description>
 <files>
 <filename module="mod-favicon-image">mod-favicon-image.php</filename>
        <filename module="mod-favicon-image">mod-favicon-image.xml</filename>
 </files>
    <params description="this module has no parameteres" >
    </params>
</install>

The installation of a malicious extension would most likely be done through a hacker’s access to a Joomla admin account. So we then reviewed the database table that stores user accounts and found there were numerous accounts that didn’t look legitimate. Only one of those was recorded as having been used to log in to the website recently.

For that account the email address was “demo@demoolink.org”. We then did a Google search on that address and found a thread on the Joomla Forum where someone had a template that was trying to create exactly the same user using a SQL statement. By exactly the same, the registration time specified for both was exactly the same, down to the second.

What didn’t make much sense to us is why a template would be trying to create a user. Considering that the template in use on the website we were cleaning was a commercial template from Template Monster, we first thought the explanation might be that it had been obtained from a warez website and the template was modified to allow website installing it to be exploited.

When we reviewed the installer file for the template though we found that there was no code to create the user. At that point we thought we had hit a dead end, but after doing some more investigating we found more evidence to connect the account to the template. After that we got access to another file that had come from Template Monster. This file was named fullpackage.zip and in addition to the template, it included a copy of Joomla and a sample data file created by Template Monster. When installing Joomla you have the option to install various sample data files, so when using this file to set up Joomla you could install the sample data provided by Template Monster

In that sample data file was the following SQL statement that created the user:

INSERT INTO `#__users` (`id`, `name`, `username`, `email`, `password`, `block`, `sendEmail`, `registerDate`, `lastvisitDate`, `activation`, `params`, `lastResetTime`, `resetCount`) VALUES
(846, 'Demo User', 'demo', 'demo@demoolink.org', 'ad358a48fb2891854aa8b547c7b151be:jGftU2FbdRXUNikAQrKKeAQl9Is104QE', 0, 0, '2012-10-17 10:56:12', '0000-00-00 00:00:00', '', '{"admin_style":"","admin_language":"","language":"","editor":"none","helpsite":"","timezone":""}', '0000-00-00 00:00:00', 0);

INSERT INTO `#__user_usergroup_map` (`user_id`, `group_id`) VALUES
(846, 8);

Any website that installed that sample data would have a Super User (the highest level user in Joomla) with the same username/password combo. Unless one of those was changed then someone that could figure out the password could log in to the websites where this sample data has been installed. At that point it looked to us that the user might have been installed across multiple Template Monster templates.

At that point we also contacted Template Monster informed them of the issue and suggested that they notify anyone that had purchased the impacted templates about the potential issue. We also suggested that they register the domain name demoolink.org seeing as that isn’t registered and someone could register and use it to gain access to the impacted website without even knowing the password (by resetting the password).

The first response we received was as follows:

Thank you for reaching the Technical Department of Template-Help.com!

Take our apologies for the delayed reply.

We are sorry for inconvenience caused by this. Usually clients change demo email address. We are happy that you managed to resolve it yourself.

Let us know if you are having any other issues with the template.

We responded trying to explain the issue wasn’t just related to the email address and we received the following response:

Take our apologies for the delayed reply.

demo@demoolink.org is added in admin panel as example of demo link, you can easily change it. Please specify with some screenshot what issue exactly you are having so we will be able to check it for you.

At this point we asked if there was a security department we would be transferred to we received the following response:

We appreciate the information you’ve provided. We will forward it to our development department. They will check it more carefully.

Thank you. Have a nice weekend.

While we waited for another response (none has come in two weeks) we wondered if the password might be something really easy to guess. It turned out that we didn’t need to guess it, as we entered the password hash, “ad358a48fb2891854aa8b547c7b151be:jGftU2FbdRXUNikAQrKKeAQl9Is104QE” in to Google and on got this page as one of the results. From that we then knew that the password was “demo123”. Not only is that not strong password, but with that in hand we found a page on the Template Monster website that told everyone what the username and password was for website using this sample data:

Right below that is a message that indicates that they were aware of there being a risk from providing this user account:

You can delete sample user though the Joomla administration panel in the “Users > Users Manager”. In case you are planning to use sample data we recommend you to change Sample Author user login and password.

We still don’t understand what the purpose of creating a sample Super User like this, since another one is created when installing Joomla.

Kaspersky Lab’s News Website Threatpost Spreads Unfounded Claims About Security Threats

The Russian security company Kaspersky Lab has been in the news a lot recently in regards to questions about its relationship with the Russian government, but what deserves to get some focus is how their news website, Threatpost, helps to spreads unfounded claims about security threats coming from others in the security industry.

Back in November over at the blog for our Plugin Vulnerabilities service we looked at a situation where the Threatpost had covered a claim by the security company Checkmarx that they had found “severe” vulnerabilities in several WordPress eCommerce plugins. At the time Checkmarx presented no evidence to back the claim up and stated that it would be “available in the future”. What they did present indicated that the vulnerabilities, if they existed, might be less than severe. In May we went to look to see if any additional information had ever been released, but we couldn’t find any update and we received no response from Checkmarx when we contacted them asking were we could find it.

Today we ran in to another example of the Threatpost spreading an unfounded claim about a security threat. This time it was with a threat resolving around placing the files for WordPress on a website and then not running the installer. The following line in the article stood out:

WordPress experts claim the attack method isn’t exactly new, but that it clearly hasn’t limited its effectiveness.

The article and the cited source for the article do not provide any measure of effectiveness of the attack. The only cited figure is rather underwhelming argument for even covering this, “biggest increase in scans – roughly 7,500 a day”. Considering that there are apparently at least 100s of millions of websites currently, that isn’t a significant number (it does look like attacks occur a lot more than though, but not more than many other threats that don’t receive any coverage).

We left the following comment on the post pointing to the lack of backing for the claim as to effectiveness of attack:

Your article implies the attack is effective, “WordPress experts claim the attack method isn’t exactly new, but that it clearly hasn’t limited its effectiveness.”, but you and Wordfence don’t present any evidence as to the effectiveness of these attacks. We have seen hackers do large scale attacks that had no chance of being successful because they didn’t understand what they trying to exploit, so 7,500 attempts in a day isn’t in any way an indication that this is effective.

Originally it was held for moderation:

But shortly after that it was removed. So they were clearly aware of the issue, but instead of addressing it they would rather not let people know that they are making unfounded claims.

It also worth noting that first part of the sentence “WordPress experts claim the attack method isn’t exactly new” isn’t all that accurate. It isn’t just a claim that the attack method isn’t new, it actually is factually true that it isn’t new. For example, the issue was brought up five and half years ago and we discussed it at the time.