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 … Continue reading

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 … Continue reading

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.

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 … Continue reading

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.

Your Website Probably Wasn’t Hacked Through A Backdoor

When it comes to dealing with hacked websites our experience is that information coming from web hosts often isn’t great. When you consider how terrible many security companies dealing with websites are, it isn’t very surprising that companies that don’t claim that … Continue reading

When it comes to dealing with hacked websites our experience is that information coming from web hosts often isn’t great. When you consider how terrible many security companies dealing with websites are, it isn’t very surprising that companies that don’t claim that expertise would be bad as well.

Last week over on the blog for our Plugin Vulnerabilities service we discussed one issue that comes up from time to time, which is web hosts claiming that the source of a hack is whatever software that happens to be located where a hacker placed a malicious file. Often times the hacker just randomly place their malicious files, making the location of the file a weak piece of evidence as to the source of the hack in most cases.

Another recent example of this involved someone who contacted about a website that was hacked, cleaned, and then was getting re-infected everyday. In that situation our first question is always if the person that cleaned up the website determine how it was hacked. Seeing as someone doing a cleanup should attempt to determine how a website was hacked, that will tell you if the person doing the cleanup was doing things properly (the response almost always indicates they haven’t). It also important since the re-hacking could indicate that the security vulnerability that allowed the website has not been fixed and knowing what was believed was the cause would provide a better understanding of the situation.

In this case they said that there web host had been hacked through a backdoor (apparently the person that did the cleanup did not determine how the website was hacked). For those not familiar a backdoor would be code that allows a hacker remote access to the website internals. In most cases a backdoor could not be source of a hack since the backdoor would have to have gotten on the website. Usually the hacker will exploit a vulnerability to allow them to place a backdoor on a website and then use the backdoor to perform further actions on the website, so the backdoor isn’t the source of the hacking, only a result of it.

The main exception to this is that occasionally a malicious individual will be able to plant a backdoor into non-malicious code, say sneaking it in to an otherwise legitimate WordPress plugin in the Plugin Directory. That is by no means a common occurrence though.

If your web host or someone else is telling you your website was hacked through a backdoor, you should ask them how it got there to understand if they are correct about the source of if they failed to understand the actual source.