A Drupal 7 site not updated within hours of the October 15 fix should be treated as compromised: take it offline, restore a backup from before then, update it, change every password and name an owner for updates.

A notice nobody expected to read

On Wednesday, Drupal's security team told site owners something it rarely says: any Drupal 7 site not updated within hours of the October 15 fix should be treated as compromised.

For a small business, the news arrives secondhand, from the developer, the host or a trade newsletter. Meanwhile the site looks exactly as it did last month.

That is the difficulty. A site taken over by an automated attack usually keeps working normally, because whoever controls it wants the access, not the attention.

What the October 15 release closed

Drupal 7.32 fixed a flaw in the code Drupal 7 uses to talk to its database. A visitor who was not logged in could send a crafted request that ran database commands of their choosing.

From there an attacker could add an administrator account, change pages or plant files that run code on the server. The team rated the flaw highly critical, its most serious level.

Automated attacks began within hours, trying the flaw on every Drupal site they could find. Sites updated within those first hours were ahead of them; sites updated a week later must be assumed reached first.

What an attacker may have left behind

Updating to 7.32 closes the original hole. It removes nothing an attacker added while the hole was open, which can include:

The last is why a site already showing 7.32, though nobody on your side updated it, is a warning sign rather than a relief.

The recovery the security team describes

The team's advice is to take the site offline behind a simple holding page, then tell the host, since a back door on one site can reach others on the same server.

Restore the files and database from a backup made before October 15, update that restored copy, and only then put it back online. Changes made since the backup are redone by hand.

Cleaning the live site in place is possible, but the team advises against it. Back doors are hard to find, and a single one missed leaves the attacker's access intact.

When every backup is too recent

Many small sites rely on the host's rolling backups, which keep a week or two and then overwrite the oldest. The copies from before October 15 may already be gone.

Ask the host today whether anything older survives, and ask the developer what copies were kept. A copy from the summer is a better start than a compromised one from last week.

Without any clean backup, the safer route is a rebuild: a fresh installation of Drupal and its modules, with the content brought across and checked page by page.

Passwords and the rest of the server

Once the clean copy is running, change every password connected to it: each Drupal account, the database password, the hosting control panel and file transfer.

Staff who used the same password elsewhere, such as for email, should change it there too. A copied password record can be worked on long after the site is clean.

If other sites or mailboxes share the hosting account, ask the host to check them as well. An attacker able to run code on the server was never confined to one folder.

A worked example

The site of a geotechnical engineering firm with offices in two Interior towns was built on Drupal 7 four years ago: project summaries, staff profiles, a careers page and a contact form.

Its developer has moved on, and nobody at the firm reads Drupal's announcements. The update went on October 22, after the host sent a general reminder.

The office manager heard about Wednesday's notice from a client. The user list showed an administrator account nobody recognised, created on the evening of October 15.

The site went offline that afternoon behind a page with both offices' phone numbers.

A nightly backup from October 13 was restored to a fresh account, updated and checked against the office's drafts. A copy from before October 15 cannot hold anything an attacker added.

Every password was changed. Security updates now sit under a monthly maintenance agreement, with a named person who applies critical releases the day they appear.

Updates need an owner

Drupal, WordPress and Joomla all publish security releases. Most can wait a few days for a convenient time; now and then one cannot, and only the announcement says which.

A site with no named owner for updates waits until someone happens to notice, such as a reminder from the host a week later or a client mentioning the news.

The owner need not be anyone in the office. It has to be a person or company with the access to act, who reads the announcements and applies critical fixes the same day.

Backups belong in the same arrangement: enough history to recover from a late discovery, one copy kept away from the server, and a record of what was updated when.

The counter-case

A site updated on October 15 itself, within hours of the release, is in a different position. A look at its user list and recent files is a sensible precaution, not a rebuild.

Sites still on Drupal 6 were not affected by this flaw, which is in code Drupal 7 introduced. They have their own security releases to keep up with.

A site already due for replacement may not justify a careful restore. It still should not stay online in the meantime, because an unexamined back door puts the whole server at risk.

If your site runs Drupal 7

  1. Find out which version the site runs and when it was updated.
  2. Ask the host how far back its backups go, today.
  3. Take the site offline behind a holding page if the update came late.
  4. Restore a backup from before October 15, then update it.
  5. Change every password connected to the site and the server.
  6. Check the user list for accounts nobody recognises.
  7. Name the person who applies security updates from now on.

Step two is the urgent one. Rolling backups are overwritten on a schedule, and each day brings the clean copies from before October 15 closer to deletion.

For ordinary, scheduled updates, with a backup first and someone testing the forms afterwards, see WordPress 4.0 and updating without surprises.

Frequently asked questions

What did the October 15 Drupal update fix?

A flaw in how Drupal 7 builds its database requests. Anyone, without logging in, could send a crafted request that ran their own commands against the site's database.

Why treat the site as compromised if it looks normal?

Automated attacks began within hours of the fix and were built to stay quiet. A site that looks normal can still hold a hidden account or a back door.

Does updating to Drupal 7.32 now solve the problem?

It closes the original flaw but removes nothing an attacker added while it was open, such as extra administrator accounts, planted files or changes in the database.

What if our only backups are from after October 15?

Ask the host at once for anything older, since backups are deleted on a schedule. Without a clean copy, the safer route is a rebuild with the content brought across carefully.

Were Drupal 6 sites affected?

Not by this flaw, which is in code that Drupal 7 introduced. Drupal 6 sites still need their own security releases applied promptly whenever they come out.

Who should own the updates from now on?

A named person or company with the access to act and the habit of reading security announcements, agreed in writing so that critical releases go on the same day.

West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.

Drupal site updated after October 15?

Send us the address and the date it was updated, and we will help you plan the restore and the clean-up.

Start a Conversation