Drupal Sites Hacked Worldwide in October 2014

Security Exploit revealed in October allows total control of YOUR Drupal site
Security Exploit revealed in October allows total control of YOUR Drupal site

In mid-October Drupal announced a serious defect in the Database Abstraction Layer allowing guest users to gain full access to a site and server. The security noticed can be found at the FAQ on SA-CORE-2014-005 on the Drupal website.

This exploit creates the ability for attackers to place their own PHP files on your server for remote execution, or to inject their own code into pre-existing files.

Ways to detect a breached system - and steps to remediate:

Look for files with a datestamp in October 2014

If you didn't upload any new versions or modules in October 2014, there should be no php or include files with these datestamps. Use the Linux FIND command to find files last edited on or after October 1st, 2014 and then check those files.

Locate files with PCT4BA6ODSE_ in them

Using the GREP command, look for files that have this string - which was a popular exploit that hit many sites. The string of characters was used to programmatically assemble remote-execution code in a way that would be hard to decipher for the casual observer.

Locate files that have a giant array of character mappings at the beginning

Some of the popular exploited sites have obfuscated code that hinges on an "alternate alphabet" being set up in the beginning. If you see page that you don't recognize, and it starts with a massive list of alphanumeric characters "equalling" other ones, delete the file.

Look for file permissions that do not make sense

Again, using the FIND command, look for file permissions that are not inline with the peer files in the same directory. Often times a hosting company will mark files as non-executable when they determine a site has been hacked. For example, 1 and 1 hosting will flag files as "200" which means they have effectively been quarantined. Using FIND against en entire directory to look for these permission settings will essentially dump a list of hacked files. You may also find that the hosting company shuts down entire directories of sites by removing the public execute bit. Contact your hosting company for more information on that.

Check your database for new (database) users

Manual hack attempts may be more intricate than automated ones. When a hacker takes control of your site they may add a DB user so that once you fix your site they can still come in through the DB and re-establish a beach head. Make sure there's nobody in there that you don't recognize.

Look for the EVAL() command

This one's harder to do since not every file using PHP's eval() command is malicious code. But almost every hacker's attack vector involves the eval() command at some point. GREP for that command and interrogate the files containing it that they don't look strange.