Protection against setting the WordPress default “role” to “Administrator”

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:

Allowing this is a serious flaw that was supposed to be fixed in WordPress itself some time ago, but the problem still exists.

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.

Protection against a critical Joomla security bug

The authors of the Joomla software announced today that every version of Joomla between 3.2.0 and 3.4.4 has a critical security bug that allows hackers to take over a site (the bug is known as “CVE-2015-7857”).

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.

Read the rest of this entry »

Protection against the WordPress “large comment” security bug

The authors of WordPress today released version 4.2.1 that fixes a critical security 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.

Read the rest of this entry »

Protection against the critical Magento “Shoplift” security bug

Researchers recently found a critical security bug in the widely used Magento e-commerce shopping cart software. If you use this software and don’t update it to fix the bug, “hackers” can easily take over your site, including potentially stealing the credit card numbers of your customers.

We’ve analyzed the Magento software our customers have installed and found that more than half is unpatched, despite the Magento team sending e-mail notices to Magento users in February.

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

Read the rest of this entry »

Protection against WordPress “Pagelines” and “Platform” theme security bugs

The researchers at Sucuri yesterday announced that they’ve discovered a critical security bug in the widely used Pagelines/Platform WordPress themes. If you use one of these themes or their many derivatives, “hackers” can easily take over your site unless you update the theme.

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.

We’re again surprised to see how many customers are using versions of these themes that haven’t been updated in years. I know we sound like a broken record, but when WordPress offers to update something you’ve installed, you must update it if you want your site to stay secure.

Read the rest of this entry »

Protection against a critical Drupal security bug

The authors of the Drupal CMS software recently announced a “highly critical” Drupal security bug (CVE-2014-3704). This vulnerability is being very widely exploited: If you use Drupal 7 on a server without protection, and you haven’t upgraded to Drupal 7.32, your site is soon going to be compromised (taken over by “hackers”).

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.

Read the rest of this entry »

Protection against a critical Joomla file upload security bug

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.

Read the rest of this entry »

WP Super Cache and W3 Total Cache security

Several people have asked us about the recent WordPress WP Super Cache and W3 Total Cache plugin security vulnerability.

For the most part, sites hosted on our servers aren’t vulnerable to this because we block comments that contain the malicious code.

Read the rest of this entry »

WordPress login rate limiting (again)

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.

Read the rest of this entry »

Our customers are protected against the CVE-2012-1823 PHP security bug

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.

Read the rest of this entry »