Yesterday, on one of our websites and in data from third-party websites, we saw what looked to be a hacker probing for usage of GoDaddy’s WordPress plugin CoBlocks by requesting the readme.txt file for it:
/wp-content/plugins/coblocks/readme.txt [Read more]
As we have noted in the past, the GoDaddy owned security provider Sucuri keeps writing blog posts about what has happened to their customers’ websites after they have been hacked. They seem uninterested in how those websites were hacked, despite the importance of figuring that out as part of properly cleaning up a website. And, more importantly, they are uninterested in that despite being a service that is supposed to protect websites from being hacked. At best, these are new customers, but they don’t mention that, which would seem like an obvious thing to mention when you are a service that is supposed to avoid that situation. If you look at reviews of Sucuri, there are plenty of customers mentioning they were hacked despite already using the service (some of them with a positive view of the company, despite that).
You would reasonably think that journalists writing stories that cite those posts would be in the context of raising questions about Sucuri, but they don’t. In a recent instance, the WordPress Plugin Directory was being criticized instead. [Read more]
The headline of the most recent post on the blog of GoDaddy’s security service, Sucuri, blares “Massive Campaign Uses Hacked WordPress Sites as Platform for Black Hat Ad Network”, which was written by Denis Sinegubko. How massive? Not massive at all, as they claim that it only involved 5,600 websites:
PublicWWW results show over 5,600 websites impacted by this malware at the time of writing [Read more]
Last year GoDaddy disclosed a massive security breach of their managed WordPress hosting service, which according to them, impacted 1.2 million of their current and previous customers. They also claimed that customers’ passwords were compromised:
•The original WordPress Admin password that was set at the time of provisioning was exposed. If those credentials were still in use, we reset those passwords. [Read more]
A month ago, GoDaddy was in the news after announcing a data breach of information for customers using their managed WordPress hosting service. What was lacking in the coverage of that is that GoDaddy owns a major web security provider, Sucuri. It seems like if a web host owns a major security provider they should have a good handle on security, not fail to handle the basics, as the breach showed.
For those knowledgeable about security, the apparent incongruity really wasn’t surprising, since Sucuri has always been run by people that don’t seem to have much grasp on security. That could be seen again in a post earlier this week about vulnerabilities recently fixed in a popular WordPress plugin, All in One SEO. [Read more]
We can’t emphasize enough that you should not use the plugin Ultimate Member as the plugin has been riddled with security vulnerabilities including one that was widely exploited last year and was slow to be fixed, due to what appears to be a lack of interest by the developer in getting it secure. That lack of interest is particularly problematic due to the fact that the plugin has 100,000+ active installations according to wordpress.org. The latest vulnerability found in it is yet another reminder of that, as the developer attempted to fix a serious vulnerability, but used the wrong code, so there is still a vulnerability, though less easily exploited. The continuation of the vulnerability also involves a security failure in WordPress that was warned about back in February of 2011, but still hasn’t been resolved despite being continually being implicated in widely exploited vulnerabilities.
The situation is also is yet another reminder why actually checking out and testing out claimed fixed vulnerabilities is important, so you don’t incorrectly believe that an unfixed vulnerability that is more widely known about, since it has been noted to have been fixed, has been fixed. That is something we do, but clearly other data sources on WordPress plugin vulnerabilities competing with our service don’t do. [Read more]
We recently found that the Site Analytics Plugin contains a cross-site request forgery (CSRF)/cross-site scripting (XSS) vulnerability on the plugin’s setting pages, /wp-admin/plugins.php?page=siteanalytics.php.
The CSRF potion of the vulnerability was due to a lack of a nonce on the page and a lack of a check for a valid one when processing a request to change the plugin’s settings. [Read more]