No One Is Trying To Brute Force Your WordPress Admin Password

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:

sucuri-security-brute-force-graph

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.

Sucuri Security Doesn’t Like the Truth To Be Exposed

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:

sucuri-security-innacurate-claims

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.

Trend Micro Running Outdated and Insecure Version of WordPress on Their Blog

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:

The Trend Micro blog is running WordPress 4.5

WordPress 4.5.1 was released on April 26 and 4.5.2, which fixed two security issue, was released on May 6.

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).

It Looks Like SiteLock is Scamming People

Over the past couple of years we have run across a lot of bad stuff involving the security company SiteLock, from not doing basic security checks to not doing basic parts of hack cleanups to breaking websites they are supposed to be cleaning to labeling a website that is very dangerous for visitors as being “secure”. Unfortunately those kinds of things are really par for the course when it comes to security companies (it is a really sleazy industry in general). But recently we have started to see and hear more that indicates that SiteLock has gone past that and moved to more egregiously cheating their customers. Making this more of  a problem, is that they now have partnerships with many web hosts, which gives them additional legitimacy that they shouldn’t have considering the multitude of problems we have see involving them.

One of the issues that we see coming up a lot involves SiteLock charging a monthly fee to protect websites and then when the website gets hacked they want a much larger amount to clean up the website. If the website is getting hacked then the protection being paid for doesn’t seem to be actually happening or isn’t very good. There also seems to be an incentive for the protection they provide to not actually protect, since they can actually make even more money if it doesn’t work.

The other that comes up is fairly frequently is them contacting people claiming that a website has been hacked and that they can clean it, without SiteLock actually checking to see if the website is actually hacked. One example of that we were contacted about involved a website that had been actually hacked, for which the person who took over resolving that decided to start fresh, only reusing the domain name. So the website would have been clean at the point that SiteLock contacted them, which didn’t stop SiteLock from charging them for a cleanup:

When the site was hacked, the domain was blacklisted by every major blacklister, however,since I built the new site from scratch, it was clean when it went live. In spite of that, Sitelock contacted me the day after bringing the new site live that they were in the process of cleaning malware from the site and to contact them as it was going to involve manual removal and additional costs above what the plan that came with WordPress covers. They offered me two options, 300 to clean the site and submit to the blacklisters for review or 299 (in three installments) to clean the site and provide manual removal coverage for three months, after which I could continue with the scan and removal tool and add manual removal coverage for 49.00 per month from then on.

Beyond the fact that SiteLock was charging them for an unneeded cleanup, a website shouldn’t need continuing removals of malicious code. If that is the case, that would usually indicate that the original hack cleanup wasn’t done properly and the hacker could get back in, in that case the person who did the original hack cleanup should go back in and get the issue fixed for free (we certainly would want to do that for a client).

What SiteLock then did for that monthly fee doesn’t sound great either:

I have not been able to make it even a week (in two months) without Sitelock sending me some scary critical security warning email concerning the site. One of them said that they were cleaning malware, which I had a hard time believing since I had really good passwords, 2 step verification and login limiting onthe site. It turned out, the “malware” was a file that was created when I installed the Ithemes security plugin.All the other warnings were the result of them constantly not being able to connect and access the files in ordder to scan, which I don’t understand since I had not changed the passwords and each time, the problem ended up being resolved without a clear explanation as to how or why it happened in the first place.

Based on what we are seeing we have some recommendations if you are contacted by SiteLock or if your web hosts is recommending using them:

Get a Second Opinion

Based on what we are seeing it sounds like SiteLock sometimes is claiming that websites have been hacked that haven’t actually been hacked, so it would be a good idea to get a second opinion as to whether you have been hacked when you are contacted by them.

This is a good idea in other instances as well, since we sometimes see web hosts claiming a website has been hacked due to issues that were caused by something that was actually unrelated to a hack or them not double checking results of antivirus scanners (which can produce some bad false positives).

We are happy to do a free check to see if a website is actually hacked (we always will do that before taking on the clean up of a hacked website), so we are happy to provide you with a second opinion.

Hire Someone Who Properly Cleans Up Hacked Websites

If your website has in fact been hacked it is important to make sure you are hire someone that does a proper hack cleanup. You don’t want to be like many of our clients who hire to us to re-clean their hacked website after the first company they hired didn’t do those things.

