Thinkphp の歴史的な脆弱性を保護の観点から見る方法を教える

以下は、Thinkphp フレームワーク 開発チュートリアル コラムで、Thinkphp の歴史的な脆弱性を保護の観点から紹介します。

1. はじめに

2019 年の初めに、Thinkphp5 の 2 つの RCE 脆弱性がインターネット上で公開されました。スキャナを使用してネットワーク全体をスキャンします。これらの脆弱性を利用して、ips デバイスを介してバッチ getshell 攻撃を実行する大量の攻撃トラフィックが引き続き観察されています。この記事では主にトラフィックの観点から簡単に分析し、thinkphp を使用してネットワーク全体のスキャンと getshell トラフィック トレースを攻撃します。

2. Thinkphp RCE の脆弱性とトラフィックのスキャン

2.1 脆弱性の原則のレビュー

2.1.15.0。 x バージョンの脆弱性

原則として、Thinkphp がリクエストを処理するために使用する主要なクラスは Request(thinkphp/library/think/Request.php) であり、HTTP リクエストのいくつかの設定を実装できます。

Thinkphp は、「フォーム迷彩変数」の構成をサポートしています。デフォルトでは、この変数の値は _method です。したがって、method() で「フォーム迷彩変数」を使用して変数を上書きし、このクラスの関数を呼び出すことができます。関数として $_POST が使用され、パラメータが渡されます。フィルター属性 (フィルター属性にはグローバル フィルターに使用される関数が格納されます) を上書きするなど、リクエスト クラスの属性値をオーバーライドするリクエストを構築することで、コードを実行できます。

2.1.25.1.x-5.2.x バージョンの脆弱性

5.0.x バージョンの脆弱性と同様に、脆弱性ポイントはすべて Request(thinkphp/library/) に存在します。 think/Request.php) クラス、ここで:

##$method 変数は $this->method で、これは POST の "_method" パラメーター値に相当し、次のことができます。 $ filter の属性値 (filter 属性には、グローバル フィルタリングに使用される関数が格納されます) をオーバーライドしてコードを実行するために使用されます。

この脆弱性が発生すると、警告レベルの例外が発生し、プログラムが終了します。このとき、例外を無視するプロンプトを設定する必要があります。public/index.php で error_reporting(0) を設定します。以下に示すように、例外を無視してコードの実行を続行します。

##2.2 ネットワーク全体で Thinkphp の脆弱性をスキャンします

From aトラフィックの観点から見ると、Thinkphp の脆弱性を利用して http パケットが送信されます。私たちは、ハッカーのスキャナが最初に単純な文をフィンガープリントとして書き込み、次にファイルにアクセスしてフィンガープリント情報が返されるかどうかを確認することを発見しました。アクセスが成功した場合は、シェルが成功したことを示します。基本的に、それは 2 つの http パケットを送信し、スキャナーは正常な書き込みを記録します。Web サイトの IP とシェルの URL を入力し、その後の操作のために包丁を使って手動で接続します。

IPS デバイスのログと手動検証から、攻撃者の攻撃手順には 2 つのステップが含まれます: 1. ネットワーク全体をスキャンして exp を送信し、指紋に基づいて getshell を行うかどうかを識別します; 2. 遠隔制御用のチョッパーで接続します。 ;

2.2.1 ネットワーク全体をスキャンして exp

通常、スキャン ログはセグメント B またはセグメント C を横断し、比較的長時間かかります。ログフラグメントは次のとおりです。

には 3 つの特徴があります。 1. 宛先 IP が同じセグメント C または B である、 2. ポートが比較的固定である、 3. スキャン時間が非常に集中する #Scan シェルが正常に書き込まれたことを確認するためにスキャナーによって送信されるメッセージには、スキャナーの専用のフィンガープリントが使用されるため、ips にはこの検出ルールがありません。

2.2.2 チョッパー接続

攻撃者が侵害されたサイトに手動でチョッパーを接続すると、IPS によっても検出され、ソースを追跡できます。コンテキスト関連付けによる thinkphp の脆弱性、攻撃者の侵害ポイント。当時記録された典型的なケースをいくつか選択します: 侵害された鄭州サーバー 1 (122.114.24.216):

この Web サイトは確かに thinkphp5 用に開発されました。その時点では、WebShell 型トロイの木馬はまだサーバー上に存在し、削除されていませんでした。ハッカーによってアップロードされたトロイの木馬はサーバー経由でアクセスでき、フィンガープリント情報はbaiduであり、スキャナーはこのフィンガープリントを使用してgetshellの成功を自動的に判断し、URLを記録します。

侵害された四川省サーバー (182.151.214.106):

侵害された四川省サーバー (182.151.214.106):

これは、このケースのトロイの木馬は削除されましたが、その時点ではサーバーはまだ接続できました。サーバーは thinkphp フレームワークでもありました。ユーザー名は chanpei

であると疑われていました。デバイスはハッカーのトロイの木馬への接続とネットワーク クエリ コマンドの実行を記録したメッセージで、取得された情報は上記のエラー メッセージと一致しています。また、サーバーがイントラネット内のマシン上にあることもわかります。スクリーンショットは、以下に示すように、ネットワークに少なくとも 2 つのサブネット 192.168.9.0 と 192.168.56.0 が含まれていることを示しています。

侵害された米国サーバー (161.129.41.36):

この米国サーバー上の Web シェルもクリーンアップされました。デバイス パケット キャプチャを通じて、次のことが判明しました。はハッカーでした 同じ Web シェル トロイの木馬、つまり x.php が使用されており、同じハッカー グループであると疑われています。

ハッカーが米国サーバー上の x.php (Webshel​​l) ファイルの内容を参照すると、デバイスは x.php のパスワードが xiao であることを記録し、旗も百度でした。

Thinkphp のこれら 2 つの高リスク RCE 脆弱性を使用して、当時、多数のサーバー脆弱性が発見されたことがわかります。

3. 概要

この記事では、Thinkphp の歴史的な脆弱性原則を組み合わせ、Thinkphp の脆弱性を悪用した成功事例を共有します。現在、デバイスによって毎日検出される最も一般的なログは、weblogic、struts2、thinkphp などの直接の getshell ログ、または ssh rdp ブルート フォース クラッキング ログです。多くの攻撃者が最新のエクスプロイトを発見すると、独自のスキャナーを装備してネットワーク全体をスキャンするため、1 日に数回のシェルが発生する可能性があります。したがって、高リスクの脆弱性が発生した場合には、ユーザーは適時にパッチを適用し、セキュリティ デバイス ポリシーを設定することが推奨されます。実際のいくつかのケースから判断すると、スキャナーのリスクは常に存在します。 Web サイトが直接 IP アクセスを禁止するように構成できれば、この脅威をある程度軽減できます。レベルが限られているため、記事内の間違いを指摘し、提案を共有してください。

以上がThinkphp の歴史的な脆弱性を保護の観点から見る方法を教えるの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。