GoDaddy’s Managed WordPress Hosting Fails to Provide Important Security Feature

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”:

Keep bad guys at bay Your site gets the personal bodyguard treatment, 24/7. Our security team monitors, thwarts, and deflects so you can rest easy.

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:

Malware scan & removal Hackers can inject malicious code—malware--into your site to steal info or deface your site. With SiteLock Professional Malware scan (included with Ultimate plan), malware’s found and destroyed before it harms you or your customers.

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.

iThemes Security Uses Non-Existent Threat of Brute Force Attacks To Collect Users’ Email Addresses

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”

New! Take your site security to the next level by activating iThemes Brute Force Network Protection. Get Free API Key

If you get click the “Get Free API Key” button in that notice you get shown the following page:

Network Brute Force Protection If one had unlimited time and wanted to try an unlimited number of password combinations to get into your site they eventually would, right? This method of attack, known as a brute force attack, is something that WordPress is acutely susceptible to as, by default, the system doesn't care how many attempts a user makes to login. It will always let you try again. Enabling login limits will ban the host user from attempting to login again after the specified bad login threshold has been reached. Network vs Local Brute Force Protection Local brute force protection looks only at attempts to access your site and bans users per the lockout rules specified locally. Network brute force protection takes this a step further by banning users who have tried to break into other sites from breaking into yours. The network protection will automatically report the IP addresses of failed login attempts to iThemes and will block them for a length of time necessary to protect your site based on the number of other sites that have seen a similar attack. To get started with iThemes Network Brute Force Protection, please supply your email address and save the settings. This will provide this site with an API key and starts the site protection. Email Address test@example.com Receive Email Updates Receive email updates about WordPress Security from iThemes.

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

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.

WordPress.org Support Forum Disappearing Our Replies

As part of the work we do for our Plugin Vulnerabilities service we monitor the WordPress.org support forum for threads about security issues in plugins, to help make sure that we can provide the best data on plugin vulnerabilities to our customers. That also causes us to run across an assortment of related topics. When we can provide some insight we also will reply to threads we run acrros. In the past few days we have been finding some of our recent replies have started to disappear (if you were to go to the relevant threads you wouldn’t even known they had been there) without explanation. We really don’t know why that might be, the more concerning possibility is that they didn’t like that in one thread we had corrected some inaccurate information in regards to the state of handling of plugin vulnerabilities by the Plugin Directory, but since there is no explanation we have no idea what the cause iss. These disappearance don’t just impact us, it has also caused others to be left without useful information.

Take for instances a thread we responded to yesterday. Someone started a thread looking for help identifying an arbitrary file upload vulnerability in some software running on their website. Seeing as arbitrary file upload vulnerabilities are probably the most serious vulnerability out there in plugins, since it is the most likely to be exploited of commonly found vulnerabilities, we thought it would be a good idea to see if we could find any in the plugins they indicated they were using since we would want to make sure that is in the data our Plugin Vulnerabilities service. In checking over the plugins we couldn’t find any of that type of vulnerability.

While we were already looking over things we thought we might as well see if we could take a look at the Suffusion theme they were using as well. The theme used to be available on the wordpress.org Theme Directory, but was removed a month ago. Since it still remains in the underlying repository we were able to get a copy of the last version, 4.4.9, of that and found that was in all likely hood the source of the issue the original poster was having, as the AJAX accessible function suffusion_admin_upload_file() in the theme allows anyone logged to upload files through the WordPress function wp_handle_upload(). That function only allows certain types of files to be uploaded, so it wouldn’t be an arbitrary file upload vulnerability, but the logging included with their post showed that files that were uploaded are types that are allowed by that. Notably the logging included with the post did not show any .php files being uploaded, which is what an arbitrary file upload vulnerability would normally be used to upload. The request for doing the uploads through theme would be handled through a POST request to /wp-admin/admin-ajax.php, several of which are shown in the logging that was included in the post.