The three main components of a proper hack cleanup are:

  • Cleaning up the malicious code and other material added by the hacker.
  • Securing the website (that often means getting the software on the website up to date).
  • Attempting to determine how the website was hacked.

While determining how the website was hacked is often not possible to do due largely to web hosts failure to store log files on a long term basis (something that we found SiteLock had not rectified with at least one of their hosting partners), we have found going through the process is important to get a hacked website fully cleaned. If the source of hack hasn’t been determined then that increases the chances that the security issue hasn’t been resolved and that the website will get hacked again.

We would recommend asking the companies what there hack cleanup service involves and if they don’t mention that they do those things, then you probably should look elsewhere.

Securing Your Website

One really important thing to understand it isn’t naturally for websites to get hacked. For that to happen something must have gone wrong. So the solution to keeping your website secure is to make sure you are taking the proper security measures with your website, instead of going with a security product or service that doesn’t do those things and instead make bold claims that it will keep you secure some other way.

It also important to understand that the chances of a website being hacked are pretty small, so when you see people saying that they use a service and haven’t been hacked, it is entirely possible that the service had nothing to do with them not being hacked.

SiteGuarding.com’s WordPress Security Plugin Touts Its Use For Those That Pirate Software, While Charging For Its Services

When it comes to security plugins for WordPress, we don’t think to highly of most of them. But we have continued to be surprised how low things can go with them. Take for example the WP Antivirus Site Protection (by SiteGuarding.com) plugin, which on it’s description page on the Plugin Directory it states near the top:

This plugin will be especially useful for everybody who downloads WP themes and plugins from torrents and websites with free stuff instead of purchase the original copies from the developers. You will be shocked, how many free gifts they have inside 🙂

Their touting its use for those that pirate WordPress themes and plugins is kind of incredible on its own (note the lack of past tense in terms of downloading that software or lack of suggestion not to do that). But more incredible is the fact that at the same time the plugin is really just a connection for a mostly paid service, so they think you should pay them, but are okay with people not paying the developers of software.

What makes that dichotomy more striking is the comments from the developer on some of the negative reviews of the plugins.

One review reads:

If your website contains a file larger than 25MB, the plugin will abort and ask you to upgrade rather than just skipping it and warning you. The plugin is just a leadgen ploy. Uninstalled. Further more, of all the wordpress hacks I’ve ever seen, files affected are NEVER large or over a few kb.

That seems like reasonable complaint, which gets this response from the developer:

free version has limits. if you are not ready to pay for the security enjoy and live with the viruses.

As part of their response to another review the developer wrote in part:

If you installed it again. It means plugin is good, you just dont want to pay for good plugins and services and want everything for free.

It is also worth noting that there are a lot of rather fake looking reviews for the plugin.

The Fact That Wordfence Couldn’t Clean Up a Hacked Website Doesn’t Stop People From Suggesting That It Will Clean It

When it comes to improving the security of websites one of the biggest problems we see if the shear amount of bad information, including lots of bad advice, that is being put out there. We frequently see people suggesting using the Wordfence plugin for WordPress, which we have hard time believing somebody who is knowledgable about security would recommend due to a number of issues. Those issues include the fact that broad based security plugins like that are not all that useful against real threats, that more than a few security vulnerabilities have been found in the Wordfence plugin itself, that the developers don’t seem to have a good grasp of security, and that the plugin produces some really bad false positives. Usually you have no way of knowing if somebody giving out that advice has a different opinion in regards to those types of things or they are giving advice without really being informed about the situation. In some cases you can see that advice is being handed out uniformed, though.

As part of keeping track of security issues in WordPress plugins for our Plugin Vulnerabilities service, we monitor the wordpress.org forum for threads related to plugin vulnerabilities. In addition to helping to find some more vulnerabilities to include in our data, we run across threads about other security issues related to WordPress and WordPress plugins. In one of those we saw when the use of Wordfence being suggested as a solution, when that clearly wasn’t helpful advice.

The original poster in the thread described the problem they were having cleaning up a hacked website. After trying numerous things, including reverting to a backup copy, malicious files were continuing to be added to the website. At the end of the post they mentioned that they have three WordPress security plugins installed, but that they hadn’t been any help:

Protections plugins I’m currently using (and which can’t find anything wrong with the website)

Despite that one those plugins was Wordfence, the second and third responses suggested that Wordfence could deal with the issue:

Yes, those are not default files. WordFence is the best for scanning once you are already infected.

and

