16 Nov

No Ninja Forms, Wordfence Security is Not Trustworthy and Blacklisting IP Addresses Doesn’t Provide Effective Protection

When it comes to choosing security products and services what is lacking is nearly any evidence that they are effective, while at the same time there is plenty that shows that many of them are not. For example, over at our main business we regularly have people asking if we offer one that will really protect their website from being hacked after the one they were using didn’t prevent their website from being hacked. So why would people being using those if there isn’t evidence that they work? One of the reasons we have heard from people we have dealt with that have had their websites hacked is that they are using products and services based on recommendation of others. Since those are not going to be based on evidence, since there is a dearth of that, not surprisingly a lot of that advice is quite bad. Take as an example of that bad advice, the most recent post on the blog of the Ninja Forms plugin, which is used on 1+ million websites. We ran across that while looking if they had released a post on the vulnerability fixed a couple of days ago, when were detailing that.

Right off the bat the post, 5 WordPress Security Plugins to Keep You Safe, puts forward the proposition that the Wordfence Security plugin is trustworthy, which seems to be disputed by reality. The post claims the Wordfence Security plugin is “one of the most trusted security plugins for WordPress”. They provide no evidence that it is trusted at all, much less one of the most trusted. Maybe by that they mean that it is tied for most popular and therefore it is trusted due to that, but that doesn’t mean it actually works at all or should be trusted (the security plugin it is tied for most popular with currently contains a vulnerability and is not needed). Near the end of their discussion of the plugin they again refer to it as “trustworthy”.

Considering that the company behind the plugin, Defiant and their employees, lie all the time, trustworthy isn’t a word we would use with their plugin. From claiming that the plugin provides data that it doesn’t, to having promoted it with an unqualified claim that “stops you from getting hacked” despite their employees knowing that isn’t true, to just last week lying that their related paid service, Wordfence Premium, had you “covered” with a vulnerability, when in fact it didn’t. We could go on from there, but that seems like more serious lies then should possibly be coming from a security company.

The post also mentions this about their plugin and Wordfence Premium service:

In addition to keeping you safe at the source, Wordfence also keeps an up to date list of black listed IP addresses that will be halted before they ever reach your site. For free users this list is automatically updated every 30 days, but there is a premium version that updates immediately.

As we just mentioned their Wordfence Premium service failed to protect websites using it just last week even with that IP address blacklisting in place. That isn’t surprising since what we have seen is that hackers have access to and use numerous IP addresses (some use a different IP address for each request they send to a website), so IP address blacklisting would likely have serious limits at best, but you need to be able to detect that malicious activity is coming from an IP address to blacklist them and for that you would have to be keeping up with the threats out there and Wordfence doesn’t do a good job (hence the website being hacked last week), so it likely to be even worse. Data that is 30 days out of date is likely going to be even less useful.

The problems go on from there, as for example, the post touts the second plugin listed as “a great tool to prevent brute force attacks on your site”, which are not actually even happening.

What helps to explain the quality of the advice is the author of the post “is an English teacher and content writer for WP Ninjas”, which isn’t exactly an indication of someone that has much security experience. Unfortunately many people feel they should be handing out security advice without have the necessary expertise to do that or relying on evidence based advice from others to come up with recommendations.

What we would advise when looking for a broad based security product or service is evidence, preferably from independent testing, that it works because otherwise you are likely not going to be using something that really works. When it comes to products and services that provide something specific functionality, you should look for evidence that what that provides is actually something you need.

15 Nov

Detectify is Eight Months Behind Detecting Vulnerability in WordPress Plugin With 2+ Millions Installs

For us providing the best data on vulnerabilities in WordPress plugins is important, but we could easily being doing that even if we were doing much less than we do currently, but even with that we continue to work to improve and find ways to gather data on more vulnerabilities. As an example of how far ahead we are, take blog post from today from the security service Detectify.

The post starts out with this:

For continuous coverage, we push out major Detectify security updates every two weeks, keeping our tool up-to-date with new findings, features and improvements sourced from our security researchers and Crowdsource ethical hacker community. Due to confidentially agreements, we cannot publicize all security update releases here but they are immediately added to our scanner and available to all users. This post highlights a few things that we have improved in the last two weeks.

Considering that a vulnerability in a WordPress plugin was widely exploited a day after it was fixed last week, having updates every two weeks is much too slow. By comparison we continuously update our data and when you use our service you website is checked against our data as often as every hour.

It then goes on:

The following are some of the security vulnerabilities reported by Detectify Crowdsource ethical hackers. We added these tests to the Detectify scanner tool on 15 November.

