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: HighCategory: csrfSummary: WordPress 4.2-4.7.2 – Press This CSRF DoSDescription: CSRF DoS vulnerability in WordPress versions 4.2 to 4.7.2 through the Press This functionality.
Severity: MediumCategory: rceSummary: WordPress 4.3-4.7 – Potential Remote Command Execution (RCE) in PHPMailerDescription: 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: HighCategory: bypassSummary: WordPress 4.2.0-4.7.1 – Press This UI Available to Unauthorised UsersDescription: Authentication bypass vulnerability in WordPress Press This versions 4.2.0 to 4.7.1 allows unauthorized users to access the UI.
Severity: HighCategory: csrfSummary: 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: MediumCategory: bypassSummary: WordPress 2.8.1-4.7.2 – Control Characters in Redirect URL ValidationDescription: Control Characters vulnerability in WordPress versions 2.8.1 to 4.7.2 through the Redirect URL Validation
Severity: MediumCategory: unknownSummary: 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: HighCategory: xssSummary: WordPress 3.4-4.7 – Stored Cross-Site Scripting (XSS) via Theme Name fallbackDescription: 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: HighCategory: xssSummary: WordPress 4.3.0-4.7.1 – Cross-Site Scripting (XSS) in posts list tableDescription: Cross-Site Scripting (XSS) vulnerability in WordPress versions 4.3 to 4.7.1 through the posts list table.
Severity: MediumCategory: xssSummary: WordPress 2.9-4.7 – Authenticated Cross-Site scripting (XSS) in update-core.phpDescription: 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: HighCategory: xssSummary: WordPress 4.0-4.7.2 – Authenticated Cross-Site Scripting (XSS) in YouTube URL EmbedsDescription: 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: HighCategory: xssSummary: WordPress 3.6.0-4.7.2 – Authenticated Cross-Site Scripting (XSS) via Media File MetadataDescription: 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: HighCategory: sqliSummary: WordPress 3.5-4.7.1 – WP_Query SQL InjectionDescription: In WordPress 3.5 to 4.7.1 WP_Query is vulnerable to a SQL injection (SQLi) when passing unsafe data.
Severity: MediumCategory: unknownSummary: WordPress <= 4.7 – Post via Email Checks mail.example.com by DefaultDescription: 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.
A Better Alternative to SiteLock For Cleaning Up a Hacked Website
If your web host is pushing you to hire SiteLock to clean up a hacked website, we provide a better alternative, where we actually properly clean up the website.