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.