Their service starts at $60 a month (which is much more than ours) and yet they are relying on crowdsourcing to keep up with vulnerabilities, which clearly produces poor results, considering the first vulnerability listed after that is:

WordPress limit-login-attempts XSS
This WordPress plugin logs the IP-address of users that has multiple failed login attempts. However, in place of recording the actual IP-address, it is possible to log the value of the X-Forwarded-For-header instead.

When the administrator of the WordPress installation later logs into the dashboard the log is visible to them without proper filtering. This means that it is possible to use an XSS-payload as header value. Additional reading.

If you follow the link in that post you find it is link to our post about the vulnerability from March 9th. So they are 8 months behind us in detecting this issue in a plugin with 2+ million installs, according to wordpress.org.

Making that worse, at least in their explanation in the blog post, they are missing the important qualification that this vulnerability is only exploitable if you changed one of the plugin’s default settings, so probably most of the websites using this plugin are not currently at any risk. Between March and today we have added numerous vulnerabilities that are much more likely to be a serious security risk, which it would seem they probably don’t have in their data set considering the haven’t mentioned those.

At the end of the post they tout how many vulnerabilities they check for:

Detectify is a continuous web scanner monitor service that can be set up for automated scanning for 1000+ known vulnerabilities including the OWASP Top 10.

Probably not surprisingly considering they are adding something we have had for 8 months, we have significantly more vulnerabilities in our data set and we just are focused on WordPress plugins, while they are supposed to be handling all types of websites so even if there data on WordPress plugin vulnerabilities is shallower they should have more vulnerabilities.

14 Nov

The Need and Limits of Warning That Closed WordPress Plugins Contain Security Vulnerabilities

Earlier today we full disclosed that a WordPress theme contains a vulnerability due to its inclusion of the plugin OptionTree, which we had full disclosed contained the same vulnerability last week. That plugin was removed from the Plugin Directory after the disclosure (though strangely that hasn’t happened with a security plugin that has the same type of vulnerability that we disclosed yesterday, so who knows what is going on the WordPress side of things). As we noted in the post earlier today, it looks like other themes have, at least in the past, also included the plugin as part of their code. What we have also now run across is that other themes have been separately installing it. With it removed from the Plugin Directory that doesn’t work anymore.

If those theme developers go to the Plugin Directory they wouldn’t know it was removed due to a security vulnerability as the only information given is:

This plugin was closed on November 6, 2018 and is no longer available for download.

The problem with that is that removing it won’t stop them from trying to use it, as a topic, Older themes still required OptionTree, on the support forum of the plugin started yesterday indicates. Here is the relevant part of the original post:

We are using Option Tree plugin in some of our older themes. The install is made via WordPress repository. Now, since the plugin is no longer available, install of it is unavailable. What could be the easiest solution? Is there an option to access the latest version in repo?

In response someone else pointed out where else it can be obtained:

You can still get the latest version on the github repo: https://github.com/valendesigns/option-tree, and include it in the theme package then use the TGMPA script for the installation process.

It seems the plugin has been discontinued for a long time and the chance for further development is very slim. I think we need to find an alternative to it.

What is important to note here is that just telling people that it has a vulnerability isn’t necessarily going to stop them from using it.

The Twitter account for the party that responded there about where to obtain it tweeted this the day after the plugin was removed:

The response to that from the developer of the plugin indicated it has a vulnerability:

Five days later that theme developer indicated they were going to being including the plugin, which they now knew to be vulnerable, in their themes for the time being:

That seems like a good reason to repost part of post from earlier today:

We have added a check to our Plugin Security Checker that will flag the inclusion vulnerable versions of OptionTree in another plugin. While that tool is designed for plugins, if you are a customer of our service you can upload plugins not in the Plugin Directory to check those and that same capability can also be used to check themes. While looking into adding that check to the tool we found that at least a couple of commercial themes have at least in the past included it as well, so you may want to manually check themes for that inclusion of that plugin or run them through the tool, where it could also identify possible other security issues in the themes.

What can be done about people that are going to distribute to others software they know is vulnerable is something we don’t have a good answer for. Making sure that plugin vulnerabilities are fixed if the developer isn’t around would be one answer. We have offered to do that for vulnerabilities that are likely to be exploited on the average website, but doing that for every vulnerability would be quite a task.

09 Nov

Wordfence Security and Wordfence Premium Fail To Protect Websites, But Defiant Is Happy to Lie and Tell You Otherwise