I had the same issue, so far WordFence has done a great job. Two days and no wp-checking.php has showed up. Yet!

In this type of situation what we would recommend, and did later in the thread, is to see if you can determine if the hacker still has some sort of access to the website, which is allowing them to continue to modify the website, and if that is the case, close off that access.

Incidentally, one of the other plugins they were using, AntiVirus, was one that we found was flagging a fresh install of WordPress as having virus back in 2012.

Google Needs to Improve the Review Process for Websites Labeled “This site may be hacked”

Early last year Google changed some of the underlying technology used in their process of of handling websites they suspect of being hacked (which leads to a “This site may be hacked” message being added to listings for the websites on Google’s search results). More than a year later we are still finding that the review process for getting the”This site may be hacked” message removed after cleaning up such a website is in poor shape and likely lead leading to a lot of confusion for people trying to navigate it if they don’t deal with it’s problems on regular basis (like we do). While we think that what Google is doing by warning about these situations is a good thing, the current state of the review process is not acceptable.

To give you an idea of what are people are dealing with lets take a look at what we just dealt with while getting Google to clear a website we had cleaned up.

Once you have cleaned a website with the “This site may be hacked” message, you need to add the website to Google’s Search Console and then you can request a review in the Security Issues section of that. That section will also give you information on what Google detected:

security-issues-page-1

 

In this case Google detected that spam pages were being added to the website, which they refer to as an URL injection.

Before requesting a review last Monday, we doubled checked that the spam pages no longer existed using the Fetch as Google tool in the Search Console, which allows you to see that what is served when a page is requested by Google. The URL they listed on the Security Issues page was “Not found” when we used the tool, indicating that the spam page was no longer being served to Google.

On Tuesday a message was left in Google’s Search Console for the non-www version of the website’s domain indicating that hacked content had been detected:

seach-console-message-non-www

Considering that Google was already listing the website as having a security issue for several days you might think this was a new detection, but it wasn’t. In the security issues section it still listed the old last detected date:

security-issues-page-2

Using the Fetch as Google tool in the Search Console we requested the URL again and it was still “Not found”:

fetch-as-google-4-19-2016

Then on Wednesday the same message was left for the www version of the domain:

seach-console-message-www

Again the last detected date in the Security Issues section hadn’t been changed and the using the Fetch as Google too the URL was still “Not found”:

fetch-as-google-4-20-2016

Then on Saturday the Security Issues page indicated that URL injection had been detected as of that day:

security-issues-page-3

We again used the Fetch as Google tool and it was still “Not found”:

fetch-as-google-4-23-2016

At this point we also checked the website over to make sure the malicious code hadn’t returned and it hadn’t.

Then this morning the warning was gone from the search results and the Security Issues page was clear:

security-issues-page-4

Considering that nothing changed between Saturday and today, that detection on Saturday would seem to be some kind of a mistake. Seeing at the page wasn’t even being found this doesn’t seem like an understandable false positive, but something seriously wrong with their system. If you weren’t aware of that how problematic the process is, you might have been very concerned upon seeing the new false detection.

The fact that it took them a week to finally clear the website also doesn’t seem to be an acceptable in this case.

 

iThemes Security Plugin Has “One-Click Secure” Button That Does Nothing Except Claim The Website Has Been “Secured”

We are frequently asked what about various broad based WordPress security plugins and which ones should be used. Our answer to the second part of that is none of them. These plugins generally provide little protection against actual threats and have been found to have security vulnerabilities themselves fairly often. That second part might sound odd, you would think that someone developing a security related plugin would be very careful about the security of their plugin, but people that actually know about security would be unlikely to be involved in developing one of these due to the first part of that, that they don’t provide much protection against actual threats.

So what you are left with is products generally developed by people that don’t have much concern for real security and in a lot of cases seem to be mainly interested in making money by taking advantage of the public that understandably lacks strong security knowledge. That results in lots of plugins and related services that end up scaring people based on bad or false information and that collect information from users under false pretense.

If you are looking for some particular security feature you would be better off finding a plugin that doesn’t also include a kitchen sink of other features with it, since that reduces amount of code that could be harboring security vulnerabilities. The important things you need to do to keep your website secure are listed here.

The iThemes Security Plugin And Trust

That all brings us to something we just ran across with one of those plugins, iThemes Security (formerly Better WP Security), which is listed as having 700,000+ active installs.

