Drupageddon - PSA-2014-003

Latest page update: May 7, 2016

»We have restarted daily checks on May 7, 2016 to make sure that no one stays on some too old Drupal version with many known security vulnerabilities. You will receive Drupageddon alert for every site with outdated and not secure codebase, even if it was not affected by Drupageddon bug directly. Please be a good web citizen and upgrade to latest Drupal core provided by BOA-3.0.2. As a bonus, you will be able to speed up your sites considerably by switching PHP-FPM to 7.0

»NOTE: If the only issue detected is related to unusually big user UID’s gaps, it will be ignored in all future checks, because it can be a false positive affecting sites with UID’s gaps caused by post-testing or post-spambots-attacks cleanup.

How BOA protects you from recently discovered catastrophic Drupal Core 7 bug? We assume that you have already read Drupal Core – Highly Critical – Public Service announcement – PSA-2014-003 which is a follow up to SA-CORE-2014-005 – Drupal core – SQL injection announcement.

!If you have received an e-mail from your BOA system monitor with subject line “URGENT: The foo.com site on server.bar.com has been HACKED!”, please read everything below and act now! But before you will attempt to upgrade your site please make sure to read our docs: Your Drupal Site Upgrade Safe Workflow.

Since November 5, 2014, BOA automated monitoring scans all Drupal 7 sites for known signatures of an attack using Drupalgeddon Drush extension. This extension helps to detect already compromised sites and sites only attacked, but only with already known attack methods. If you have not received this alert, it doesn’t mean that your site hasn’t been compromised, unfortunately. Read further below for details.

Please note that this scan may also reveal some mistakes in the platform structure, like Drupal core copied into another platform root directory, etc. You will also receive alerts if you have modified core themes, or added some .php files there. Please copy your customized or extended core theme to sites/all/themes/ and restore vanilla version in the core themes directory to avoid false alarms. Please move or delete all other files which exist in the Drupal core directory tree, since they don’t belong there if they are reported as “Common signatures of an attack”. If you believe that the alert you have received was caused by some not yet whitelisted .php files which should be whitelisted, please report this in our issue queue on GitHub.

Note that while this scan may result with some false alarms if you have some unexpected mess inside the Drupal core directory structure, there is no other method to help you identify potential problems than by comparing your codebase to Drupal 7 vanilla codebase. Please clean up your codebase to avoid receiving these alerts each morning.

If you have received the HACKED! warning e-mail and it reported as suspicious accounts you are absolutely sure are legitimate and they are not listed here, it means that these accounts are still suspicious, because they have invalid creation date, which is either a sign of account created as a result of an attack or account improperly imported, so it is shown as created 44 years ago. You have to investigate and fix every single account (and role) reported as suspicious to avoid receiving these alerts each morning. Furthermore, if the account reported as suspicious is listed here, you have to delete it (or rename if you are absolutely sure it is legitimate account), to avoid receiving these alerts each morning.

If the site reported as hacked doesn’t use ~/static directory tree, but some very old built-in Drupal 7 platform, not fixed automatically on October 15, because it was older than 18 months (with core 7.22 or older), so it didn’t use current BOA standard directory tree for shared D7 cores in /data/all/000/core/, the attack could be still successful, even if all built-in platforms, including those ancient versions you shouldn’t use (right?), are write protected, because there are myriads of other possible attack vectors, which don’t need any extra .php files, so don’t assume that you are safe just yet!

!It’s important to understand that while all built-in Drupal 7 platforms (with core 7.23 or newer) have been patched immediately after SA-CORE-2014-005 security alert has been published, your custom D7 platforms located in the ~/static directory tree have been patched after BOA-2.3.5 release and subsequent upgrade, so with some delay, depending on the server timezone.

You can easily verify the exact date and time when your custom D7 platforms have been checked and patched if needed, by looking at the timestamp (modification date) on this special file located in every custom platform: profiles/SA-CORE-2014-005-D7-fix.info.

If you have found some suspicious .php files in your custom codebase in the ~/static directory tree (again, they never worked for an attacker anyway!), or you have discovered other anomalies in your site’s database or behaviour, you should assume that your site has been compromised, and you should investigate this immediately.

!Warning & Reminder for self-hosted BOA users: Unless you have enabled non-standard option _PERMISSIONS_FIX=YES in your /root/.barracuda.cnf file, BOA did not patch your custom platforms located in the ~/static directory tree before November 2, 2014. We have explained this at the top of BOA-2.3.5 changelog.

»Update for hosted and self-hosted BOA users: Since November 3, 2014, both BOA and its Skynet Agent will force _PERMISSIONS_FIX=YES by default again, on both hosted and self-hosted instances, so critically important fixes can be applied. It will still honor the custom value of fix_files_permissions_daily INI variable, if set in the platform level INI file, but only if the platform has been already patched. If not, it will be ignored and BOA will proceed with patching the platform and forcing its default permissions / ownership on dirs/files in the codebase.

Is there any good news? Even if you have discovered and confirmed that your D7 site has been hacked before BOA was able to apply the patch, possible damage can be at least partially limited thanks to these BOA default shields:

• BOA strict web server configuration doesn’t allow to execute unknown .php files
• There is no write access to Drupal core in any built-in platform
• BOA comes with shell wrappers designed to block various possible attack vectors

»Update for self-hosted BOA users: The BOA Skynet Agent normally runs only daily checks for BOA new release. It also updates all BOA meta-installers. But since November 1, 2014, BOA Skynet Agent will daily hot-fix Drupal SA-CORE-2014-005 also on servers left on auto-pilot or not fixed yet, globally, no matter which BOA version is used – head, stable or legacy.

»Good to know: Why BOA runs these checks and fixes daily since October 15, 2014? It is possible, and should be expected, that users will continue to import sites with old, vulnerable D7 core versions in the ~/static directory tree, so it is not enough to run/provide only one-time hot-fix.

If you have any questions not answered above, please contact our support.