Over at our main business we have a steady stream of people contacting us to ask if we offer a service that will stop their websites from being hacked, a not insignificant number of them mention that they are currently using a service that claimed to do that and there website got hacked anyway. That second item obviously tells you that these service don’t necessarily work, but what seems more relevant to the poor state of security is that even when one of these doesn’t work these people are often sure that they can and do work, just the one they used didn’t. That probably goes a long way to explaining why the complete lack of evidence that these services are effective at all hasn’t been an impediment to people using them. The problem with that is not only do they end up not working well or at all, but the money spent on them could have been spent on services that actually improve security of these websites (and everyone else’s website if there services is anything like ours), but are not sold on false promises.

Seeing as there are lots of people that still haven’t gotten the message about these services should be avoided if there isn’t evidence that shows effectiveness, we thought it would be worth emphasizing and expanding on something we mentioned in a post yesterday where websites could have been protected by doing one of the basics of security, keeping WordPress plugins up to date, while a security service failed to protect them while being promoted as being able to do that.

Defiant Against the Truth?

The current state of the security rewards unscrupulous companies and individuals that have no qualms about misleading and outright lying to the public to sell their products and services. In the WordPress security field there are plenty of companies and individuals that would fit that bill, but probably the most prominent WordPress focused one would be the company and people behind the Wordfence Security plugin. Nearly two years ago we ran across the head of that company, Defiant, making this claim on a Reddit thread:

I’d say about 2 years ago I would not have been comfortable running WordPress even with Wordfence on a mission critical site where data theft is a disaster.

Today that has changed and there is one thing that changed it: Our firewall. Back when I wrote and launched the code for Wordfence myself (in 2011) we didn’t even have a firewall. We launched a full blown firewall some time ago and it’s now evolved to the point where I’m completely confident that if you install our firewall and are running WordPress, you are going to be much more secure than if you’re running an alternative product, even if that alternative CMS is behind a firewall.

We then responded pointing out that the real world results did not match their claimed belief in what they provide:

We have been testing security plugins against real plugin vulnerabilities over at our Plugin Vulnerabilities service and the results have not been good when it comes to your plugin or any other security plugin.

The latest test involved a vulnerability in the plugin Delete All Comments that was discovered by the makers of NinjaFirewall while they were cleaning up a hacked website. This vulnerability hasn’t been fixed, so keeping plugins up to date won’t protect against it and therefore a security plugin could provide some real value. Unfortunately, none of the 15 plugins we tested, including Wordfence, prevented it from being exploited.

In the other three tests we found that your plugin provided no protection or was the protection was easily bypassed. Most of the tested plugins have provided no protection in any of the test and in only one test did a plugin, NinjaFirewall, provide protection that wasn’t easily bypassed. The protection it provided came with the tradeoff that Editor-level and below users are unable to upload media.

We also did two previous one off test with your plugin and it didn’t prevent exploitation in either case.

You might think that would cause that person to get to work improving their offering, but that person being who they are, just lied through their teeth. Somehow our specific testing was knocked down to “generalizations”:

Lots of generalizations in the above post. If you have any other specific issues/exploits/bypasses that are current, I’d love to hear about them. As you can see, the team responds very quickly.

The lies were turned up with a popular plugin with a widely exploited vulnerability that they only became aware days after wide exploitation had happened, but to hear them the story was very different:

We developed a firewall rule for that exploit and released it into production on December 16th, the moment we heard about it from our users. That’s a screenshot from our internal Slack. It’s a fun read – shows what a great place Wordfence is to work.

The rule is now in production for Wordfence Premium. It will only be available in the free Threat Defense Feed 30 days after release, so around Jan 15th.

FYI, that plugin was pulled from the repository and is no longer available. It wasn’t very popular when it was in the repo.

We deploy rules for vulnerabilities and their exploits the moment we hear about them or see them exploited in the wild. That just wasn’t a widely exploited vulnerability or a popular plugin. In the case of the vulnerability above, we heard about it because you were making some noise about it. Our users alerted us.

As one example of how ridiculous that was the plugin was actually popular by their own metrics:

As of a month ago, it had 30,000+ active installs according to wordpress.org. That seems to be popular to us. It also does to WordPress, as the Popular section the of Plugin Directory currently includes plugins with as little as 10,000+ active installs. In November of last year you also considered that be enough to be popular. In your post New Vulnerabilities in 6 Popular WordPress Plugins, one of those 6 popular plugins had 30,000+ active installs. In fact one of the popular plugins only had 2,000+ active installs. So either you have radically changed your view of what is popular in 13 months or your view changes to fit the narrative you want to present at the moment.

In are later testing either their protection against that vulnerability it didn’t work or it didn’t actually exist, at least if you were not paying for their Wordfence Premium service.

Two Years Later Things Haven’t Changed

Yesterday as a vulnerability in the plugin WP GDPR Compliance started being exploited, another Defiant employee made this claim:

So was that true?

