WebShell にアップロードされたトレーサビリティ イベントの分析例

検査と強制終了

まず、私がしなければならないことは、アップロード場所が表示される場所を見つけることではなく、サーバーにログオンしてWebシェルの検査と検査を実行する必要があることを理解しています。他人から侵入されていないか、バックドアがないかなどを確認します。報告された IP アドレスは当社の IP アドレスですが、いくつかの Web シェルが見逃され、他の人がアップロードに成功したにもかかわらず検出されなかった場合、サーバーが侵入された場合はどうすればよいでしょうか?そこで私はサーバーを検査し、WebShell 強制終了ツールをアップロードして、netstat -anpt と iptables -L を使用してバックドアが確立されているかどうかを確認し、CPU を占有しているマイニング プログラムがあるかどうかを確認しました。ここでは詳細には触れません。幸いなことに、サーバーは侵害されなかったので、このアップロード ポイントに何が起こったのかを考え始めました。

ファイルアップロードの脆弱性レビュー

まず、連絡をくれた開発者にこの公開されているサーバーのアドレスを聞き、アドレスを聞いた上でサーバーを開いて、見覚えのあるものは、私が最近テストしたものであることがわかりました。この時少し混乱し、修正情報を開発者にぶつけたところ、前回のテストの結果、アップロード先がホワイトリスト制限を行っており、jpeg、png、その他の画像形式のみのアップロードが許可されていることが分かりました。その際、アップロードがホワイトリストによって制限され、アップロードされたファイル名に乱数が追加され、時間ルールが一致していても、返送されたパッケージでアップロード パスとファイル名が見つかったことも発見しました。他 ファイルに脆弱性が含まれる可能性があるので修正するよう勧められましたが、実際に修正が行われ、パスが戻らなくなったとの報告がありました。

ファイル接尾辞エンコードのバイパス

前回の修正の問題について議論し検討した後、自分の考えを明確にしました。次に、原因を確認するために Web サイトにログインしました。Web サイトには写真をアップロードする場所が 1 か所しかないため、パケットをキャプチャしようとしました。リピータを使用してパッケージを再生した後、返されたパッケージがファイルのアップロードを返していないことがわかりました。そこで色々と寄り道をしてみたのですが、結果はダメでした。結局、一生懸命考えても結果が出ず、クラウドプラットフォームにアラームが提供された理由を尋ねました。クラウドプラットフォームからのフィードバック結果を読んだところ、画像コードがあることが分かりましたが、これは大きな問題ではありません、アップロードされたファイルには実行権限がなく、ファイルパスも返されません、ファイル名はランダムに変更されています、しかし、なぜこの JSP は正常にアップロードされたのでしょうか? そうですね、これには困惑しています。

クラウド プラットフォームによって提供される webshel​​ データを注意深く観察したところ、ファイル名に Base64 エンコーディングが使用されていることがわかりました。これについて非常に混乱しています。すでにランダム関数を作成しましたか? 前回は、テスト中にコーディングが行われませんでした。私は突然問題の鍵を思いつき、burpsuite のデコーダ モジュールを使用してファイル名「1.jsp」を「MS5Kc1A=」に Base64 エンコードし、このアップロードの代わりに成功したフィードバック ステータス コード 200 を送信しました。失敗フィードバック ステータス コード 500 エラー。

つまり、問題は、修正プロセス中に研究開発担当者がファイル名にbase64エンコーディングを使用したため、保存プロセス中にファイル名がbase64を使用してデコードされ、ファイルをアップロードしたときに、サフィックス名を .jsp に変更しましたが、これも Base64 でエンコードされ、.jsp は保存プロセス中に正常にデコードされました。研究開発チームは、デコード後にホワイトリストの制限を課しませんでした。実は、このようなコーディングの変更は不要です。結局のところ、乱数を使用してファイル名を変更しているため、コーディングは少し余分です。プログラムのバグを変更すると、さらに多くのバグが発生するのはこのためです。

以上がWebShell にアップロードされたトレーサビリティ イベントの分析例の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。