One important element of any security product is trust, since the average user can’t verify that a product does what it says, they are trusting the developers in a major way. Any abuse of that trust should be a major red flag. That trust is something the developers of the iThemes Security plugin don’t seem to care about.

When you install and activate the iThemes Security plugin a notice is displayed at the top of the page with a button to “Secure Your Site Now”:

ithemes-security-1

Clicking on that brings up this page:

ithemes-security-2

The most important part of that would seem to be the section Titled “Secure Your Site”:

Use the button below to enable default settings. This feature will enable all settings that cannot conflict with other plugins or themes.

When you click on the One-Click Secure button, you get a message that it is “Working…” for a moment:

ithemes-security-4

Then it will tell you that “Site Secured. Check the dashboard for further suggestions on securing your site.”:

ithemes-security-5

Based on that you would think that the website has been secured in some way after doing that. It turns out that nothing actually has happened, something we found about when ran across a post on a thread on the WordPress.org support forum for the plugin that stated

Please note that since the 5.2.0 release (5.2.1 included) clicking on the One-Click Secure button in the First Important Steps modal window will not do anything despite the fact that it still reports:

Site Secured. Check the dashboard for further suggestions on securing your site.

which is also kind of lame as there is no longer a Security Status section on the Dashboard page …

Note this is not a bug, since iThemes knowingly removed the code that was normally executed behind this button …

If you want to see that for yourself you can see the changes made in version 5.2.o here (doing a search on the page for “Register one-click settings” will take you to parts of the page where that is shown). What makes this even more incredible is how long ago this happened, version 5.2.0 was release on January 18 and the post pointing that out is now two months old, and yet it is still that way now.

When they don’t care about misleading people with something that visible, then you have to wonder what else they might be misleading people about. We already spotted one other thing, but you will have to wait for a future post to hear about that.

Somebody’s Impersonating Us On The Hacker News

A lot of strange stuff happens on the Internet. Case in point, today some posted a comment on a Hacker New post claiming to be us, saying:

This type of nonsense from WordFence shouldn’t surprise anyone. I’ve written of their incompetence before: http://www.whitefirdesign.com/blog/2015/02/23/wordfence-real…

Laugh and move on…

That wasn’t us and we don’t have an account there.

 

Who’s The Worse Party In HostGator’s and SiteLock’s Security Partnership?

The web host HostGator has a partnership with the security company SiteLock where if your website is hacked HostGator suggests you hire SiteLock to fix it, which if you followed our previous post’s on SiteLock would seem like a bad idea. The actual results also back that up, as situation we we dealt with recently highlighted.

A website we were going to be doing an upgrade on once HostGator changed the PHP version on the server, got hacked and was rendered non-functional due to it being defaced. HostGator recommend SiteLock to clean up the website. Getting the website back up and running should have taken just a few minutes (by replacing the index.php file in the root directory), with a full cleanup taking a few hours. Four hours after they were supposed to have started it was still not functional and we were contacted to see if we had any suggestions. The website only became functional later in the day after the website’s developer followed our advice to replace the index.php file, by the next morning SiteLock had removed the defaced index.php file. When we double checked SiteLock’s work later we found that they had not removed a backdoor script, which allows a hacker remote access to a website, that had been added to a core Magento file in the root directory of the website. While things can be missed during a cleanup, this seems to be a case where corners were probably cut instead of an understandable mistake since a simple file comparison of the website’s file with a clean copy of Magento would have spotted that backdoor script.

All this would point to it being a bad idea for HostGator to have partnered with SiteLock, but there are problems going the other way as well.

A couple of weeks ago we discussed the fact that HostGator misrepresents what security SSL certificates provides. If SiteLock was actually concerned about security it seems like the kind of thing they would want to make sure a partner isn’t doing. But a much more important issue that we have noticed with HostGator when comes to a security, particularly when comes to the cleanup of hacked websites, is that HostGator doesn’t have it set so that log files for websites they host are archived. By not doing that it is much harder to determine how a website was hacked (since the evidence often resides in those logs) and therefore makes it harder to make sure the website has been secured against the hack happening again. We have trouble understanding why a security company would want to partner with a web hosting company that makes doing a good job more difficult than it needs to be. Especially when archiving logging isn’t some obscure feature, it prominently featured on the Raw Access Logs page in cPanel:

host-gator-cpanel-raw-access-logs-page

Incidentally, if you are hosted with HostGator or another web host that uses cPanel, now would be a good time to make sure you have archiving enabled in cPanel.