In another thread on Reddit someone that was hacked due to this vulnerability described the result of that:

Over the last few hours we have had a slew of registrations using the email address trollherten@mail.com which show up with Administrator access. This was across 3 sites for the same client. This email address has shown up on cleantalkrecently as well.
Has anyone else experienced this or know of a security issue? These sites do share a few plugins:
Feed them social
Gravity forms
Really simple SSL
WP GDPR Compliance
The core, themes and plugins are all up to date. Anyone else having this issue?

In response someone asked if anyone impacted was using Wordfence:

Anybody with wordfence installed and its firewall configured get p0wned?

The original poster responded that they were using Worfence Premium and it didn’t protect them:

Yo. WordFence Premium and Firewall enabled.

So what happened? It is quite simple, Defiant only even claims to have added protection after the widespread exploitation happened (whether their protection is effective is an open question without independent testing), which is too late:

Leaving Wordfence Security Users To Be Hacked

Coming back to head of Defiant, he had the following response to someone that was using Wordfence and got hacked due to this vulnerability:

How releasing protection after websites have already been hacked is supposed to mitigate against that is a mystery to us.

It gets worse though, if you look at the post cited in the tweet it reads (emphasis ours):

At this time, the Wordfence Threat Intelligence team has released a new firewall rule preventing exploitation of this flaw for all premium users. Users of the free version of Wordfence will receive the new rule following a thirty-day delay, but as always they can protect themselves by updating their site’s plugins.

Considering that the vulnerability was already widely exploited before they even had protection in place, the free protection after thirty days seems worse than useless, since people will hear that Wordfence Security provides protection against numerous vulnerabilities, but could easily be unaware that they are not protected when it actually matters. At that point Wordfence is there to sell them a clean up service, which they shouldn’t have needed if they were doing the basics.

Updating Provides Better Protection

The last part of that previous quote seems to be the most important element of this since while website using Wordfence Security and Wordfence Premium would have been hacked, websites that simply had plugins update automatically would have been protected since the vulnerability was fixed before the exploitation started. We used to provide a plugin that did just that, but WordPress removed that as part of their efforts against improving security.

In this instance using our service could have provided even better protection since we started warning our customers that the plugin was vulnerable before the new version was easily upgraded to (since the new version had been released, but the plugin was closed on the Plugin Directory) and could have help them to upgrade to that version. Or once it was easily upgraded, they would have already known that there was a vulnerability that had been fixed that had a high likelihood of exploitation.

08 Nov

Unlike Wordfence and Other Security Providers We Warned About WP GDPR Compliance Before Websites Started to Get Hacked

When it comes to protecting WordPress websites against vulnerabilities in plugins we provide a level of protection that others don’t for the simple reason that we do the work they don’t (but that they absolutely should be doing). The result can be seen with the plugin WP GDPR Compliance, which had multiple vulnerabilities fixed in version 1.4.3.

We had been warning our customers of one of those before you could even normally upgrade to that version of the plugin as the plugin was closed at the time (we warned our customers that it was at high likelihood of exploitation). At that time we could have help our customers to upgrade to 1.4.3 and then shortly after we started warning them the plugin was re-opened and they could upgrade normally. That all occurred yesterday.

If you had been using our service or simply had plugins update automatically, something we suggest doing and even created a plugin to make easy to do, you would have been protected from what looks to be a large scale exploitation of another one of the vulnerabilities that started today. We could have also warned people that were not our customers if WordPress hadn’t gotten in the way of us doing that.

Other providers are now belatedly warning people after their websites likely have already been hacked, which looks in large part about promoting themselves to deal with the after effects of that instead of providing a useful resource. In looking over their tweets and posts we haven’t seen any contrition for being late to the warn about this and failing their customers or what steps they are going to take to prevent that from happening again (considering this is far from the first time that should have happened long ago for many of them).

What seems to be the worst example of that is with the company behind the plugin Wordfence Security. Here for example is a tweet from one of their employees:

Users of the Wordfence Premium service actually were not covered, because as tweet from another employee shows they added protection after the fact:

It is galling to see members of the security industry mislead people in this way, but that is unfortunately par for the course.

If a Reddit thread is to be believed you have at least one of the users of Wordfence Premium that got hacked despite using the service and there likely are more if other users of their service also used that plugin.

Being late to this isn’t how the Wordfence Premium service is promoted, instead they promote their Real-Time Threat Defense Feed that is part of that this way:

Wordfence protects over 2 million WordPress websites, giving us unmatched access to information about how hackers compromise sites, where attacks originate from and the malicious code they leave behind. The team in our Forensic Lab are constantly adding updates as they discover new threats. Premium members receive the real-time version of the Threat Defense Feed. Free users receive the community version, which is delayed by 30 days.