We posted reply explaining that and it then quickly disappeared. In the meantime the only other person that responded was a forum moderator, who was sending the original poster off in the wrong direction by telling them to contact their web host about server issues. None of the evidence provided looks to match a server issue to us, so we are not sure why they would suggest that. Making the whole thing more aggravating, after we had already posted what the actual cause was (and then having it disappear) the forum moderator posted that beyond what they told the person about focusing on a server issue, “There is little else anyone can say.”, which clearly isn’t true.

A Good Example of What is Wrong With The Management of the WordPress.org Plugin Directory

Through the work we do for our Plugin Vulnerabilities service we spend a lot of time on the Plugin Directory, dealing with issues in plugins on it (mostly security issues), and interacting with the people running it. Our experience is that things are not really handled well by the people running it. Something we ran across today seems like a good example of the poor state of the people managing it, which we thought would be good to share to help expose the bad state of things.

Since we have several plugins in the Plugin Directory, prior to the release of a new version of WordPress we get an email asking us to test our plugins with compatibility with the new version of WordPress and then update them to indicate they are compatible with the new version. Here is the email we got prior to 4.5 (the plugin listed as only being tested up to 3.6 is due to the fact that the plugin’s functionality was integrated into the next version of WordPress):

Hello, WhiteFirDesign!

WordPress 4.5 is scheduled to be released on April 12. Are your plugins ready?

After testing your plugins and ensuring compatibility, it only takes a few moments to change the readme “Tested up to:” value to 4.5. This information provides peace of mind to users and helps encourage them to update to the latest version.

Here are the current “tested” values for each of your plugins:

* https://wordpress.org/plugins/automatic-plugin-updates/ (tested up to 4.5)
* https://wordpress.org/plugins/https-updates/ (tested up to 3.6)
* https://wordpress.org/plugins/no-longer-in-directory/ (tested up to 4.4)
* https://wordpress.org/plugins/plugin-vulnerabilities/ (tested up to 4.5)

For each plugin that is compatible, you don’t need to release a new version — just change the stable version’s readme value.

Looking to get more familiar with 4.5? Check out this roundup post on the core development blog: https://make.wordpress.org/core/2016/03/30/wordpress-4-5-field-guide/

Thank you for all you do for the WordPress community, and we hope you will enjoy 4.5 as much as we do.
WordPress core contributors

So clearly the Plugin Directory wants people to be testing their plugins for compatibility and then updating the compatibility information.

Based on that you would think that the person described as the “WordPress.org Tech Dude”, who is involved in managing the Plugin Directory, would be setting an example by making sure to do that, but as we noticed today that isn’t the case. For one of their plugins PHP Code Widget, which has 100,000+ active installs, it is still only listed as being compatible up to WordPress 4.4. WordPress 4.5 was released in April and WordPress 4.6 getting closer to release, with the third beta released a week ago.

It isn’t a situation where the plugin is no longer supported, hasn’t been tested, or the developer just forgot to update the compatibility. As a couple of forum threads show, the developer is instead just refusing to update the compatibility listing. If that sounds strange to you, you are no alone, but that is inline with the type of attitude we have seen when dealing with those people.

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.

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.

WordPress Leaks Potentially Sensitive Information From Private Posts and Pages

Over at our Plugin Vulnerabilities service we are in the process of trying to help to get a fairly serious security issue with a WordPress plugin fixed. In the process of doing that we have noticed an issue with WordPress that impacts more than this plugin. Without getting into the details of it, since a fix is still in progress, the plugin created WordPress pages which provide access to non-public data. These were accessible by the public, which was a problem. As part of trying to fix this, these pages were intended to be made private (we say intended because that wasn’t done right). This would have worked in private pages were totally private, but it turns on they are not.

Here is how the WordPress documentation describes what the impact of setting a post’s or page’s visibility to private:

