Don’t Get Caught With Plugin VulnerabililitesWith our Plugin Vulnerabilities service you are alerted if you any of the WordPress plugins you use contain a security vulnerability.
Search This Blog
- Sucuri Doesn’t Have A Clue What Brute Forcing Actually Refers To
- Where Are The Vulnerabilities That SiteLock’s Vulnerability Scanning Should Have Found?
- Joomla Firewalls Are Not a Replacement For Properly Cleaning Up a Hacked Website
- SiteLock Promoted Services To WordPress.com Users That Are Not Relevant to Them
- SiteLock Filed a DMCA Takedown Notice Against Our Website For A Screenshot of Their Homepage
Web Software Updates
Did We Make a Mistake?While it seems to be acceptable for blogs discussing web security to contain numerous factual mistakes, we hold ourselves to a higher standard. We only write about things that we actually understand and only after we have double checked the information. So if you see a mistake in one of our posts please leave a comment on the post or contact us so that we can add a correction.
Category Archives: Bad Security
SiteLock Spreading False Information About WordPress’ Security To Their Customers Through Their Platform Scan for WordPress
A couple weeks ago we had a post about the WordPress security company Wordfence’s scary lack of security knowledge, which something they certainly are not alone in among security companies with a focus on WordPress. Another such company is SiteLock, that in a recent post announcing a new feature that is supposed to warn of known vulnerabilities in WordPress, showed they lack a basic of understanding of how WordPress handles security issues, leading to SiteLock warning their customers of WordPress vulnerabilities that don’t actually exist on their websites.
In the fourth paragraph of the post they say something that would red raise a big red flag from anyone who actually some knowledge of WordPress security:
Vulnerabilities can range from cross-site scripting (XSS) and SQL injection (SQLi), to authorization bypass. Issues are presented with their name, category, severity, a summary of the issue, and a more detailed description. For example, when scanning a WordPress website running v3.9.13, many serious vulnerabilities are found detailed in the scan report.
The reason for the red flag is that WordPress 3.9.13 is the latest version of WordPress 3.9, so that version should have little to no known security vulnerabilities. To understand why that it helps to understand how WordPress handles security updates. Back in WordPress 3.7 a new feature, automatic background updates, was introduced. This allows WordPress to automatically update between minor versions, so a website would automatically updated from 3.9.12 to 3.9.13, but would not automatically update to 4.0. Alongside of that WordPress started releasing security updates for older versions of WordPress that contain that feature, even as they moved on to newer versions of WordPress. So for example when the security release 4.5.3 was put out, so was 3.9.13, with the same fixes.
So while you should be keeping up to date with WordPress, if you are running WordPress 3.7 or above you should still be relatively secure against WordPress vulnerabilities since you would normally be getting those security updates. If you deal with the security of WordPress websites and in particular if you deal with cleaning up hacked websites, this is something you absolutely should know since it plays an important role in the determining the possible sources of the hack. SiteLock does those things, but clearly isn’t aware of this. Which you can tell by screenshot of their scan report warning about a couple of “Critical” severity vulnerabilities in WordPress 3.9.13 that don’t actually exist in that version:
[The following image is missing because SiteLock doesn’t want to you to be able see text they copied from other people’s websites.]
From the announcement post, WordPress 3.9.8 fixes three cross-site scripting vulnerabilities and a potential SQL injection that could be used to compromise a site (CVE-2015-2213).
It also includes a fix for a potential timing side-channel attack and prevents an attacker from locking a post from being edited.
From the announcement post:
- A serious critical cross-site scripting vulnerability, which could enable anonymous users to compromise a site.
- Files with invalid or unsafe names could be upload.
- Some plugins are vulnerable to an SQL injection attack.
- A very limited cross-site scripting vulnerability could be used as part of a social engineering attack.
- Four hardening changes, including better validation of post titles within the Dashboard.
The final paragraph of their post doesn’t show good grasp of the reality of securing WordPress websites:
In WordPress security, knowing you have a vulnerability is half the battle. Taking action to remediate vulnerabilities is the other half. Fortunately, as many WordPressers know, the majority of issues found will likely be resolved by simply updating the WordPress core, plugins and themes. However, most WordPress users don’t regularly check the WordPress.org forums or subscribe to notifications about plugins, so they may not be notified of major security issues that haven’t yet been patched. With the new Platform Scan for WordPress, we are increasing the visibility of security concerns to help you be the most informed WordPress user you can be.
Your focus should be first and foremost on keeping the software on your website up to date, since the reality is that you will not always know if a new version includes a security fix. So knowing about vulnerabilities is much less than “half the battle”. Another problem, we know from running our Plugin Vulnerabilities service, is that even if “regularly check the WordPress.org forums or subscribe to notifications about plugins” you won’t know about many unpatched vulnerabilities out there, as lots of vulnerabilities appear to be known and being exploited by hackers, but no one has been noticing them, until we started actually doing the work needed to find them. So could SiteLock play a similar role? It is possible, but based on their track record and the fact that they look to be just reusing existing vulnerability data (which doesn’t even include many vulnerabilities that we have disclosed that exist in the current versions of plugins) it seems unlikely. If you want to be most informed WordPress user when it comes plugin vulnerabilities then signing up for our service would do that over SiteLock’s.
SiteLock’s post doesn’t say where their data comes from (which raises another red flag), but what is shown in the scan results screenshot in their post it looks they are using data from the WPScan Vulnerability Database and adding in some additional information from the US-CERT/NIST. Considering that we have found that the WPScan Vulnerability Database has some serious quality issues when it comes to their listing of plugin vulnerabilities, SiteLock’s data is likely to also likely to have those issues as well.
We would have placed a comment on their post letting them of the problem with their data, but they don’t allow comments (maybe because they would be inundated with complaints about how they treat their customers).
Use of Very Outdated Versions of WordPress Security Plugin Is a Reminder of the Challenges to Improving Security
In cleaning up lots of hacked WordPress websites over the years one thing that we have noticed fairly often is that there are security plugins installed (that clearly didn’t actually protect the website from being hacked, since it got hacked) and on those websites the security plugin(s) and other installed plugins haven’t been kept up to date. Keeping the plugins up to date is going provide you a lot more protection than a security plugin is going to provide (if the security plugins provide any protection at all), so that combination surprised us at first. Even with that knowledge, something we ran across recently stuck out to us.
While doing some checks over security plugins for security issues in them for our Plugin Vulnerabilities service, we recently spotted a couple in the plugin Centrora Security. We have notified them of the issue and hopefully the vulnerabilities will be fixed soon. While looking over the plugin we noticed on the plugin’s Stats page that most of the active installs seem to be running quite out of date versions.
The current release, 6.5, is only used on 26.8 percentage of the websites using it according to wordpress.org’s data:
The breakdown for the other versions shown there are:
- 1.0: 12.5%
- 1.6: 29.2%
- 2.2.: 11.9%
- other: 19.6%
One possible explanation for that could have been that the plugin had jumped a lot of versions recently, but looking back at when the older versions were released shows that isn’t the case here. Version 1.0 was superseded with version 1.5 on February 13, 2013. Version 1.6 was superseded with version 2.0 on September 10, 2013. Version 2.2 was superseded with version 3.0 on April 4, 2014.
Another possibility would be that websites using the plugin are still on an older version of WordPress that isn’t’ compatible with newer versions of the plugin. The current version is listed as requiring WordPress version 3.7 or higher, which would make it compatible with the vast majority of WordPress websites based on WordPress’ chart of versions of WordPress currently being used:
Looking at what versions of WordPress were required for the old releases doesn’t seem to explain this as, as version 1.0.0 of the plugin required WordPress 3.3, version 1.6.0 also required 3.3, and version 2.2.0 required at least 3.5. So it is not as though the websites could be using a much older version of WordPress than 3.7.
When you have people concerned enough about security to install a security plugin, but not update it in years, despite keeping plugins up to date being an import and rather basic security measure, it points to the difficulty that there is in trying to improve the current poor state of security.
Since we are discussing keeping plugins up to date, don’t forget that we offer a plugin that will turn on WordPress’ ability to automatically update plugins, so you can easily keep your plugins up to date.
If you follow the news what seem pretty clear is that cybersecurity is not in good shape these days, whether it’s major credit card breaches at retailers or hacks of high profile organizations, clearly something is very wrong. It seems unlikely that is due to a lack of spending on security products and services, consider that estimates of yearly spending on cybersecurity are in the 10s of billions of dollars and expected to continue to rise. Instead part of the explanation is that much of that money is being spent on products and services from companies that know and or care little about security.
To give you one example, anti-virus software from well known companies Kaspersky Lab, Norton, McAfee, Sophos, and Trend Micro all were found by Google researcher Tavis Ormandy to have had exploitable vulnerabilities in them. When you have to be concerned that security products are increasing your security risk that indicates something is quite wrong. But what is more striking about those vulnerabilities is the ease of exploiting some of these and that they were due in part to the companies doing dumb things. For example, in the case of Norton, quite of few of their products, including enterprise products, were subject to a remote code execution vulnerability that could be exploited by sending an email (it wouldn’t have had to be opened) that was due in part to running code at a higher privilege level than was have been needed.
As we have ramped up our Plugin Vulnerabilities service for keeping track of vulnerabilities in WordPress plugins, we have run across more of what WordPress security companies are up to and what is seen is that are not the exception when it comes to the poor state of security companies. One such example is Wordfence, we have frequently seen things that showed they either didn’t know or care much about security.
What we have wondered for some time though, is it more that they don’t know about security or if they just don’t care about it. To see why that is, take their involvement in the widespread claim that brute force attacks against WordPress admin password are occurring, despite the fact the evidence from Wordfence and other security companies actual shows that they are not. Does Wordfence had no clue what they were talking about or do they know they were telling people a falsehood to help push their product and service, seeing as those wouldn’t be needed if people knew what the malicious login attempts falsely being labeled as part of brute force attacks were most likely part of, dictionary attacks, which can be protected by simply using a strong password. We really were not sure.
In another example, Wordfence made a bold claim about being able to protect against stored XSS attacks, which we found to be false with some simple testing. In that case it could have either been that they were saying something they knew wasn’t true or it could have been that they understand so little about this type of vulnerability that they didn’t understand what incredible claim they were making and that they needed to be very careful about making it without being sure about the claiming.
We think the latest false information put forward them makes it pretty likely that they are lacking a basic understanding of security, which is frightening since so much of the WordPress community is relying on them for information and protection.
In a post about what they say are the most attack plugin vulnerabilities (worth mentioning here is that we recently found that Wordfence seems to be oblivious to vulnerabilities in plugins that are actually the biggest threat) they made a claim that we and they found out surprising, that many of the vulnerabilities being targeted were local file inclusion (LFI) vulnerabilities:
The large number of local file inclusion vulnerabilities that are being exploited is surprising. I should also note that many of these LFI’s were discovered by Larry Cashdollarwho I had the pleasure of seeing speak at Defcon in Las Vegas 2 weeks ago. So I suspect that many of these are being used in an attack script of some kind which may explain their prevalence in the attacks we’re seeing.
The clustering of LFI’s together and Shell exploits together in the list order is odd, but I don’t have a theory to explain that and there is no error in the data that accounts for that. It appears to be coincidence.
Considering that everything we know from monitoring plugin vulnerabilities and dealing with lots of hacked websites is that this type of vulnerability is rarely targeted, this seemed odd. But a quick look at the data they presented showed a simply explanation, local file inclusion vulnerabilities were not actually be targeted. Instead what was being targeted were what we refer to as arbitrary file viewing vulnerabilities (they are also often referred to arbitrary file download or directory traversal vulnerabilities), which are very different.
Before we get in to what each of those type of vulnerabilities is, it is worth mentioning that Wordfence really had to go out of their way to get this wrong, as can easily seen by the fact that the first five vulnerabilities they listed as being local file inclusion vulnerabilities are actually listed in the linked to advisories as being the following types of vulnerabilities:
- Arbitrary File Download
- File Disclosure Download
- Arbitrary File Download
- Aribtrary File Download
- Arbitrary File Download
Not one of those is listed as listed local file inclusion vulnerability, so Wordfence must have thought they were all wrong.
A local file inclusion (LFI) vulnerability allows an attacker to include a file that exists on the file system of the server the website is on (a remote file inclusion (RFI) vulnerability allows the same with a file that exists somewhere else). For this type of vulnerability to useful to a hacker they either need to be able to place a file on the website or there needs to be a file thats inclusion in this way causing a security issue. Since those do not appear to be readily available in most cases it follow that this type of vulnerability is not often being exploited.
An arbitrary file viewing vulnerability allows viewing the contents of a file that exists on the website. With WordPress websites we frequently see attempts to exploit this type of vulnerability to view the contents of the wp-config.php file. If successful that would provide the attacker with the database credentials associated with the website. For that to be useful the attacker would need to be able to connect to the database, their ability to do that varies greatly depending on the hosting setup. While we see many attempts to exploit this type of vulnerability, we see it being the cause of a website being hacked much less than arbitrary file upload vulnerabilities, which we also see many exploit attempts against.
While Wordfence’s lack of understanding what each of these vulnerabilities would likely has some impact on protecting against them, it would have an even bigger impact on their properly doing hack cleanups (which they also offer) since it greatly helps to understand what security vulnerabilities have existed on the website to determine the source of the hack and the impact the exploitation of a vulnerability could have had.
If you care about security we would recommend you help us get the truth about Wordfence out to a wider audience so that together we can lessen the damage they are doing toward the security of so many websites.
Questionable Support Advice on Dealing With Hacked Websites From WordPress and Norton Safe Web’s Mystery Blacklisting
One of the things we do to keep track of vulnerabilities in WordPress plugins for our Plugin Vulnerabilities service is to monitor the WordPress support forum for threads related to them. In addition to threads that actual relate to that issue, we frequently run into to other security related threads. In doing that we noticed that in many threads a reply containing the same advice is given, which consisted mainly of a series of links. Some of the pages linked don’t seem to provide the best information, so we wondered if the various members providing that reply were actually aware of what they were linking to or if they were just repeating something they had seen others saying. While looking into another issue involving the forum we found that the source of the message was from a series of pre-defined replies for moderators.
While looking into another thread that came up during that monitoring of the forum we came across evidence that one of the links they include, a link to something called Sucuri SiteCheck, may not be the most appropriate to include. In that thread the original poster had written:
Sucuri is showing my site as harmful and is asking for $16/month to fix it, yet my site seems fine, traffic is normal and I have no log in / access problems on any browser or device.
When we went to look to see why Sucuri was claiming the website was harmful, the SiteCheck page was light on details and high on pushing you to use their service:
Looking at the other two tabs of information, the only issue that they were identifying was that website was blacklisted by “Norton Safe Web”:
It seems to us that a service would be careful in situation where they are not themselves detecting anything malicious, but Sucuri seems to be labeling the website as “Site Potentially Harmful” and “Site Likely Compromised” based only on the fact that Norton Safe Web was blacklisting it. Based on our limited experience with Norton Safe Web, that would seem to not be appropriate because the results we have seen from it in the past have been rather poor.
Looking at what they are claiming to have detected with this website makes us more confident of the position.
Here is what they are reporting as of now:
You can see they are not claiming that there are any “computer threats” or “identity threats”, just an “annoyance factor”. What the “annoyance factor” isn’t really further explained, with the only information being that a page is listed as having a “SWBPL” threat. There is no explanation what a “SWBPL” threat is either on the page or through a link. In searching around to try to find out what that is, we found that we were not alone in trying to figure that and that even some people at Norton did not know what it is. The most detailed information we could find was in a thread on the Norton website, where it was stated that:
SWBPL is one of the threat type in safeweb which is based on telemetry which we collect from 3rd party vendor feeds. Since these sites are classified based on the static data it is pron to few FPs
So Norton is apparently warning about the website based on unidentified third-party’s data, which is also apparently prone to a “few” false positives. That doesn’t really seem like something that should be the source for Norton warning about a website and certainly shouldn’t be used by someone else to make claims as to the security of the website.
Looking at the URL they identified as being a “SWBPL” threat, visiting it normally just returns a “Page not Found” message and when visiting it in some other ways didn’t produce any different result. Without having access to the backend of the website we can’t rule out there is some issue with it, but from the outside there is nothing we could find harmful about it.
We hope that WordPress will review the boiler plate message they provide to those with questions about hacked websites and consider if they are providing the best information in it.
Automattic Helping Security Companies Peddle False Narrative of Brute Force Attacks Against WordPress Admin Passwords
Last week we looked at one example of the poor state of security information surrounding WordPress, security companies falsely claiming that brute force attacks against WordPress admin passwords are happening (and also offering products and services that are supposed to protect against that non-existent threat). That has negative impact on security since you end with a lot focus and concern on something that isn’t actually threat while other issues, like the poor state of WordPress plugin security, which actually leads to websites being hacked, don’t get the focus and concern they should and needs to get.
While security companies being part of the problem isn’t something that really surprises anymore, considering that most of them seem to either know and or care little about security, when other companies that you would expect to be better, are part of the problem, it is surprising to us. That brings us to the company closely connected to WordPress, Automattic, which has among their offerings the plugin Jetpack.
Despite the fact that brute force attacks simply are not happening, protection against them is prominently advertised feature of the Jetpack plugin. As can be seen on the plugin’s page on wordpress.org:
and on the features page on the plugin’s website:
It easy to think the public would be more likely believe that they were happening when they see that.
At the same time the Jetpack website provides further confirmation that brute force attacks are in fact not happening. Going back to our previous post, with a password made up of numbers and letters (upper case and lower case) that is six characters long, there are over 56 billion possible combinations. By comparison according to the website, Jetpack has only blocked over 1 billion attempts:
Jetpack has blocked over one billion malicious log-in attempts aimed at our users’ WordPress websites.
While that might be enough attempts for a brute force attack to succeed if they all occurred on one website, that is a cumulative total across possibly millions of websites and maybe for a period of over a year, so it shows that there are not even close to enough attempts for brute force attacks to be happening.
We hope that Automattic will become more consciousness of the impact they have on the security of WordPress going forward, because it would be a help to us and others that are trying to improve the situation.
We were recently brought in to deal with a WordPress website that had been hacked multiple times and just re-hacked. In that type of situation one of the first things that should be done is to review the log files available for the website, since those are likely to provide evidence on how the website is being re-hacked and depending on how far the logs go back, how the website was originally hacked.
One of the big problems we find in being able to review the log files of a hacked website, is that often times web hosts only store the log of HTTP activity for a short period, in some cases less than a days worth of logging is available. One of the better web hosts when it comes to this is GoDaddy. With their standard web hosting accounts using their own control panel, they store about a months worth of logging. When using the cPanel control panel instead, the log is stored for a shorter time period by default, but you can enable archiving, so we can at least make sure it stored for a longer period once we get started on the cleanup.
The website we are dealing with in this case though was in GoDaddy’s Managed WordPress hosting account, which we would find out when the client tried to get access to the log files, does not provide any access to the log files. We are puzzled that they manage to provide that in the standard web hosting accounts, but not not in what would seem to us to be a higher end type of account. The explanation for why they can not provide it, is also puzzling, as they say they can’t provide it because the website is hosted in a shared environment. The other web hosting accounts are also on shared environment and yet they manage to provide them there.
If you are concerned about security we would recommend that you not use their Managed WordPress hosting until they resolve this, since if you were to get hacked, you are going to be missing important information needed to properly clean it up (is worth mentioning that many companies that do hack cleanups either don’t know how to do things properly or are cutting corners and don’t review the log files like they should).
While we were looking over the marketing materials for the service we noticed some security claims that are also worth mentioning. One of the “key features” of the service is that they “keep the bad guys away”:
Seeing as the website we are dealing with got hit multiple times while using this hosting service, their ability to actually protect the websites is is at least limited.
The ability to protect the website is also contradicted by another feature available in one level of account, which removes malware from the website:
If they were actually able to protect the websites, as they advertise, then there shouldn’t be any malware getting on the website that needs to be removed.
We would also have wondered about the fact that the company SiteLock would be involved in doing hack cleanups on this service, when they can’t do things properly because the logs are not available, if not for the fact that we have seen that SiteLock doesn’t seem to seem to be interested in properly cleaning up websites and is known for taking advantage of their customers.
When it comes to security companies, trustworthiness is critical, since the average person isn’t going to have the knowledge and skills to understand if the security company is actually doing (or could even possibly do) what they are claiming to do to protect them. Any upstanding security company would therefore be very careful in what they say and do, so if you see a company being less than honest it should be a major red flag when it comes to using their products and services.
That brings us to something we noticed in the WordPress security plugin iThemes Security. When you install the plugin a notice is displayed at the top of pages in the admin area that read “New! Take your site security to the next level by activating iThemes Brute Force Network Protection”
If you get click the “Get Free API Key” button in that notice you get shown the following page:
On that page they accurately describe what a brute force attack is, so clearly they know what it is. What they either don’t know or they are intentionally not telling people is that brute force attacks against WordPress admin passwords are not happening, so you are not taking your site security to the next level by enabling that feature as they claim.
What makes this more troubling is that they are using the non-existent threat of brute force attacks to try to collect users’ email addresses. By default permission to send “email updates about WordPress Security” is also included when doing that and considering in the best case here they are not aware of it pretty basic security fact that brute force attacks are not happening, the quality of the security information they would provide in those email is likely to be poor.
Just based on this it would seem like a good idea to avoid this company and their plugin, but it isn’t the only issue with found with the plugin recently. Back in April we ran across the fact that the plugin had button labeled “One-Click Secure” that didn’t do anything.
When it comes to improving the security of the WordPress ecosystem one of the biggest problems we see is the shear amount misleading and often times false information that is put out by security companies. One of the most frequent falsehoods we see is the claim that there are a lot of attempts to brute force WordPress admin password. Not only is the claim false, but is so obviously false that these security companies either don’t understand the basics of security or they are knowingly lying to the public, either of which would be a good reason for you to avoid them.
To understand how you can tell that these brute force attacks are not happening, it helps to start by looking at what a brute force attack involves. A brute force attack does not refer to just any malicious login attempt, it involves trying to login by trying all possible passwords until the correct one is found, hence the “brute force” portion of the name. To give you an idea how many login attempts that would take, let’s use the example of a password made up of numbers and letters (upper case and lower case), but no special characters. Below are the number of possible passwords with passwords of various lengths:
- 6 characters long: Over 56 billion possible combinations (or exactly 56,800,235,584)
- 8 characters long: Over 218 trillion possible combinations (218,340,105,584,896)
- 10 characters long: Over 839 quadrillion possible combinations (839,299,365,868,340,224)
- 12 characters long: Over 3 sextillion possible combinations (3,226,266,762,397,899,821,056)
Now that you have an idea of the number of requests it would take to actually do a brute force attack, lets look at the number of attempts that security companies are claiming are occurring that support their claim that brute force attacks are going on.
First up is Wordfence, back in January they put out a post about the claim that brute force attacks are going on and gave a figure for how many login attempts had occurred over a recent 16 hour period (they call each login attempt an attack):
During this time we saw a total of 6,611,909 attacks targeting 72,532 individual websites. We saw attacks during this time from 8,941 unique IP addresses and the average number of attacks per victim website was 6.26.
The total during that time period likely isn’t any where near enough login attempts for even one brute attack to be successful, but with less 7 attempts per website, that clearly is not evidence of brute force attacks actually occurring.
How about Sucuri Security, they have a page on their website entitled WordPress Brute Force Attacks, that is supposed to present the “state of brute force attacks against WordPress sites”. The graph shown there includes failed login attempts for websites “protected” behind their website firewall. There is an obvious issue with that since failed login attempts are not necessarily malicious, so the graph is not necessarily entirely that accurate. Even with that caveat, the largest amount on one day looks to be have been about 50 million requests:
We don’t know how many websites that is split across, but even if it was one website that likely wouldn’t be nearly enough for one successful brute force attack per day.
In one instance recently, someone we perviously did some work for contacted us because they had gotten an email from Sucuri’s WordPress plugin that was alerting them to brute force attack. In that instance Sucuri was claiming that a brute force attack was occurring based on a total of 30 login attempts.
Security Companies That Don’t Understand the Basics of Security
Back in September of last year Sucuri not only claimed that brute force attacks where happening, but also claimed that brute force attacks are frequent source of hacking (despite the fact that they are not actually happening at at all):
However, brute force attacks are still going strong. In fact, they are one of the leading causes of website compromises.
So what could explain the false claims about brute force attacks?
One explanation is that these security companies don’t have an understanding of the basics of security, like knowing what a brute force attack is. Considering you don’t have to look at some obscure resource to know what they are, you just have to go to the Wikipedia, there isn’t any excuse for that.
The other explanation is that these security companies do know what a brute force attack actually is, but they are lying about them happening since if they told what was actually happening they wouldn’t be able to use it to push the products and services they provide. That would have the added bonus of allowing them to claim they can protect against something, without having to worry about that turning out to not be true (as we recently found with another claimed protection by Wordfence), since the brute force attacks are not actually happening.
Protecting Yourself From the Real Threat, Dictionary Attacks
So based on those security company’s data brute force attacks are not going on, but there are malicious login attempts happening, so what is actually happening? Based on looking at actual login attempts and the number of requests it looks like most of the malicious login attempts are from dictionary attacks.
A dictionary attack involves trying to log in using common passwords, think things like “123456” and “123admin”.
With dictionary attacks protecting your website is really easy, just use a strong password. Thats it. You don’t need to put in place all sorts of other protection, since the dictionary attacks will fail as long as you do that. WordPress now defaults to generating a strong password and displays a password strength indicator if someone chooses to create their own password, so if you have an Administrator choosing to use a weak password, you probably have bigger issues to worry about. If you are concerned about lower level users using weak passwords and then being subject to dictionary attacks, there are a number of options to enforce stronger passwords that are available.
With it being that easy to prevent what is going on, it would be difficult for security companies to promote products and services to deal with this, so that is why we wonder if they are intentionally lying about what is going on.
It also worth noting that there is likely a quite a bit of overlap between the passwords tried during different dictionary attacks, so the amount passwords tried is likely much less than the total attempts occurring over even a fairly short period of time.
Help Us Clear Things Up
If you see someone claiming that brute force attacks against WordPress admin accounts are happening, we would appreciate if you point them to this post, so that we can start to clear up the false information being pushed by those security companies and people can start focusing on properly protecting themselves.
When it comes to bad security companies Sucuri Security is certainly up their for a variety things we have seen them do over the years. In just a few of those cases we have written up blog post about those. The company clearly don’t like that we exposed some of their bad practices, as something we just ran across today shows. Someone had posted a review for one of their WordPress plugins, which linked to several of our posts. The review has now been edited, but from the Google cached version you can see what was there and response from Sucuri’s CEO:
The part relevant to our previous posts was (our emphasis added):
Those articles have absolutely nothing to do with the issue you experienced or this ability of this plugin, they are inflammatory and now you’re crossing into the line of social harassment unnecessarily. It’s a shame, seeing your social presence that you’d stoop so low. They are also inaccurate and completely out of context.
So what were these articles they claim are inaccurate and inflammatory.
The third article linked to discussed the poor state of Sucuri’s scanner several years ago, which was accurate then and based on what we have seen more recently the scanner still seems to be quite poor.
The second article discussed an attempt by Sucuri to astroturf a comment on that third article, which they admitted to in the comments of the second article. That comment came from the same person now claiming that the articles are inaccurate, but in his attempt at astroturfing he didn’t actually point out any real inaccuracy in the third article (if any of are articles actually contained inaccuracies we would want to correct them as soon as possible).
The first article discussed how Sucuri uses bad data to try scare people into using their service, so that would make them, not us, the inaccurate ones and probably inflammatory as well.
When it comes to the problems with cyber security one of the issues we see is that the wrong people are often getting the blame for its poor state.
WordPress frequently gets unfairly criticized in a security context, while in a lot of ways they are really at the forefront of improving security of web software. Take for example the automatic background updates feature that was released back in WordPress 3.7, which allows for security fixes to be applied million of websites quickly without requiring any user interaction.
On the other side are security companies that seem to in a lot of cases care little for security and in some cases seem to peddling false hoods to increase their profits. One such recent example where a security company didn’t seem care about security was with Trend Micro, which had a password manager included with their antivirus software that had incredibly severe security issues.
When bring these to two examples up because they come to together with something we noticed recently. Trend Micro’s blog recently is running an outdated and insecure version of WordPress:
Seeing as those versions would normally have been applied automatically within hours of their release due to the automatic background updates feature, either Trend Micro unwisely disabled that feature or some bug is stopping that from happening in their case. If it is the later then Trend Micro could actually help to improve the security of WordPress websites by working the WordPress developers to resolve that, so that others impacted by the issue could also start getting updates.
Looking at the source code of the blog homepage’s you can see that at least one of their plugins is also not up to date:
<!– This site is optimized with the Yoast SEO plugin v3.2.3 – https://yoast.com/wordpress/plugins/seo/ –>
The latest version of the Yoast SEO plugin is 3.2.5 and that version fixed a very low severity security issue (the current version of that plugin has at least one other security issue that is fairly obvious if look into the vulnerability that was fixed).