In this case though they were behind us, not because we have more advanced tools, but because we do the basics. From what we have seen it doesn’t appear they do what they claim to be doing there because they are consistently behind or missing things, even things that they could have known about by just following our blog.

What is also important in that is that they leave people relying on just their plugin and not their paid service vulnerable for thirty days, “Free users receive the community version, which is delayed by 30 days.”, which as this situation shows is over 30 days after it probably matters. By comparison before WordPress got in the way, we always warned users of companion plugin about exploited vulnerabilities even if they didn’t use our service since we don’t want websites to be hacked. If you look at their post cited in those tweets there is an unfortunate possible explanation for that at the end of it:

If you believe your site has been impacted by this vulnerability, please do not hesitate to reach out to our site cleaning team to begin the remediation process.

So if they can’t get you to pay for one service maybe they can get you to pay for another (or even both since they didn’t provide protection to those using Wordfence Premium until after the exploitation started).

Make Sure You Keep Your Plugins Up to Date At All Times

Also in Wordfence’s post cited in those tweets they twice belated tell people to update the plugin:

Any sites making use of this plugin should make it an immediate priority to update to the latest version, or deactivate and remove it if updates are not possible.

It is of critical importance that any site using this plugin performs the update as soon as possible.

What they should have told people is that you need to be keeping all of your plugins up to date at all times, since belated updating them after Wordfence warns you about a vulnerability doesn’t work.

Cleaning Up Hacks

Since we mentioned that they are marketing cleanups we should mention that if you have been hacked due to this and need someone to clean it up we provide a better option than other providers, not just because unlike so many other companies we properly clean up hacked websites, but you get a free lifetime subscription to our service, so you wouldn’t have to be belated notified of such a situation in the future.

07 Nov

RIPS Technologies and BleepingComputer Creator Claim That Plugin’s Functionality Not Working When Disabled is WordPress “Design Flaw”

We generally avoid security journalism as it frequently involves widely misleading to flat-out falsehoods, one example of that being something we discussed just a couple of weeks ago. One of the security journalism outlets we mentioned in that post was the BleepingComputer, so when a Google news alert let us know of another story related to the security of WordPress plugins from them it wasn’t surprising that it might not be totally accurate. The title of the story is WordPress Design Flaw + WooCommerce Vulnerability Leads to Site Takeover, though there doesn’t appear to be a design flaw in WordPress or a site takeover that actually occurred.

The “design flaw” is first described as one with the “WordPress permission system” and then as:

The flaw with WordPress plugin/privilege system is that if the WooCommerce plugin is disabled, the function that limits what users a Shop Manager can edit is no longer accessible and thus Shop managers can edit users in the Administrator role.

We don’t understand how it is WordPress design flaw that if a plugin is disabled its functionality doesn’t work, what it actually sounds like is that the design of the plugin is flawed, but that wouldn’t draw as much attention.

It is important to note that this claim isn’t actually an original thought of the writer of the article, Lawrence Abrams, who is the “creator and owner of BleepingComputer.com”. Instead he has simply repeated the claim from the security company Rips Technologies. That seems like a bad idea since they are known to make widely overstated claims.

The supposed design flaw is also out-front in Rips Technologies’ post, as it is titled “WordPress Design Flaw Leads to WooCommerce RCE“. The claim is much same in that:

The Design Flaw

While these filters work, they only get executed when the plugin is active. The issue is that user roles get stored in the database and exist even if the plugin is disabled. This means that if WooCommerce was disabled for some reason, the meta privilege check which restricts shop managers from editing administrators would not execute and the default behavior of allowing users with edit_users to edit any user, even administrators, would occur. This would allow shop managers to update the password of the admin account and then take over the entire site.

Again this doesn’t sound like a WordPress design flaw. User roles do not have to be tied to a plugin, so what is happening there seems to be WordPress working correctly and a plugin is designed in a way that doesn’t appear to be fully thought out. If you want to add a capability in a way that only works with a plugin enabled there is a WordPress filter for doing that, which according to the documentation has existed since WordPress 2.0.0, which was released nearly 13 years ago.

So how about the “site takeover” element? Well for that to be possible you would have to have access to a fairly privileged account, though Rips Technologies describes that as if it is not actually a big deal to get access to that:

No other requirements other than an attacker being in control of an account with the user role shop manager were required. Shop managers are employees of the store that can manage orders, products and customers. Such access could be obtained via XSS vulnerabilities or phishing attacks.

A malicious actor that has control of a shop manager account could do a lot just with the ability to “manage orders, products and customers”.

Neither Bleeping Computer or Rips Technologies make a claim that any website was taken over through this.