Private content is published only for your eyes, or the eyes of only those with authorization permission levels to see private content. Normal users and visitors will not be aware of private content. It will not appear in the article lists. If a visitor were to guess the URL for your private post, they would still not be able to see your content. You will only see the private content when you are logged into your WordPress blog.

Despite the claim that “normal users and visitors will not be aware of private content”, that isn’t totally true. If you have your permalink structure set to include the title of the page in it, which is fairly common set up, then someone can find out the titles of private posts and pages.

You do that by taking advantage of WordPress’ automatic redirection from plain URLs to the chosen permalink structure. Lets say a post with ID number 12 was titled Surprise Party For Julie In Accounting, when accessing

WordPress Releases Version 2.6

WordPress to automatically redirects you to

http://example.com/surprise-party-for-julie-in-accounting/

The page you see though gives no indication that a private page exists, as the documentation suggest:

Oops! That page can’t be found. It looks like nothing was found at this location. Maybe try a search?  Search for:

By enumerating through potential ID numbers you can see what the titles of all private posts and pages on a website are.

Coming back to the plugin, the title of those pages contains enough information to allow some access the non-public data. While the plugin shouldn’t have you used pages in the way it did, we suspect that in other cases private posts or pages could also contain sensitive information in the title that isn’t meant to be public, as it is now.

After noticing this we thought that we should bring this to the attention of the WordPress developers since it doesn’t seem like this should be this way. It turns out that someone already did that 8 years ago, back around the time of WordPress 2.3.1. But 7 years ago that ticket was closed and marked as “wontfix”. Maybe there was some good reason for that, but the only comment included with that change was “there’s a dup of this one somewhere, and it shoud get wontfixed too.” The fact that a potential security issue was treated in this way is more than a little concerning.

Why Does The WordPress Plugin Directory Have Rules If They Don’t Bother To Enforce Them?

When it comes to distribution platforms for software one of the frequent complaints of developers is uneven enforcement of rules and regulations, which makes it hard to know what is and isn’t acceptable. Recently we came across an example of this with Plugin Directory for WordPress:

While dealing with one of the vulnerabilities we recently discovered through our Plugin Vulnerabilities service, we were have a bit of issue discussing communicating about the issue since it turned out the plugin had two names.

On the Installed Plugins pages in WordPress it is referred to as Spider Event Calendar:

spider-event-calendar-on-installed-plugins-page

On the Plugin Directory its name is WordPress Event Calendar:

wordpress-event-calendar-on-plugin-directory

Okay, actually while the main name is WordPress Event Calendar, you can see that it is referred to by both names in different places:

wordpress-event-calendar-on-plugin-directory-full

It is confusing to say the least and it seems like restricting a plugin to one name would be reasonable thing to do, but what seem to be the bigger issue here was with the fact that using the word WordPress in a plugin’s name is supposed to be against the rules of the Plugin Directory.

On the Detailed Plugin Guidelines page it says:

Don’t violate our trademarks. Don’t use “wordpress” in your domain name. Use “wp” instead, or better yet, come up with your own original branding! People remember names.

On the Developer FAQ page it is put a lot more clearly:

Are there names you don’t permit?

We don’t allow ‘WordPress’ in plugin names as it’s redundant and somewhat obvious that you’re a WordPress plugin.

A little more looking showed that the same developer had six plugins with WordPress in the name:

webdorado-wordpress-plugins

All six of those plugins have associated paid plugins.

search of the Plugin Directory shows that these are far from the only ones using WordPress in the name of plugins:

plugin-directory-search-results-for-wordpress

It certainly seems like the Plugin Directory is allowing the word WordPress to be used since it is in such wide use and it would be easy to detect its usage in the name of the plugins when getting the name of the plugins from their files to show it in the Plugin Directory. If this is the case then the documentation should be updated, otherwise we have just provided the people running the Plugin Directory with an easy way to find a lot plugins that they need to do something about.