If you use WordPress, and you allow strangers to register for WordPress accounts (which isn’t usually a good idea, but some plugins require it), it’s possible to accidentally configure it so that those new users get created as WordPress administrators. That can happen simply by doing this:
We don’t think it’s reasonable to ever create new users as “Administrators” by default, regardless of whether you have “anyone can register” turned on. (Even if “anyone can register” is turned off now, it would be easy to turn it on later without remembering to change the default role back.)
To make sure our customers’ sites stay secure, we’ve added some protections against this:
Setting the “New User Default Role” to “Administrator” is blocked at the Web Application Firewall (mod_security) level on our servers, whether from the WordPress dashboard or from any other web request;
If it somehow gets set anyway, our security systems will detect it as part of the daily security scan we do of every site;
If your site already had this setting as of today, we’ve restored it to the default “Subscriber” role.
Nobody should notice any changes as a result of this, but as always, don’t hesitate to contact us if you have any questions or difficulties.
The best solution for Joomla users is to update to version 3.4.5 immediately. However, we’ve also added a rule to our servers to protect our customers until they do this. The rule should ensure that if you use our hosting service, “hackers” won’t be able to take advantage of this bug.
While upgrading is always a good idea, we’ve blocked the attack for all versions of WordPress on all sites that we host. We’ve also verified using our MySQL binary logs that no sites were attacked before we started the blocking.
“Hackers” are now beginning to exploit the bug. Because this is so dangerous, we yesterday added security rules to block these attacks even if you haven’t updated.
Although we’re confident that these rules block the current attacks (we’ve seen it block several live attacks, and it makes sites we host pass the useful Shoplift bug tester), you should still patch your site if you use Magento: using outdated versions of e-commerce software is always dangerous.
Since many of our customers use these themes, so we’ve added security rules to block attacks even if you haven’t updated. And we’re glad we did: our logs show that a large Chinese botnet started attacking every WordPress site we host last night, in alphabetical order (they’re currently up to domain names starting with “e”), testing whether each site is vulnerable to the bugs.
To protect our customers who have installed Drupal, yesterday we added security rules to block the common attacks. And today, we “patched” the vulnerable “database.inc” file on every copy of Drupal on our servers, blocking the more complicated attacks that we expect to see in the future.
So our customers are protected against this particular problem. But that doesn’t mean you shouldn’t upgrade Drupal: older versions also have other security bugs. So if you’ve installed the Drupal 7 software on your site, please make absolutely sure you’ve upgraded to version 7.32 today.
There’s been a lot of discussion recently about a critical Joomla security bug that allows “hackers” to upload malicious PHP script files to Joomla sites, then run them. This would allow hackers to use your site to send spam, or to replace any file on your Web site.
Although our customers running Joomla should always upgrade to the latest versions when available, we’ve also put rules in place to protect against this vulnerability.
We’ve talked before about WordPress login rate limiting. Attempts to guess WordPress administrator passwords are an ongoing problem, getting worse all the time.
The average WordPress site we host has received tens of thousands of malicious login attempts this month, with hundreds of thousands of different IP addresses being used in the attacks. We try to block the IP addresses that are responsible, but the ever increasing number of addresses means we can’t block all of them — an individual address often attempts a login only once a day for a given site. We need to adopt other tactics.
There’s been a lot of talk in the last few days about a nasty PHP security bug that allows “hackers” to compromise some Web sites that use the PHP scripting language.
Our customers are not vulnerable to this problem because of the way PHP is set up on our servers. You don’t need to worry about it.