Based on the previous instance of bad journalism mentioned at the beginning of this post, it is seem likely other journalist will run with these misleading claims soon.

05 Nov

More of WordPress Support Forum Moderator Jan Dembowski’s Bizarre Handling of People Trying to Deal With Closed Plugins

In protest of the continued inappropriate behavior by the moderators of the WordPress Support Forum just over a month ago we started full disclosing vulnerabilities until the moderation is cleaned up, so far it hasn’t caused them to change their behavior (apparently continuing to act inappropriately is the only thing they seem to care about considering they haven’t even bothered to notify the developers of those vulnerabilities). In the meantime we have continued to run into more examples of them bizarrely getting in the way of the WordPress community.

With one of the moderators we have had run-ins with them acting bizarrely, named Jan Dembowski, we haven’t been alone.

A couple of weeks ago we discussed one instance of that were they stopped any discussion of why a plugin was closed from being possible and claimed that it somehow wasn’t a support issue to ask about why the plugin was closed (you really have to wonder if they think at all about what they are saying).

Last week we detailed a vulnerability that might be related to the closure of the plugin AMP for WP – Accelerated Mobile Pages. Not surprisingly someone started a topic about the plugin’s closure, which at the time of our post hadn’t been closed and another moderator even had participated in it, which is a reminder of the complete lack of any consistency in the moderation (subsequently it was closed and replies just saying thank you were deleted). After that, not all that surprisingly either, the developer put up a pinned topic to explain what was going on, which seems like a good idea to avoid numerous topics started on the closure. That brings us back to Jan Dembowski as they closed that topic and left this message:

I am closing this topic. The support forum is not your bulletin board, it is not your blog. If you wish to send users to your site for your updates then feel free to do so.

That is just head-scratching. It isn’t clear why in general a moderator feels the need to micromanage everything like that person does, but they seem to have no understanding of what the people actually using the support forums for plugins are using them for.

Further proof of that comes from topic started in response to the previous one being closed:

Hi Ahmed, unfortunately your sticky topic regarding the suspension of this plugin has been closed by a keen amateur volunteer. I appreciate you were aiming to update that thread when the plugin is re-released, but thanks to their unhelpful intervention you can no longer do so, nor can you tell us where to seek further information. Please let us know via this thread where we can seek ongoing updates.

In a case of more “unhelpful intervention” that topic itself was closed as well.

That moderator also seems to have obsession with classifying messages as blog posts. Here was part of a response to a review for Gutenberg we happen to run across recently:

OK, I was hoping to not but I am closing this review. The review will stand but here’s the thing about reviews.

The reviews on this site for any theme or plugin is not a blog post. These are not discussion forums. All the reviews here are about a user’s experience with that theme or plugin.

It is worth noting that that plugin reviews not only are part of the Support Forum system, but anyone can reply to reviews, so claiming they are not discussion forums seems disconnected to how things are designed. If they are intended to be different it seems it would better to change how they are set up instead of having moderators micromanage the WordPress community like this.

05 Nov

The WordPress Forum Moderators Keep Bizarrely Deleting Replies Just Saying Thank You

Where we first saw indications that something was very amiss with the moderation of the WordPress Support Forum was when a reply from someone just thanking us for answering a question they had, was deleted. It didn’t make any sense to delete that and went against what people were being told as to the limited circumstances that things would be deleted from the forum:

When a post is made and people contribute answers to an issue, that then becomes part of the community resource for others to benefit from. Deleting posts removes this added value. Forum topics will only be edited or deleted if they represent a valid legal, security, or safety concern.

In reality the moderators delete things all the time and delete things where there seems to be no good reason to do that.

More recently the person who is in charge of moderators and apparently selecting most of them, Samuel Wood (Otto), claimed this:

We don’t remove words from the forums because people disagree, but we do remove those words that do not belong in a polite and decent community.

That sounds odd coming from him considering he is someone that others in the WordPress community don’t think is able to act in a “polite and decent” way in the Support Forum, take this comment in response to something he said on the forum:

Some people, no matter how long they’ve been in the project or how important stuff they gave to it, should never be allowed to answer reviews in .org. They lack the minimal sensitivity to understand and speak to a human. I’m not saying they aren’t great, I’m just saying they aren’t fit for it. Therefore, they shouldn’t be there, where you have to understand a lot of different people, with different troubles using which, for some, are essential and at the same time complex tools to master.

That he appears to be oblivious that he might be the kind of person that in his own view shouldn’t have their words allowed there, seems like it goes a long way to explain the mess that is the moderation, seeing as he is largely in charge of it.

