This is a critical vulnerability. If this is the first you are hearing about it and you manage a Drupal website, I would highly recommend that you go read the Drupal PSA and follow the instructions there before doing anything else.
The situation with CVE-2014-3704
On October 15th, 2014 the Drupal core team released the details of a vulnerability, CVE-2014-3704, that was classified as the most severe type of vulnerability: Highly Critical. This CVE-2014-3704 SQL injection attack can allow remote, anonymous users to take control of your Drupal installation and gain access to all of your content. The Drupal team describes it in a bit more technical detail:
Drupal 7 includes a database abstraction API to ensure that queries executed against the database are sanitized to prevent SQL injection attacks.
A vulnerability in this API allows an attacker to send specially crafted requests resulting in arbitrary SQL execution. Depending on the content of the requests this can lead to privilege escalation, arbitrary PHP execution, or other attacks.
This vulnerability can be exploited by anonymous users.
The website firewall company, Sucuri, observed attacks on Drupal sites starting only 8 hours after the vulnerability was disclosed. Those attacks have become systematized and are now widespread. As a result, the Drupal team is advising all website owners to assume “[...] that every Drupal 7 website was compromised unless updated or patched before Oct 15th, 11pm UTC [...].”
What should website owners do about CVE-2014-3704?
Unfortunately, the patch that Drupal provided for CVE-2014-3704 can only prevent a future attack. If your site has already been compromised, as the Drupal team and Sucuri data suggest is very likely, the patch can not undo an attack that has already occurred. The recommendation from Drupal is to restore your website to a time before October 15th to remove the backdoor and then apply the patch to prevent re-infection.
If you have your website backed up with CodeGuard, restoring to a time before October 15th should not be an issue. If you do not have daily backups, CodeGuard or otherwise, you could also check with your hosting provider. However, while they may have a disaster recovery backup of their servers (including your website content) that was taken some time between 24 hours and 7 days ago, that would not help in a case like this where backdoors could have been inserted weeks ago. If you do not have a viable backup, the only other option that Drupal provides is to rebuild your website from scratch. Ouch. Backdoors can be incredibly difficult to find manually, so if you do not have a comprehensive backup, rebuilding is the only other truly safe option if you have been compromised by CVE-2014-3704.
Backups are a necessary part website infrastructure
Just like reliable hosting, a comprehensive backup strategy should be high on the list of priorities when building a new website or maintaining an existing property. In addition to providing some measure of insurance against events like CVE-2014-3704, they can also save you time in cases where files are accidentally deleted or when plugin updates go awry.
In addition to 99.99% levels of reliability and daily backups, CodeGuard’s ChangeAlert feature can also be helpful in bringing unauthorized file content changes to your attention. In the event that the backdoor was inserted in a file or your static content was defaced, CodeGuard can provide you with a notification of the change and the tools to roll back the malicious activity.
In this age of rapidly exploited vulnerabilities like CVE-2014-3704, a comprehensive backup strategy is no longer a nice-to-have option, it’s a must-have for every website owner or administrator.