On Oct 15th 2014 a serious security vulnerability in the Drupal CMS was reported by the Drupal Security Team:
with additional articles here:
The issue also made the headlines of some major news agencies, e.g.
Itomic hosts and/or supports some 40+ Drupal sites. Within 24 hours of the issue being announced, all Drupal sites covered by Itomic’s Drupal Security Contract (DSC) were patched. Where Drupal site owners did not have a DSC, their sites were patched some time afterwards.
In common with the experience of others (see the FAQ), Itomic noticed that some sites (4, to be precise) had already been patched, but not by us. This was a clear indication of interference by hackers. First they used the security vulnerability to write a malicious script (a single file) to the hosting account, then they closed the backdoor to other hackers by patching the vulnerability. This technique might have tricked some website owners into thinking that, because their websites were patched, everything was fine. In each of the 4 compromised websites Itomic was able to quickly and easily delete the malicious scripts.
All Drupal sites hosted and/or supported by Itomic, including the 4 above, were individually reviewed for malicious activity. This included the use of the tool Drupalgeddon. No additional malicious activity was discovered.
We acknowledge that, just because no additional malicious activity was discovered, this does not guarantee that some of the sites were not compromised in ways we have not yet been able to detect. That said, because of our prompt action and follow-up site reviews, we deem this to be very unlikely.
If indeed there are some sites on our systems that remain compromised, we’re as confident as we can be that our hosting systems and procedures are extremely well equipped to a) detect and report any significant malicious activities emanating from the compromised sites, and b) prevent those malicious activities from negatively impacting other hosting accounts on the same hosting server.
- CloudLinux, arguably the most secure operating system for shared and dedicated website hosting.
- suPHP and CageFS. These make it theoretically impossible for an infected hosting account to interfere with other hosting accounts or the broader server environment.
- OSSEC. Intrusion detection system.
- Maldet. Realtime malware detection.
- OpenNMS. Performance and health monitoring.
- KernelCare. Rapid automatic patching of core server software.
- In collaboration with our advanced tech support partners in the USA (a very successful 10+ year relationship), we have a 24/7 human response team in place to deal with critical issues.
- With the odd temporary exception, our hosting policy is to only run a single CMS-type per server. So for example we have Drupal-only servers and WordPress-only servers. This has two primary benefits: 1) we can optimise the hosting environment for that particular CMS, 2) security issues with one CMS-type do not impact other CMS types.
Above we’ve described what Itomic does to protect the website assets of our valued clients. And yet the fact remains that if a person (or ‘bot’) is in possession of a valid username and password, all the above provides little or no protection. Which is why always using very ‘nasty’ (hard to guess) passwords is imperative for all persons who login to electronic systems – especially those with elevated privileges such as administrators or super-users. We acknowledge that really nasty passwords are, by definition, hard to remember. We therefore strongly recommend the use of password management systems such as LastPass or other reputable alternatives. If you’re not comfortable with electronic systems storing all your passwords, here’s an article about how to create and remember good ones.
Are you knowingly using a relatively easy-to-guess password? We urge you to change it today.