Getting back to people saying thank you have their replies deleted, we just ran into an instance where multiple replies with people just saying thank you were deleted. Those replies seems like they would be part of a “polite and decent community” (though maybe not in the bizarro world of the moderators).

Last week we mentioned a topic discussing a plugin that had been closed on the Plugin Directory, when we went back to topic to look at something it seemed like there were replies missing. In fact there were, as there is an archived copy of that topic from Wednesday where there were ten replies instead of the three now showing. It is rather obvious looking at what is there now that replies were deleted since there are multiple references to users where there is no reply from that person anymore.

Among the replies deleted is this

Thanks for update @ampforwp

And this:

Thanks. Looking forward to the update

What in the world could be the legitimate (or even illegitimate) purpose of deleting those?

05 Nov

It Looks Like Hackers Have Started Probing For Usage of AMP for WP – Accelerated Mobile Pages

A week ago we put out a Vulnerability Details posts with the details of a vulnerability in the plugin AMP for WP – Accelerated Mobile Pages, which had been closed on the Plugin Directory recently, so if you were already customer of our service and using that plugin you would have been warned about that particular issue, as well as the general poor security of the most recently released version of the plugin. It looks like hackers are aware of that as well now, as yesterday we had a series of requests requesting files from the plugin that looked to be probing for usage of it:

  • /wp-content/plugins/accelerated-mobile-pages/readme.txt
  • /wp-content/plugins/accelerated-mobile-pages/README.md
  • /wp-content/plugins/accelerated-mobile-pages/templates/custom-amp-content-
  • button.js
  • /wp-content/plugins/accelerated-mobile-pages/languages/how-to-use-a-pot-file.txt
  • /wp-content/plugins/accelerated-mobile-pages/LICENSE

The series of requests came from web servers in several different locations around the world and from Chinese telecom providers.

According to data from abuseipdb.com, others had requests of the same type several days before.

As of right now the plugin still is closed on the Plugin Directory (it has been closed on October 21), so people cannot use the normal upgrade process to get to a more secure version (we can help our customer upgrading to the unreleased version that fixes the issues).

From the changes made to the plugin since it was removed, it looks like this is an example of the poor handling of security by the team behind the Plugin Directory team as instead of being focused on working with the developer to get the serious fixed as soon as possible (and possibly avoiding removing it at all if they could get it promptly fixed, to avoid spotlighting the issue) and focusing on security improvements later, they are holding back those serious fixes, at time when hackers are already moving forward. That isn’t a new issue and it is the kind of thing that could be corrected if the team was open to working with others, like us, that could help them to make the process better and lead to better security for the WordPress community, unfortunately things like the inappropriate behavior of the WordPress Support Forum moderators allow them to get away with causing unnecessary security headaches for the WordPress community.

Until such time that things get cleaned up on the WordPress side of things our services continue to be important way to protect you and or your customers from insecure plugins, especially since unlike this one, many haven’t been removed from the Plugin Directory despite having vulnerabilities that are already publicly disclosed (those plugins have over 5 million installs). In addition to our main service we now also provide weekly and daily newsletters that provide access to the underlying data that is tapped into with the main service. We think those newsletters could be a better option for larger providers over setting up our service for individual websites (though for someone with say 10s of websites, the main service is much better option).

02 Nov

With a Source Like This It is No Wonder Security Journalism Is Making WordPress Websites Less Secure

Recently an instance of security journalism received a significant spotlight and significant pushback. Bloomberg claimed that a malicious chip had been found in servers used by Apple and Amazon, which both Apple and Amazon categorically denied. Either there is a significant cover up or Bloomberg got things very wrong. The latter possibility wouldn’t surprise us since from what we have seen over the years security journalism is filled with inaccurate and outright false claims, much of that coming from people in the security industry that either don’t know what they are talking about or are intentionally spreading false information. Security journalists seem to not be interested in avoiding that.

Last week we discussed a situation where security journalists were spreading false information due in part to relying on a single source that didn’t really know what he was talking about. Since then, we had an interaction with that source that made it clear that they are not a source that should be relied on alone (or maybe at all) as these journalists had done and that seems to be a good example of why security journalism is in such bad shape, which in turn is actually making WordPress websites (and websites in general) less secure.

The source for their stories was Larry Cashdollar, a security researcher for Akamai’s SIRT (Security Intelligence Response Team). As we noted in the previous post, what we had seen in the past is that he doesn’t always provide accurate information. Specifically we noted a recent situation where he had claimed that vulnerabilities in a WordPress plugin had been fixed when they hadn’t. At the time of his disclosure we tried to notify him of that on Twitter:

It was until last week that he responded:

The follow up to that sounds like a reasonable explanation as to what happened:

