Drupalgeddon project long-term support plans

Thank you for starting this discussion.

While Drupalgeddon should certainly not be recommended as a solution for compromised websites, I think it is still useful as long as its shortcomings are clear.

1. For people who can not restore from backups, it helps them find and remove backdoors more quickly, and collaborate on signatures of new types of exploits. (It may also make attackers put backdoors in harder to find places, which makes finding and removing backdoors harder. But that is just conjecture.)
2. It helps people realise that the attacks and backdoors are real; Restoring from backup is not just a precautionary measure, and Drupageddon is not to be taken lightly.

I think there are some key improvements we can do to reduce the false sense of security or optimism that users may be fooled into:

1. Upon execution of any drupalgeddon drush command, check if there is a newer version of drupalgeddon available, and if so; Try to self-update. If that fails, exit with error "A newer version of Drupalgeddon is available. Update and run drupalgeddon-test again: drush dl drupalgeddon". Skip this check if --force is specified, but only document that in drush help drupalgeddon-test. We can just tell the user to update initially. A later version can attempt a self-update.
2. Constantly remind users that drupalgeddon is not reliable;
   • The project page already makes this clear.
   • If drush drugtest was negative (no known-signs of compromise), issue a warning "Nevertheless, the website may have been compromised".
3. Regardless of the drugtest result, issue the warning "Restoring from pre-15 Oct 2014 backups and updating to 7.32+ is the only certain way to secure a publicly accessible website that was vulnerable to SA-CORE-2104-05 (Drupageddon)".
4. Make it as easy as possible for people to document exploit signatures, create patches to look for them, commit patches (sponsorship? gittip? more maintainers?)

On a slightly related note; According to the project page's download statistics, the tool was downloaded 1000 times per day for the 7 days after the PSA, but has not been downloaded since. (I have been checking manually each day). I think it must be broken. I created #2373479: Download count broken?.

I feel the project should be kept online, there's valuable work in there that can be used within other projects and/or as reference.

I also feel that there should be some version checks, IE if it's a Drupal version of 7.32 or higher, don't run file checks. That way the project can avoid the whack-a-mole approach and endless support.

There should probably be a 1.0 release and the project status set to minimally maintained at some point. That will help set expectations.

We have added drupalgeddon extension in all BOA servers by default in all accounts, but since BOA uses its own download mirrors, these downloads are/were not visible in stats on d.o here. As far as we know, there are over 500 BOA systems not associated with our own hosting, plus a big list of BOA instances we host or maintain. All of them can have multiple accounts, with multiple sites managed per account, and drupalgeddon is still very useful there, even if BOA already patched all vulnerable codebases hosted on it, and still monitors newly added codebases to make sure they are all patched if still used.

We are using drupalgeddon in the pro-active mode - users don't need to run it manually, it is run on all hosted D7 sites, daily, and if it it detects anything, it keeps sending alerts to the system admin and sites owners.

Furthermore, since there was already enough time to fix hacked sites, BOA has started to automatically shutdown all clearly hacked sites (like when there are most popular roles and users with escalated privileges detected). BOA still uses drupalgeddon to runs these checks.

We have also made it clear in our messages to BOA users that no alert doesn't mean that your site is clean, only that available tools couldn't find *known* attack symptoms.

In my opinion the project should stay online, since it is still very useful to not only detect hacked sites, but also some otherwise hard to notice issues with codebase integrity or structure. It helps a lot, so please don't shut it down!

Thank you for this great work!

To clarify; I think the Drupalgeddon drush command should attempt to update itself, not Drupal core. I think that is beyond the scope of this project.

I agree with keeping the project, we are using it for on-going monitoring. Our script automatically downloads the latest copy, then applies the patches that haven't been committed yet.

I would also suggest putting the disclaimer notice at the beginning of all output as a reminder.

I just want to note, I ran the Drupalgeddon test earlier today against a compromised site. Drupalgeddon reported 7 suspicious files (which, upon closer inspection, were definitely attack files. I then diffed by entire code base against the last-known-good version I had in version control (this version was local to my desktop) and found that those were the only files that had been changed.

So, good job to Drupalgeddon, for accurately identifying attack files a month after the attack started. I guess I could see why this project might stop being useful in theory, but in my case Drupalgeddon absolutely nailed it.

I think the Drupalgeddon drush command should attempt to update itself, not Drupal core.

I strongly do not recommend that. Including a version? That's fine. I do that in site_audit.

/**
 * Display the Site Audit version.
 */
function drush_site_audit_site_audit_version() {
  $info = parse_ini_file(SITE_AUDIT_BASE_PATH . '/site_audit.info');
  drush_print(dt('Site Audit v@site_audit_version', array(
    '@site_audit_version' => $info['site_audit_version'],
  )));
}

site_audit_version=1.12

Of course, there should be a version number as well, so I'd recommend making 7.x-1.0 as a starting point.

@mkorostoff; Remember that Drupalgeddon can not guarantee it has found all the backdoors. Did you also investigate the files directories and database or restore from backups?

Given we have moved the tasks into new issue nodes, I think this is resolved?

Even if the value for the Drupalgeddon exploit has diminished potential at this time, I think we should continue maintaining this module with more of a focus on scanning for potentially exploited sites. A new attack may come out at some point, but the style of backdoors will remain quite similar to the ones we're already scanning for.