Write up on Drupageddon hack (attempt) on my site

On October 21, 2014, an attempt to compromise my personal web site was partially successful. The attack was able to delete log entries for October 21, 2014, and was able to add a non-existent user to the administrator role on the web site. The attack apparently failed to actually create the user, however.

The attack exploited an SQL injection vulnerability. This vulnerability was almost certainly the vulnerability describe in Drupal’s SA-CORE-2014-005 advisory, released on October 15, 2014. This vulnerability lead to what is referred to in the Drupal community as “Drupaggedon”, an event where a massive number of Drupal sites were compromised.
Investigation of the attack involved comparison of the compromised site to a backup of the site made on October 4, 2014. The analysis was performed using standard unix commands, and a Perl script used to break large lines in the mysql backups into manageable chunks. The most important information was located in the “watchdog” table of the site, which contained some of the information that would have been in the missing log file.
Important lessons from this incident
 Prompt patching would have prevented this partial compromise.
 Site administrators should consider changing the administrator role from the default numeric value
 Patching prior to data gathering, although recommended by Drupal.org, significantly complicated the investigation
 Log entries should be sequestered in real time by web sites if they have a high security requirement (remote syslog, etc.)
 The ability of Drupal to access the backend database directly is a fundamental design flaw.