We have seen situations in the past were developers had done just, so it sounds reasonable, but in reality it is totally false, which could easily be checked on since all changes made to WordPress plugins in the Plugin Directory are easily accessible through the underlying Subversion repository.

Here is how CVE-2018-1002002 was listed in his report:


<div><label><?php _e(‘Filter by email’, ‘broadfast’)?>:</label> <input type=”text” name=”filter_email” value=”<?php echo @$_GET[‘filter_email’]?>”></div>

That code outputs the value user input, in the form of the GET input “filter_email”, without escaping it, which is a reflected cross-site scripting (XSS) vulnerability.

In version 2.5.15 the code is exactly the same:

<div><label><?php _e(‘Filter by email’, ‘broadfast’)?>:</label> <input type=”text” name=”filter_email” value=”<?php echo @$_GET[‘filter_email’]?>“></div>

After we contacted the developer about the lack of a fix they released version 2.5.17, which fixed the vulnerability by escaping the value:

<div><label><?php _e(‘Filter by email’, ‘broadfast’)?>:</label> <input type=”text” name=”filter_email” value=”<?php echo esc_attr(@$_GET[‘filter_email’])?>”></div>

No change was made to that code in version 2.5.18.

After we tried to explain that to him, Larry he responded with this:

That simply isn’t true.

So what explain all this, the explanation is supposed to be the following:

From our interaction with the developer it was quite clear they didn’t understand at all was at issue, so relying on them would have been a bad idea. Developers of plugins with vulnerabilities often don’t have a good understanding of what is at issue and incorrectly believe they have fixed issue that they haven’t fairly often. That is why it is important for the discoverer of vulnerabilities to check to make sure things have been fixed, which is why we contacted Larry in the first place. What seems the most problematic with that is that he did not indicate that he didn’t know if the vulnerabilities were actually fixed in his report, instead it just states “Fixed v2.5.1.5”.

We don’t know what the Plugin Directory team actually told Larry, but at best Larry is repeating claims made by others without indicating that he is doing that and without much concern if they were true. That he doesn’t seem to have much concern for the truth seems problematic in general, much less someone working in the job he does. Where it gets more problematic is when a bunch of journalists rely on him as their sole source for their stories, where we would assume that they believed that he would be telling the truth.

The outlets that relied on him as their sole source for the issue we discussed last week included Bleeping ComputerNaked Security, The Register, SC Media, ThreatPost and ZDNet.

It seems as though at least one of the journalists involved in this doesn’t even understand what sources are, as the author of the Threatpost post, Tara Seals , responded to our comment on her post in part with this:

Hi again! Here is the response that Larry Cashdollar gave me: “It’s not a sole source. The author of Blueimp and I verified it.

How her sole source saying he isn’t the sole source for the article is supposed to make sense is not something we could follow (the author the software discussed was not even mentioned in the story, much less quoted).

Considering that she works for a news outlet that somehow promoted itself in the same sentence as “an independent news site” and the “Kaspersky Lab security news service” (Kaspersky Lab being a security company), they may not really be big on journalistic standards.

Security Journalist Are Making Websites Less Secure

The inaccurate information presented in those articles about that situation isn’t one off issue, from what we have seen that is probably the default situation. Beyond misleading the public about the specific situations discussed in those articles, overall this leads to people having a bad understanding of what is going wrong with security (of which there is plenty) meaning that problems that could have been fixed long ago don’t get fixed and that websites are insecure in ways that they shouldn’t be. The poor handling of the security of WordPress plugins by the people on the WordPress side of things could definitely use the spotlight of security journalists (instead they are providing cover for that).

The problems caused by security journalists don’t end with that though, security companies certainly get promotional value from having their claims covered by these journalists. The public would likely believe that these journalists wouldn’t rely on companies that don’t know what they are doing. That would be a very bad assumption, as our discussion of another Threatpost article from a little over a month ago showed. In that instance they relied on security company, Sucuri, which had written a post about a vulnerability for which they somehow had no understanding of it. It was the kind of situation where there should have been coverage that you have a security company that is unfit to be in business instead of covering them as a legitimate source, as was done.

You don’t have to look any farther than Sucuri to see that security companies believe that being a source has reputational boost as they promote their “research” being covered, right on their homepage:

From what we have seen over the years is that company doesn’t even try to do the work they claim to be doing, so not only does their service not effectively protect websites, but they don’t try to properly clean up websites. While that failure to properly clean up website has a big impact on their customers (far too many of them have had to hire us to re-clean their websites over at our main business), but it makes everyone less secure since they usually don’t attempt to determine how websites have been hacked, which means that, for example, zero-day vulnerabilities can go unfixed longer, leading to more websites being hacked.